Peter McCulloch

I was curious if anyone knew which objects have been affected 

speedwise by the switch from the G4/5 to the Intel chips. I've used 

a lot of optimizations based on matrix~ in the past, and was curious 

A quick test seems to suggest that matrix~ is a little slower on 

Intel Macs than it was with Altivec, but I'd like to hear other 

I was curious if anyone knew which objects have been affected  
speedwise by the switch from the G4/5 to the Intel chips.  I've used  
a lot of optimizations based on matrix~ in the past, and was curious  
if that was still useful.

A quick test seems to suggest that matrix~ is a little slower on  
Intel Macs than it was with Altivec, but I'd like to hear other  
people's opinions and experiences.

intel-mac-optimizations

I've noticed this with some objects (altivec beats intel).

However, this is only to be expected to some extent as with altivec you can be parallel processing 4 values with one instruction - maybe getting the work done twice as fast (in a good case) which beats the speed increase that you'll get from the last gen PPC to the new Intel machines (esp. because you can't effectively use multicore capabilities.) having said this - some objects are still faster under intel despite the lack of SIMD code.

Now, if SSE optimisation were to be implemented then that would be some serious speed increase. it's suprisingly easy to port from altivec and SSE2 is a requirement for Mac OS X so all Mac machines have to have it. However, I doubt Cycling will go this route, as macintel means less need to code platform specific, and although SSE may be available on many windows machines, I don't think it's guaranteed. Also the heavy and UI overhaul of Max 5 means that their attention is (necessarily) elsewhere at the moment. Optimise int the dsp window does nothing under Intel asfaik (the routine in the API alsways returns false no matter what you do)

Yes - it's really bad for G4-to-Intel or G4-to-G5 transfers - it 

copies over things that it shouldn't (old frameworks, preferences, 

On Oct 16, 2007, at 5:52 PM, Peter McCulloch wrote:

> I was curious if anyone knew which objects have been affected 

> speedwise by the switch from the G4/5 to the Intel chips. I've 

> used a lot of optimizations based on matrix~ in the past, and was 

> A quick test seems to suggest that matrix~ is a little slower on 

> Intel Macs than it was with Altivec, but I'd like to hear other 

Yes - it's really bad for G4-to-Intel or G4-to-G5 transfers - it  
copies over things that it shouldn't (old frameworks, preferences,  
non-UB objects)

> I was curious if anyone knew which objects have been affected  
> speedwise by the switch from the G4/5 to the Intel chips.  I've  
> used a lot of optimizations based on matrix~ in the past, and was  
> curious if that was still useful.
>
> A quick test seems to suggest that matrix~ is a little slower on  
> Intel Macs than it was with Altivec, but I'd like to hear other  
> people's opinions and experiences.
>
> thanks,
> Peter McCulloch
>
> www.petermcculloch.com
>
>


Quote: Roald Baudoux wrote on Wed, 17 October 2007 05:24

----------------------------------------------------

> Having switched from G4 to Macintel, I've had the impression the FFT performances are not that good on Macintel.

i did some testing that clealy showed this to be the case when I first got my MBP. it's definitely true, and stems (I think) from using the same routines for mac/pc, whereas previously under G4 the fft routines on apple were those provided by mac frameworks (with all the nice altivec optimisations).

It's a shame, because under macintel the same frameworks provide new (SSE) versions that are very fast, and use (for the actual fft routines at least) exactly the same function calls, so translating code is very easy. In other words it would be technically possible to get better performance out of these objects, but I'm not sure cycling will opt for any platform dependent code in the future if it can be avoided. In a case like this where the CPU benefits are substantial however, it is frustrating not be running optimal code.

Quote: Roald Baudoux wrote on Wed, 17 October 2007 05:24
----------------------------------------------------

I also would enjoy big time to have vector optimization for FFT~ and buffir~ objects.

I'm pretty shocked that Max5 doesn't use SSE instructions. They've been around for a looooong time now. Correct me if I'm wrong, but (depending on the compiler) C++ intrinsics for coding parallelism aren't platform-specific. "movps", "addps", "mulps" etc. are common to both macintel and PC instruction sets. And the argument that not all machines support SSE is pretty much moot - all it takes is a quick CPUID (asm mnemonic) to ascertain a machine's capabilities.

 want to join the dev-bashing brigade. Max is a sick, sick program. But the performance 

 really, really bad in this day and age. Don't get me started on Max5's GUI. I'm well aware of the danger of biting the hand that feeds you, but I find it hard to hold my tongue when I read so many posts from paid-up users who seem to be more inclined towards keepinf the developers sweet than pushing them towards improving what is, in all honesty, a very expensive "work-in-progress".

Sorry devs, I still feel like my money was well-spent, but it has to be said that you're behind the curve when it comes to performance.

You know, I really don't want to join the dev-bashing brigade. Max is a sick, sick program. But the performance is really, really bad in this day and age. Don't get me started on Max5's GUI. I'm well aware of the danger of biting the hand that feeds you, but I find it hard to hold my tongue when I read so many posts from paid-up users who seem to be more inclined towards keepinf the developers sweet than pushing them towards improving what is, in all honesty, a very expensive "work-in-progress".

Sorry devs, I still feel like my money was well-spent, but it has to be said that you're behind the curve when it comes to performance.


Intel Mac optimizations?