gregnacu said:
They don't list any benchmarks on the site, but they do mention that it is about 500 times slower by Raw CPU cycle speed.
That's for the interpreted CPU, the JITC (or dynamic recompiler, as Eric Traut of VPC fame calls it) should be roughly 10 times faster, although from a quick glance the at the source code it seems that some of the more complicated instructions aren't translated to x86 code yet.
I'm interested to see if Apple will try to sue them. They must be using some sort of proprietary Apple ROM technology to allow it to run the Mac OS. A Mac is a comprised of a heck of a lot more than just a PPC Processor.
Modern Macs use Open Firmware which is, well, open, and PearPC seems to implement that.
insidedanshead said:
While WINE is a a good open source project it is still emulation.
I guess this myth is never going to die, although WINE already is an acronym for "WINE Is No Emulator".
WINE doesn't emulate a CPU or any other piece of hardware, instead it consist of a port of the Win32 API to Linux, and a PE-loader to run the Portable-Execution-Binaries Windows is using.
Once again, no emulation involved, so WINE is no emulator!
omnivector said:
second, it's IMPOSSIBLE for this emulator to EVER get close to the speeds of virtualpc for the mac. virtualpc runs as fast as it does because mac processors (g3 and g4 specifically) have little-endian emulation, when ppc chips natively run as big-endian. this basically means that the bytes inside the memory are in the order 1 2 3 4 5, not 5 4 3 2 1. with ppc's little-endian emulation, this byte-swapping does NOT have to be done in-code, but rather can be done in-cpu.
Actually, I think that trick was part of the memory controller not the processor, which is why VPC6 refuses to work on the G5. Of course there still are the "load/store byte-reversed indexed" instructions, but I doubt you are referring to those.
Anyway, since the 486 the IA-32 has the BSWAP instruction to perform an endian conversion on a 32-bit word, and that takes only one cycle on Pentium and later processors. Since I guess that byte and 32-bit accesses will be the most frequent, I doubt that the endian-conversion is the big performance hit you make of it.
on the other hand, x86 cannot do this. this means that for EVERY single mathematical operation (which in computers is almost every single assembly instruction) the bytes have to be swapped (from big endian to little endian) then calculated, then swapped back to big endian before it's put into the ppc cpu's virtual memory store.
No, those conversions only have to take place when the PPC loads or stores a value to or from a register, because as soon as it is in the emulated register you can assume that the value will be in little-endian byte-order. Since PowerPC is a load/store architecture all instructions apart from these two types only operate on registers, which means no endian-conversion has to be performed while emulating these.
To summarize: When emulating PPC on x86 endian conversions only take place during loads and stores.
the other reason this emulator will never be nearly as fast is the ppc architecture has 32 general purpose registers. the x86 only has 16.
This is the bigger issue, especially since IA-32 only has 8 registers that are sometimes called general purpose (AMD's x86-64 has 16 GRPs). But from my point of few those registers aren't GRPs, eg. variable shifts expect the shift amount in CL (the lower 8 bits of the ECX register), multiplications and divisions use the register EAX implicitly, and some instructions generally prefer the EAX register, which shows that x86 decended from an accumulator machine, to name just a few examples.
Also x86 instructions have two-address code, while PPC has three-address code, ie. in PPC you can have a=b+c, when x86 only manages a=a+b. The emulation will certainly need more instructions per PPC instruction, and register allocation will be quite tricky, with a large part of the register file probably residing in the caches.
because of this, the x86 architecture will always be horrible at emulating ppc. without having those additional 16 registers you have to emulate them in-code. which means they will be an order of magnitude slower (try 100 times slower).
That's rubbish. While the lack of registers in the IA-32 is a big problem, especially when emulating a RISC processor, stack operations have been optimized for that architecture, and most of the emulated register file will be found in the fast caches, not the slow main RAM.
It's true that the emulation won't be faster than the cache, but it certainly isn't 100 times slower. This kind of emulation of RISC processors has been done several times before in Playstation and N64 emulator, which both have MIPS processors with 32 GRPs (in the case of the N64 even 64-bit), and those don't need a 100 times faster PC either.
Will this harm Apple?
No, not unless PCs become at least 10 or more likely 20 times faster than Macs, and I don't see that happening in the near future, especially after the recent speed boost for Apple computers.
I knew that something like PearPC was bound to appear sooner or later, with all the PPC emulation showing up over months and months. But I was never worried about it, because I know enough about the internals of emulation and also about the two architectures involved to be sure that it'll take one hell of a PC to emulate MacOS X at a useable speed, and with such a small performance difference between current PCs and Macs this is going to make the Macs just more powerful.
