Two reasons: the context switch between the two processors is too slow, and the JIT emulator is probably faster than the 68k processor you have.
IIRC, the 68k & PowerPC processors on that board couldn't operate concurrently (was this a hardware limitation, or a software one?). Either one was running, or the other. Some PowerPC software appeared to be really slow because every time a call to a system library (or any other non-PowerPC code), two context switches occurred. This really killed performance.
I dont know if im thinking correctly, but couldnt the ppc/os be nursed into sleep mode, and then the JIT could make use the 68k, so that it would be a sort of emulated 68k?
I dont know if im thinking correctly, but couldnt the ppc/os be nursed into sleep mode, and then the JIT could make use the 68k, so that it would be a sort of emulated 68k?
I don't really understand what you're asking. The JIT (Just In Time) emulator translates 68k code to PowerPC and stores the result so that next time that it runs the same code, it can use the translated code directly, instead of retranslating it. This makes it much faster than an interpretive emulator which must translate every instruction one at a time. It can't use the 68k chip at all.
Putting the PowerPC chip into sleep mode is pretty much what WarpUP/WarpOS does. It wakes up the 68k processor and halts the PowerPC (one of the context switches I was talking about); once the 68k processor is done, it wakes up the PowerPC processor and halts the 68k CPU (the other context switch. It really kills performance.
I don't know if it's a hardware or software limitation. Basically, their's no multi-processing going on. Even if it's not a hardware limitation, Amiga OS isn't ready for multi-processing yet.
People are just going to have to accept that the 68k CPU on their accelerator card is of no use any more. Trying to use it will slow their machine down, not speed it up. It was put on there as an interim solution while the OS wasn't fully PowerPC and no decent 68k emulator existed. Now that the OS is PowerPC and we have Petunia (OS4's 68k emulator with JIT), it's of no use any more.
mike wrote: By the way, since the "emulator" and ppc os4 would now be separate from each other, i dont think you'd have that problem anymore
It wouldn't matter for PowerPC programs, but 68k ones would crawl if you used the onboard 68k CPU. The context switches between the CPUs are slow and there's no method to speed that up. Seeing as the emulator is already there, and is faster, I'd stick to using that.
Thats a great approach to emulation tho, it might actually be faster then.
According to people that have tested it, it is faster. The Petunia website claims that: Quote:
The emulation is working at least an M68060/50Mhz level on a PPC604/180. Faster processors will gain more speed, of course. Some opcodes and operations need more effort from the emulator to keep it compatible, the others are easier to implement, therefore the actual speed is highly depending on the emulated 680x0 code.
I'm not sure how old that is. Possibly the emulation could have had even more speed improvements since then.
Check the specifications of the 68K CPUs on Cyberstorm and Blizzard cards, and you'll see that it's faster than the 68K CPU on board (a 180MHz PowerPC is usually paired with a 25-40MHz 040). Obviously, on my 800 MHz A1, the emulated CPU is faster than any real 68K CPU.
That's good news. Have bidded for and won a PPC on ebay recently. Just waiting for it to arrive. (Fingers crossed.) Not having OS4, I don't know a great deal about it or Petunia. Intend to set up my system to run both OS3.9 and OS4. But from what I have read here, may not have to boot up 3.9 quite as often as I first thought.
Since there is no snooping or anything like that going on, and the two CPU's have their own caches, running 68k code on the 68k CPU would require a cache flush on the PowerPC and the other way around when the control passes back to the PowerPC. That is also the reason why you could never use both CPU's at once, even on WarpUp/PowerUp, because their caches might see totally different data and they don't speak the same language (i.e. the same bus protocol as two PowerPC cores would).
Bottom line, you don't get extra performance, or anything like "parallel computing" out of a CyberStorm or Blizzard. More so, executing a small quantum of 68k code will also negatively affect all other running applications because the cache flush will make them slow down (the cached memory needs to be fetched again).
"Luckily" there is no L2 cache on the 603/604, or things would become even worse.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Thanks, I'm really looking forward to getting my cppc and a4k back from repairs now, apparently It's in the final phase.
Btw, will there be a downloadable version of the OS? The import tax in Norway is sky high, 25% + the customs handling. Which in turn equals a rather pricey box and printed cd. Around 116 - 120 euro in total.
That is also the reason why you could never use both CPU's at once, even on WarpUp/PowerUp, because their caches might see totally different data
Slightly incorrect. On PowerUp and WarpUp you can take an advantage of parallelism. You only flush caches when you must share data i.e. when PPC is trying to pass decoded MP3 data to 68k AHI driver.
However there is performance penalty when both CPUs have cache misses at the same time and only in some applications both CPUs can run continuously at full speed.
Yes, but on OS4, both 68k and PPC programs are running on the same (PPC) kernel, so nothing like this is really possible. Trying to use the real 68k on OS4 would make both 68k and PPC programs run slower!
Also, on WarpOS or PowerUP, all the OS functions are 68k and run on the slower processor, but on OS4, all OS calls are PPC native, so system friendly programs get a massive speed boost.
IIRC, the 68k & PowerPC processors on that board couldn't operate concurrently (was this a hardware limitation, or a software one?).
They operate concurrently but only one can access the ram at a time.
Which is no different from any SMP system really (except maybe other systems might have a shared cache at some level, and bus snooping). What causes the huge performance hit on the context switches then? How could they run concurrently if the OS has no concept of this? Given that Amiga OS 3.x had no concept of private memory, how did PowerUP/WarpOS know which memory areas were and weren't being shared?
It sounds like having two processors really didn't help.
What causes the huge performance hit on the context switches then?
Cache flush. It is needed when 68k and PPC are exchanging data.
Quote:
How could they run concurrently if the OS has no concept of this?
New kernel called PowerUp was developed to run PPC software.>PPC software ran on PUP and 68k software ran on OS3 like it always used to be. WarpUp implements same but in hand written PPC assembly.
If PowerUp or WarpUp kernels had 68k emulator you could switch off 68k and run 68k code on PPC only... sounds familiar, doesn't it?
Quote:
Given that Amiga OS 3.x had no concept of private memory, how did PowerUP/WarpOS know which memory areas were and weren't being shared?
There were new memory allocation functions to provide required memory. You could allocate memory as non-cacheable (for PPC or 68k or both) or in writethrough mode and so on.
Quote:
It sounds like having two processors really didn't help.
In the end PowerUp boards were only expensive MP3 players.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
