Performance of the M68k emulation running on PPC (question)

[Astroman]

there's certainly some information/benchmark burried in the docs, but someone might share his/her real world experience.

Background: I use a fairly exotic (Prolog) developement system on PC, which happens to have a native M68k counterpart specifically written for the original Mac OS back in the late 80s and supported until 1996 or so.
The PC version is fast as lightning and of course features lots of brilliant language extensions developed after they ceased the Mac branch.
But the Mac version wasn't a slouch either in it's days, including a lot of Mac specific support and the ability to add Pascal/C extensions. Toolbox graphics right out of the box.

Running a benchmark app (intended to compare the different PC compilers) resulted in a difference of a whooping factor 40 advantage on the PC, oops.
Factor 4 would be expectable as optimum, for that's the clock difference between the machines.
I suspect CPU cache playing a big role in this game.
Don't bother with the 'special' language, it's just a well implemented compiler used as an example in this context (and because I really liked the Mac implementation)

[teroyk]

I am not sure if I answer to your question, but I have to say:"68k Mac emulation on G3-G4 PPC Mac is fast enough."
Longer answer is not that simple, but it can be even faster

[Naiw]

I think you can consider M68k code running on the PPC at best performing at around 1/4th of the native speed, but typically more in the range of 1/6-1/8th.

[MacTron]

Yes, it's fast because a 68k app most of the time runs calls to native PPC routines.

[Astroman]

I think you can consider M68k code running on the PPC at best performing at around 1/4th of the native speed, but typically more in the range of 1/6-1/8th.

thanks, my fastest 68k was 32 Mhz - which would set 250 Mhz as a safe PPC equivalent.
500 to 1G will shurely improve things, let alone the extended memory (which was the biggest drawback originally)
I never cared about my PC CPU specs, but will check the on chip cache figures and which PPC versions come closest in design.

Since Prolog source transfers really well from PC to OS-9 (there's even a similiar graphic handling) it may become a valid option to develope from/to OS-9.
Don't remember the procedure atm, but it was possible to run the stuff as standalone applications.

[Naiw]

I think you can consider M68k code running on the PPC at best performing at around 1/4th of the native speed, but typically more in the range of 1/6-1/8th.

thanks, my fastest 68k was 32 Mhz - which would set 250 Mhz as a safe PPC equivalent.
500 to 1G will shurely improve things, let alone the extended memory (which was the biggest drawback originally)
I never cared about my PC CPU specs, but will check the on chip cache figures and which PPC versions come closest in design.

Since Prolog source transfers really well from PC to OS-9 (there's even a similiar graphic handling) it may become a valid option to develope from/to OS-9.
Don't remember the procedure atm, but it was possible to run the stuff as standalone applications.

Why not go for a G5 or something then and run your Prolog environment in classic? Or a highend G4 that can run OS 9 natively if necessary,
The classic route would give you the best possible performance while allowing you to connect to whatever other machines etc you need.

[Astroman]

there is no need to run this in Classic - under OSX the current Windows version runs perfectly with a little help of Crossover Mac.
It's an outstanding environment for database solutions, parsers and string handling.

The Mac 68k version isn't supported anymore since over a decade.
But it might be a cool way to work under OS9 on/with more or less up to date stuff and don't treat it as the literal desert island.
While the 68k environment was limited in it's memory architecture, it can use all on the PPC.
Atm I don't remember exakt performance figures, but could easily retrieve them to get a better estimation.

As a background: we used Open Interface in the M68k days for the GUI of a text retrieval system with an Oracle Server (running on Mac) backend.
After Oracle ceased Mac support, I restructered the database and used Prolog for both db engine and user interface, resulting in a more flexible design and much less code.
(PowerMacs using Crossover to run the Windows version of the system under OSX)
Prolog is (if at all) known for scientific apps, but it can do serious business stuff if the engine is written well. And this one really is, even the 68k origin.

Never bothered about the emulator before, but now I'm just curious about the performance of the Prolog oldie, which happens to be pure M68k code.
It should be fairly easy to add Mac specific features beyond standard Quickdraw.

[DieHard]

As a background: we used Open Interface in the M68k days for the GUI of a text retrieval system with an Oracle Server (running on Mac) backend.
After Oracle ceased Mac support, I restructered the database and used Prolog for both db engine and user interface, resulting in a more flexible design and much less code.

The company I owned in NY was an OracleWare VAR back in 1998, but we ran the "backend" on Novell Servers; I have never seen a database run so efficiently as OracleWare, it makes even modern versions of MS Sequel look like absolute snail spagetti code in the performance dept.

[Astroman]

yes, I fully agree with that in the business department. Oracle simply rules in this domain.
In our case the Mac Oracle Server (around 94 iirc) successfully replaced a dBase 2 office system under Novell Netware, and then was transferred to a WinNT machine.
(which was cool since the same network driver continued to work on the Mac side and no change in the GUI was required)

But the actual task was full text retrieval in a combined text/picture archive without any transaction processing.
Stored procedures are not very efficient in this context.
Looking up (say) 3 items that have to appear in within the same sentence or paragraph.
Or numeric values in a certain range from text without a having a dedicated numeric field.
Results could be reused in new queries to avoid complex formulation of conditions.

Prolog is basically like having an Oracle core engine, but without the SQL layer 'restriction'.
As mentioned this approach requires a high class compiler written in efficient machine code.