Re: Altivec is a waste if the OS is hogging it!
Originally posted by barkmonster
Using any kind of altivec optimised code for the GUI is a complete waste of resources. I know with Quartz Extreme it's less of an issue but it shouldn't be an issue at all. Altivec is there so the G4 can try and match the raw cpu muscle of the increasingly more powerful chips Intel and AMD make. It's also there to accelerate code that would normally bog down any current cpu. Once I've got a G4 I hope any advantage altivec has isn't squashed by the sheer overhead of OS X. There's a lot of software synths and plug-ins that benefit enormously from altivec code, not to mention video codecs and such. It would be a waste to use the SiMD extensions on the OS instead of to speed up applications like they're designed to do.
Hmm. Well, either you or I has a fundamental problem in understanding AltiVec and pre-emptive multitasking.
On a CPU using pre-emptive multitasking, a single process (thread) "owns" the CPU for the duration of a time slice (how long that is is determined by the scheduler, not directly by the application as in co-op multitasking). The register state of threads has to be swapped out and in as their slices expire and come up again. While a particular thread owns the CPU, no other thread may execute on that CPU.
For instance, if AppX is doing a bunch of integer math, and AppY wants to do a bunch of floating point math, it would be really cool if the CPU would give it's integer units to AppX and its FP Units to AppY simultaneously. But that's simply not the case.
Now, I've seen the AltiVec unit described as a "co-processor", and indeed it does have its own set of registers, cache, etc. It is at least theoretically possible that when a particular thread "owns" the CPU proper, the AltiVec coprocessor could be chugging away on calculations for a different thread. However, I see this as a highly unlikely design (generally AltiVec instructions happen in tandem with PPC instructions, and so there is no AltiVec "chugging away" scenario where the CPU itself is idle for the majority of a time slice, and providing such possibility on the remote chance that it would be used would needlessly complicate the design for little noticable benefit even when it really would be used).
So, if OS X's "OS threads" (Finder, Quartz, etc) are using AltiVec, that's great. The OS using or not using AltiVec will have no bearing whatsoever on the performance of other processes that wish to use AltiVec, as any OS X altivec usage will be cleared out when its timeslice ends.
