Part of the problem with that is that apple used X86 on their OSX based PPC machines. This caused the proc’s to spend most of their time trying to patch everything through. When you weren’t doing major system stuff or on the net and just processing stuff, rendering video, blowing through code, batch processing in general, thats where the 970 raped. Still does, just expensive to run.
Glad to know I’m not alone
Expect stuff to come out on it in june/july. My IRC friends have been busy it seems
What are you referring to? The system code was from Nextstep and classic mac os, right? I imagine legacy code would be in C or ported from 68k assembly.
The base OS code? No dude OSX was built off of BSD. Now they only have the kernel and userland, but 10.6.8 and back was basically just OpenBSD with Aqua and some fine tuning on top of it.
Any idea what the base and turbo frequencies are for each of these three CPUs? Trying to find the right balance between single and multi thread performance.
Since 2003 when the G5’s were announced and released, yeah. Prior to that the G4’s were actually really good. When the G5 updates dropped that fucked everything. Later on a tool came out in 2006 that strips all the code from all your apps and system that is for other architectures, including ARM, G3, G4, G5, and X86, and on my ibook G4 my performance skyrocketed. From looking at apps on my system that were G5 oriented, but could run on a G4 just fine, that sped that shit up significantly. Even just having it scrub the base sytem of everything X86 on 10.5 sped up interface performance like mad. Other tests by other people have been done that I don’t exactly understand that have to do with how the system runs through different calls and organisation, but again thats over my head. As well as Linux running better on G4/G5 than the OS that was originally dev’d for them (10.4, I just run 10.5 for the software compatibility and deal with the performance hit from the added AltiVec usage).
The only way you would have x86 code would be with fat binaries:
This wouldn’t slow down execution, it would just take up more space on the hard drive, unless the OS is stupid enough to load executable code it can’t use, and even then, you would just be using some RAM.
I can’t think of anything that would benefit x86 at the cost of PPC in the way you describe, and certainly not anything that could be fixed without recompiling the whole system.
Can you give any links to this utility or the tests others ran?
It thin that @FaunCB may be confusing the “Compiled for x86” with the fat binaries that included PPC and x86 code branches.
There was that three year transition where the fat binaries came out and mostly all was well. The older PPC systems eventually had issues because they did not have the horse power that the G5s had and the PPC branches started becoming less optimized (Apple aint got no more time for that). The late G4s were okay because they had high clock speeds and Altivec was utilized to the max.
By the time that they phased out support for the non-G5 and x86 architectures, they had been encouraging their developers to develop for x86 because they wanted to get rid of the fat binaries. As a result a lot of code would run on the G5s but was not optimized, and they were also running on the fly instruction translation/emulation because the G5s could handle it; it had 64bit registers used to run the x86 code in 32 bit mode. As a result, if you still managed to get a non support version of OSX on your G4 or older hardware, it was balls slow. Stripping out the x86 from the fat binary forced the PPC path which was not bad. Think of this like the current " Your battery is to weak to run the new iOS are acceptable speeds" deal. Some people on the the not so distant iPhones don’t have the issue when they by-pass this feature while others have phones that power off because they cannot handle the load (unless they have new batteries of course slight_smile:
There was coverage of this in LKML for a while as Icculus and a few others were championing a fat binary to deal with the Linux x86/x86_64 debacle. they were citing Apple’s model as poster child while also point out some of the flaws in the Apple approach. Icculus had a working patch for the Linux kernel that would work on day one.
Apple made a PPC on x86 emulator called Rosetta; I have heard about this one.
What you describe is a x86 on PPC emulator; I have heard nothing about this, and it also makes no sense, as it would be a lot of effort to write this kind of emulator for a architecture you are abandoning. Especially if as you mention, it only works well on G5.
Are you sure about this, and if so what is your source?
I may have confused the two. I would have to look through some old bookmarks.
I know PPC on x86 was hella slow. In regards from a business perspective, it would make sense for them to make Rosetta Stone work on G5s as they announced the Intel change all of a sudden and those G5s were not cheap. Again, I will have to look through my old bookmarks to validate that.
I do remember that there were some issue with the endian-ness of the two architectures as well when dealing with the fat binaries. Sometimes the files were partitioned such that little endian would be on one side and the big endian would be on another. Some vendors did not adhere to this practice and sometimes the code would be intermingled. This created parsing issues on both sides, slowing things down, following pointers to get to the other chunks of relevant data. Again, I will have to look through some old bookmarks.
I thought for endian-ness, x86 would be at the disadvantage overall.
It is in HFS+; since HFS+ is big-endian PowerPC lets you skip the byte swapping. The wikipedia article does specify “metadata”, so maybe they partially fixed this for file contents at some point?
I will look through my bookmarks. I did not know that about HFS+. It always seemed like horrible FS. I did not realized the NTFS was better on a technical stand point.
I am currently trying to remedy a NIC bug on my rig so it may take a while. My temporary wireless USB dongle is flaky and seems to only partial work under Arch. partition. My heavy lifter is my Debian SID partition.
in yaboot, your help would be appreciated there I think.
I am also writing this because @FaunCB forgot to give a link when he mentioned this thread in his post, and I know Discourse will generate a helpful link there if I link to his post from here.
I have some stuff coming up at work that will probably keep me offline for a while, but before I go, I thought I should make one final post.
Torpcoms’ News
It looks like JSharp on the RCS wiki is working on some kind of crazy Power9+Opteron cluster, and he also links to a tutorial on the OCC (on-chip thermal controller core on POWER). This is the same guy that was asking about Power Ultravisor mode, and is talking about replacing the SAS controller on Talos II with an extra OCuLink port. If you find stuff on this thread interesting, you might want to keep an eye on what he’s doing.
Another user on the RCS Wiki, MarcusC, was actually recompiling the Talos firmware on Gentoo on an Amiga X5000. Apparently it takes 18 GB for the build.
Thanks for the discussion, it’s been really nice to have someone else to talk to about this stuff.
Also, I made a backup of my timestamps for certain videos on my GitHub account, if you want to use them or copy them, consider them and anything else I’ve posted to be in public domain or CC0.
Not huge news for many, maybe one or two people, but the newest version of Icaros Desktop that is coming out in a while will have better emulation support for PPC and POWER based machines. Kinda exciting.
slight_smile:
