One of the big unknowns of the Apple Switch that not many people are talking about right now is Rosetta, the translation software that Intel-based Macs will use to run legacy PPC binaries. Prior to the release of the first Intel-based Mac it’s difficult to assess just what kind of performance Rosetta will yield on the majority of legacy OS X software. Will most legacy PPC apps be usable? Mostly usable? Barely usable?
Didn’t Asa (mac firefox guy) say that the PowerPc version of Firefox run faster on the apple development box (Intel) than on a native dual 2.5 Ghz G5? I found that rather amusing. Amusing excpet for that fact I have a dual 1.8 that will be smoked by the Intel Macs….
I’ve talked to a few software developers who have used Apple’s Intel developer boxes and they’ve attested to the fact that emulation speeds are indeed 80% of full native speed as Apple said all along. Why is Hannibal so inclined to doubt them?
Why is there a repeated trend in articles that Hannibal writes that he goes out of his way to undermine anything that Apple has said. I’ve called him a PC fanboy in the past for this behavior and was scolded by some on this board for having done so. So believe it is because I’m trying to undermine Hannibal’s technical expertise. For the record, I know there isn’t yet reason to believe that his technical insight should be called into question. The guy is very intelligent and typically reports things accurately.
But he seems to have a an automatic desire to instantly doubt anything Apple does or says and often times goes out of his way to cast a cloud over the company for areas that may be subjective and I find that very telling.
He may in fact be right, but I find it interesting because it seems as if you can get a pretty good gauge for what his response will be to anything Apple. So PC fanboy continues to be his label in my eyes.
Actually Apple has maintained the fairly realistic position that the performance of the translated code will depend on the nature of the program in question. This is entirely accurate. The more sensitive to raw computation the task is, the worse the performance will be.
There is nothing in his article that paints him as a “PC fanboy,” and simply questioning the performance claims of Transitive’s CEO by technical means hardly constitutes some affront to Apple.
He states why he feels that Transitive’s figure of 80% is an optimistic figure, points out that the translation will require more memory, and posits that it should matter little to Mac owners because the largest applications will be available natively by the time they opt to switch in the first place. In short you attack him because you perceive him as questioning your faith, and that’s really silly.
You are attempting to put into question Hannibal’s technical assessments on the grounds that he is biased in such a manner as to make them worthless. If there’s any criticism that this article deserves, it’s that for anyone familiar with the topic at hand, his article isn’t at all insightful. Even people that simply make use a lot of managed code (perhaps Azureus, due to its popularity and the native SWT) should have some impression as to the increase in memory requirements they may see.
I would further suggest that outside of the memory requirements for conducting translation for the already large word processors we find ourselves using from day to day, it seems fairly unlikely that the average person would notice anything but the most astound degredation in performance in such programs, because the majority of their usage is constrained by the user, rather than the application. The most irritating aspect of the performance penalty would be in startup, I think.
I’ve talked to a few software developers who have used Apple’s Intel developer boxes and they’ve attested to the fact that emulation speeds are indeed 80% of full native speed as Apple said all along. Why is Hannibal so inclined to doubt them?
Erm, maybe because these Apple developers have a product to sell?
I thought this article was well thought-out, and his explanations made a lot of sense, even to someone who isn’t a programmer (me). We’re talking about two totally different architectures, you can’t expect emulation to be at 80% or more *always*. Of course, some apps will run at this speed, but *not* all. That is simply impossible, and I’m sure future benchmarks will support this.
Running a notepad will be at 80%, but will the same go for a bigger, more complex application? No way in hell.
Running a notepad will be at 80%, but will the same go for a bigger, more complex application? No way in hell.
Well, this is a little deceptive. Let’s take a couple of bigger, complex applications and think about it.
The Firefox developer’s mention performance on par with the currently 2nd fastest Mac’s, Meanwhile the idea of running say, DreamWeaver would terrify me, based upon previous experience with this type of technology. The question is not the size of the app (though that would have an effect during startup / initial translation), but what the app is doing. FireFox, which does not really use the CPU heavily, since it is more latency / bandwidth constrained than CPU constrained, probably does get 80% of native. At the same time, DreamWeaver, which is inexplicably CPU heavy even when nominally idle, would be lucky to eek out 30-40%. Virtual PC won’t even be able to run since it uses kernel modules to implement functions that Rosetta doesn’t address according to Apple.
It’s all in what the app is doing, not the size or complexity of the app.
In other words, PhotoShop under Rosetta is not going to be fun, but hoepfully it won’t be required either.
In other words, PhotoShop under Rosetta is not going to be fun, but hoepfully it won’t be required either.
It’s really not that terrible – I’ve been lucky enough to play with a developer kit Mactel. Guesstimating, 80% seems high but somewhere between 50 and 80% seems reasonable. PPC Photoshop works great, MS Office works great – when you’re just fiddling around, you notice no big difference. Considering that Apple is going to introduce Mactels at the low-end first – where there’s the largest performance gap between the platforms – I think people replacing their Mac Minis and iBooks won’t notice much of a difference at all.
For a dual G5 FCP box, of course, all bets are off… anybody with serious hardcore power demands is going to want a native app.
One has to understand that Rosetta isn’t like traditional emmulation. Traditional emmulators would have program X requesting that a new window be drawn and they would then have that API code run in emmulation. With Rosetta, all calls to the Mac API are NOT going to be emmulated. That makes a huge difference.
well as firefox is persumably coded on x86 box’s its possible that Asa and co are better at optimising for the X86 than the PPC. though i could well be wrong heh!
Roger
He meant that the PPC version of Firefox ran faster in emulation on the Intel developer Macs than they run native on the highest-end PPC Macs.
Maybe it is 80% maybe not. As long as it gets us through the transition smoother than the Classic Environment did with the 9-X switch then i’ll be happy.
Surely by the time the MacTels are ready most software updates will include the dual binaries so Rosetta won’t be needed as much as people think.
Most Mac users turn over their machines about every 3-7 years, unlike 2-3 years for a PC. So by the time the new processor hardware rolls out, there will be all new versions of software to go with it.
So the problem with “legacy” software isn’t as big as it would be on the Windows platform.
Heck I trashed all my OS 9 apps and “Classic” a week after using Mac OS X, I think Mac users on average are more accepting of change in order to have the very best computing experience.
For the Apple/Intel FAQ go
http://appleintelfaq.com/
To see Mac OS X in action at it’s fullest capacity go here
http://homepage.mac.com/hogfish/PhotoAlbum2.html
(the 76 widgets actually take only 1.5 GB of active RAM and no CPU usage while Dashboard is not activated)
“Only” 1.5 GB of RAM? Sad.
Yeah, I’m sure GCC is better optimized for x86, and its very possible that firefox runs faster.(That could be because of integer ops on PPC are slower than Pentium, I suspect)
And there is a reason do doubt apple’s marketing: its decieving. Its not just Apple’s marketing but most marketing for products. Remember when Apple said that their G4 were faster than a Pentium 4 at 3X their clockspeed? That was true in the one photoshop test, but not in 99.9% of all other software or even other photoshop filters. Doubting any marketing that makes broad claims is just plain sensible to me, whethet its coming from Apple, IBM, Sony, or Microsoft. Remember when people said Cell would blow the doors off all the other chips out there? Then programmers that had the dev kit found out it was restricted in what it can do with those SPU’s? It sucks for many things it turns out, and often has lower performance than a top line Pentium or athlon64.
A simpler explaination for a increase in Firefox speed could be that Gecko can not take advantage of the dual processor, what would reduce it to 2.5 vs 2.88 (3.6 * 0.8). In all this you also have to remember as soon as MacTel Firefox hits Carbon its running native code.
All for the PowerPc vs x86, I could probably write a benchmark that wold run faster on a Mac thats five time slower then a P4 regarding clock speed. Of course it would be full of the altivec instructions that have no MXX / SSE equivalents, vec_perm on char vectors using run time determined permutes should do it, or byte swapping in a SIMD register, using the permute unit as a lookup table, and using the permute unit to handle alignment, that one even has a practical application.
Those photoshop benchmark are totally revelant when your target audience uses photoshop.
Dave
You don’t need any altivec code:
http://swox.com/doc/x86-timing.pdf
just a simple cycles with dependent adc or shift instructions will seriosly drop the performance of latest P4s. Athlons can eat all of them without problems though.
Prescott offers nearly 1/2 of G5 performance on math stuff according to GMP (high precision math)library authors.
http://swox.com/gmp/gmpbench.html
I think that given the time period the majority of major applications will be FAT binaries anyway.
I have a contact dev who has one of the x86 dev boxes in question. He did some benchmarks on it, and found that CPU intensive code (ie not counting when your program is sitting, waiting for you to click on something), that was compiled for PPC and emulated with Rosetta ran anywhere from 20% to 50% of the speed of the same code compiled directly for x86.
Anyone know (or at least speculate how) one will be able to run “real” legacy apps? I am talking about PPC and m68k OS9 apps that we currently run with “Classic”.
There’s hope.
http://www.ardi.com/ardi.php
http://gwenole.beauchesne.online.fr/basilisk2
http://www.students.uni-mainz.de/bauec002/B2Main.html
http://minivmac.sourceforge.net
In the documentation for creating fat binaries, it states that ‘Classic’ will not be supported on Mactel systems. So, it’ll be a stretch to say the least, getting those truly ‘legacy’ apps running.
Hannibal is basing his opinions on experience with similar technologies. I’ll admit, my first impression was much the same, only I went a little further back.
In the early days of the Digital Equipment Corp, Alpha AXP, Windows NT ran on the Alpha, quite well I might add, but it wasn’t easy to port your code from x86 to the Alpha, mostly because of the lack of compiler support.
Because of this, DEC created a Rosetta like product called FX!32. It translated x86 Win32 apps into Alpha Win32 apps in software and used a similar caching method. It wasn’t as transparent, but it did work. This was closing in on 10 years ago, and at that time, I’d say FX!32 apps ran at 60% of native CPU speed, if they ran at all.
What Transitive has done is taken that some concept and refined it. Looking at what Transitive has said, and comparing it to what I’m hearing from the rumor mills, they’ve refined it in two major ways. The first is that it is seemless and integrated into the OS, something that DEC couldn’t do. The second is to have tweaked performance. Between these two enhancements Apple has a technology that could overcome the negative associations that would normally be associated with this type of technology.
What we know at this point is that there are some apps and tools that Rosetta can’t cope with. ( http://developer.apple.com/documentation/MacOSX/Conceptual/universa… )
We know that Rosetta does not address Endain issues in any way ( http://developer.apple.com/documentation/MacOSX/Conceptual/universa… ).
We know that Rosetta can have applications forced to run within it’s framework for compatability purposes. ( http://developer.apple.com/documentation/MacOSX/Conceptual/universa… )
We know that the developers that have DTK machines and can attest to the performance are under NDA’s, and really cannot speak about the performance numbers. I can’t tell you anymore than what is publicly published, but based upon my experiences with FX!32, 10 years of evolution, and a feel for Apple’s ability to pull this off, considering how well they pulled of Classic in OS X, which was in many ways a much harder task, I think that Mac fans are in for a pleasant surprise.
Faster Intel hardware, reasonable performance from Rosetta, and quick uptake by developer’s with the excellent tools in Xcode2.1, means that the Rosetta performance should be plenty, assuming they even a 10% increase over FX!32.
The place where it could fail the user is with things that demand high throughput, like say Windows Media Player, which will be a problem considering the slow pace at which it has been updated for the Mac, an x86 build lis likely a good ways off, and it’s so CPU intensive on PPC that it’s performance under Rosetta is likely to be just that side of awful, but only time will tell. Everything else is guesswork.
Actually, a PPC application running under Rosetta will have _some_ of its endian issues resolved for free. For example, reading files in big-endian will work as expected under Rosetta.
Only in that they will be treated as if it was a PPC, in otherwords for the lazy developer that writes memory to disk, the files won’t be portable between the PPC and x86 app. (I don’t want to point any fingers at any specific applications)
> Actually, a PPC application running under Rosetta will
> have _some_ of its endian issues resolved for free. For
> example, reading files in big-endian will work as
> expected under Rosetta.
I have seen a lot of C and C++ programs writing C structs onto disk via write(2). The write(2) function just writes out the specified number of bytes of a typeless (void*) buffer.
I have also worked on a C program featuring a homebrew object management. That program allocates big chunks of memory via malloc(3) and uses relative addressing within those chunks. Each block is more or less organized like a FAT filesystem. Consequently the blocks also contain the complete object allocation imformation. Persistence is simply done by dumping the blocks in the order they have been allocated.
So it is not only endianess which could cause trouble. Also padding could cause trouble.
I too have big doubts, i mean this isn’t first time that someone tells this kind a stuff. Next someone’s gonna tell that Java programs will run as fast as native, right.
because the PowerPC chips Apple uses are SLOW…
…compared to the Intel chips that will be out in 2 years when Mactels ship.
Apple has a two-pronged strategy.
Route A – provide tools that make building a universal binary easy and then give developers plenty of notice about the arrival of Intel based Macs.
Route B – Run applications that the developer has not bothered to port in time for the Intel release under Rosetta.
For applications that need performance like photoshop, mathematica and other high performance apps I imagine the developers will be taking route A. Even 80% would not be acceptable for high end users.
http://barefeats.com/dualcore.html
According to this article the current G5’s do VERY WELL against the Intel Pentium D’s.
Plus, Apple may finally release the the Powerbook G4 update 7448 at 1.9? with 1meg of L2 cache. One Last PPC laptop for the Open Source Linux crowd? Yellow Dog Linux, are you ready?
Anyone do any speed comparisions of G4 optimization of Linux on the PPC?
Which would be faster? ( Rumor has it Tiger is compiled for size. )
Compile for size or speed?
Actually I think the 80% is accurate if you go on the execution of pretranslated and cached code. So, if you’re running say, large Photoshop filters or massive computations the translation time is neglible, and the cached code will run at about 80%, but it’s hard to say without getting hands on solid benchmarks.
From what expert emulation programmers say, typically this is rare to hit out of that code cache to get the 80% speed, so usually with the translation overhead it hits about 25%+ speed, maybe faster as mentioned. Hard to say without a test system on my hands. Also don’t forget all the API issues are taken care of, so that’s less emulation to have to deal with, so it’s probably faster that that 25%+ I mentioned.
However, given that the full switch is 2 years off (thereabouts), and speeds usually double at the same rate as Moore’s law (well, that’s sort of broken now that dual-core chips are around) in 2 years time we can expect that whatever is out will emulate at say, 50%-75%+ of the speed of today’s PowerPC chips.
If the PowerPC clock speeds stagnate (ie, don’t ramp well) the comparison of PowerPC to Intel at the time of the final switch means that emulation would be fairly reasonable (at least 50%+ speed). You’d hope developers would have made Intel and PowerPC binaries at that point in time, however, there’s no excuses for large software companies such as Adobe or Apple.
“According to this article the current G5’s do VERY WELL against the Intel Pentium D’s. ”
So? Isn’t that what Apple has been trying to tell all the time? That the G5 is a fast processor?
BUT, you can’t use a comparison of today’s G5 with today’s Pentium to tell how future G5s compares to whatever type of future Pentiums Apple will use.
“Plus, Apple may finally release the the Powerbook G4 update 7448 at 1.9?”
WOW!!!! And it will have a whopping 200MHz bus!!!!!!! OMG!!!!!!!
On *real* legacy kit perhaps? Just keep your current machine and use it to run the legacy apps you need.
Unless you have some very obscure “special needs” why not try upgrading to some newer software for your new machine – what old SW are you running that can’t be replaced with newer stuff?
This is NOT an insult or personal attack so please don’t take it as one.
I am a serious Mac fan and professional user, I have a range of Macs from SE (with prodigy accelerator card) through LC 475 (with full 040 upgrade), PM 7100, G4 400 and G5s. Sure the ability to run old software on the G5 is neat – but I basically almost never use it…
I soooooo regret not buying Transmeta stock 2 weeks ago. They’ve doubled in value since.
Considering what Transmeta could mean to Apple…oi.