Tiger Chasing Tail? Hold off on 8 core macs!!

[Greg Voevodsky]

Check out this thread (below)

This is another strong argument for waiting till the last moment to upgrade your Mac. I wish Apple could be as straight forward as RED.

I wonder if the PCs are doing any better with their 8 cores though? Any news?

http://www.barefeats.com/octopro1.html

[Bruce Allen]

Check out this thread (below)
I wonder if the PCs are doing any better with their 8 cores though? Any news?
http://www.barefeats.com/octopro1.html

PCs have successfully used 8 cores for many years, with varying degrees of success. They've had quads working well for ages - I remember doing Mental Ray renderings at an animation company in South Africa on a Quad 200mhz (or so) Pentium Pro in 1998. It gave the Onyx in the Flame bay next door a real scare sometimes ;)

I'm sure Apple will get the OS tuned for 8-core soon. But certain software will take longer to multi-thread. Others will be almost impossible to multi-thread. And there will always be a law of diminishing returns.

In terms of buying times, bear in mind that 16-core with on-board memory controllers (which could really alleviate the bottleneck) is coming near the end of next year. Beyond that, there is more doubt as to whether the crazy pace will continue as there is a sad but quite high chance that AMD might have fallen behind too far for Intel to feel the pressure to continue at a rapid pace. So, stagnation in 2009? Hope not.

Bruce Allen
www.boacinema.com

[PaulClements]

That performance test doesn't make sense to me really.

What they are saying is the octo and quad are the same if the work being done is memory based... but then they both have 16GB memory so surely that explains that?

They then say that if it is cpu based that the octo will be twice as fast... That's because there is twice the ammount of cpu in the octo than the quad.

Isn't this just stating the facts?

The software needs to be changed to use the cpu's more than the memory in my opinion, perhaps I'm missing something here... anyone care to chime in and explain it to me lol :)

[Anders Holck]

What they are saying is that operations that need to access main ram to fetch and put data are hit by the speed of the memory bus. Calculations that fit nicely in the onboard cache is not affected as this runs at higher speed.

So according to their theory Applications that fetch a lot of data, do milder calculation, and put it back is going to suffer.

Photoshop is very memory intensive, so it could seem like that is the case.

[Clayton Harper]

What they are saying is that operations that need to access main ram to fetch and put data are hit by the speed of the memory bus. Calculations that fit nicely in the onboard cache is not affected as this runs at higher speed.

So according to their theory Applications that fetch a lot of data, do milder calculation, and put it back is going to suffer.

Photoshop is very memory intensive, so it could seem like that is the case.

The Adobe CS design team has said as much on their blogs. There are many operations that get no faster (or even slower) when the work gets divided and thus bottlenecked.

I just wish the old 2.66 quad had dropped in price a little. I seriously think this is a ploy by apple to renew interest in the old machines for people who were waiting for the intel-based Adobe suite. I promise you we'll get architecture changes on the next rev after all those design firms who were waiting buy their machines.

[Gunleik Groven]

I think the 8-core is a good idea -;)
And I'll just hang in here untill NAB to see what's happening.

I could set squeeze, compressor, quicktime and Episode pro to encode videos on this machine without ever hitting the RAM bottleneck, and as this is the kind of machine I'm currently shopping for (an encoder) I might just get one for that task alone.

Hey.
I could farm out all my Shake renders, and still edit happily on my old G5.

I think I have never seen one upgrade to the topline macs - except maybe for the G5 dual when it came out - that haven't called out the dismay of the test sites. Yet I have never regretted buying the current top-of-the line Mac - if for nothing else - the pure lifespan these machines have been giving me. 4 years of beating is quite cool - and that is on the average for buying the top of the line desktop or laptop at the moment.

It's a bit like with the Red:
"But it cannot do 120 fps @ 4k"!

Well, so what.
If I had even sugested 120 fps @ 4k for myself a year ago, I would have made me a laughing stock.

I could use a Red, probably in its most beta and unfinished stage right now. And it would make me money. Even if it was specked at "only" 1080p/4:4:4/@ 25 fps.

So:
I could use one very much today - thank you - for the tasks I need it for.
A Red edit bay?
Dunno.
Don't have a Red yet, so I'll just wait and see for that.

& wait for NAB.

Just my 2c

Gunleik

[Zakaree Sandberg]

im a mac person.. dont get me wrong.. the only PC i have or "PC's" i have are supped up gaming systems to run my home Flight Simulator..(ps when not filming i literally sit in the simulator flying real time flights.. for HOURS).. anyways...
im starting to think an awesome 8core PC would be cheaper and more easily upgradeable/fixable... final cut and premier are close enough and i can relearn avid/ learn avid and use a pc for my edit workstation... ill still have my final cut on a duel g4 but mainly for dv projects i guess..

im not trying to get in a pc.. vs mac debate.. i already know mac is the shit..
but in terms of cost and value.. should i try and get a awesome PC for less? and still be able to edit 4k redcode? or bite the bullet and go mac again...

im already in the negatives as far as money goes.. its gunna take some time to regain from this acquisition. Unless i rent for the max amount every week.....

[Chris Kenny]

If you're looking to buy a high-end Xeon machine, you won't find many options much cheaper than the Mac Pro. If you'd be fine with a less powerful tower, the Mac might not be the best choice, because Apple just doesn't sell any less powerful towers.

Really though, I think a high-end tower is likely to pay for itself pretty fast for anyone working with a Red.

[Zakaree Sandberg]

TRUE.. my thing is im mainly a DP/OP not so much into editing.. although sure i shoot my own lil projects.. but i dont edit for a living..

[Hrvoje Simic]

I don't think a PC variant would cost you any less. And soon you'd be stuck with memory sucking Vista. My friend does hardware tests for computer magazine and he's prety pissed with Vista's hardware requirements. I would really like to see similar configuration's rendering and cost comparisons. The only thing stopping me from ordering 8 core right now is lousy graphics situation.

[Vincent Rice]

Leopard should bring significant improvements to thread ordering, reducing the memory bottleneck.

[Jeff Kilgroe]

Yes, Leopard should make some great strides in thread scheduling. In reality, Tiger was only designed for dual-core operation with later add-on optimizations (kinda) for 4 CPUs/cores.

OTOH, we have to consider the current state of quad-core CPUs being used in 8-core systems. They're not true quad-core CPUs. Current Intel offerings are dual Woodcrest 2-core CPUs on a single die. The first two cores can't communicate with the second two cores without transferring data over the CPU FSB. We won't see unified quad-core CPUs until late this year or early next year.

The bus snooping and probing design on the current Intel CPUs is a little brain-dead. Both dual-core dies on a Clovertown CPU do their own snooping and monitoring when there's no need. This increases latency, but the problem won't be solved until the unified core designs arrive.

We also have the decision by Apple and many other system vendors to use FB-DIMM memory. It makes sense from the point of view of installing reliable memory in capacities greater than 8GB. However, it has much lower latency and initiation times than other forms of memory out there. It's also a little hard on the wallet of consumers. I understand the choice of Apple to use FB-DIMMs, but it would be nice if Apple could offer a mid-range pro system between the iMac and the Mac Pro. Not everyone needs the ability to install 16~32GB of RAM or some of the other Mac Pro options.

FWIW, most 8-core PCs struggle from all of the same issues of the 8-core Mac Pros. And in many cases to a greater degree. I also don't think the Barefeats testing was that accurate or reliable and more rushed.

[Bruce Allen]

Leopard is delayed until October because Apple decided to reassign programmers working on Leopard to the iPhone version of OSX in order make sure the iPhone ships on time.

This is not a joke.

Bruce Allen
www.boacinema.com

[Jeff Kilgroe]

Bastards.

Doesn't surprise me though. The last Leopard build I saw (current about 3 months ago) was still quite buggy and incomplete. I let my ADC membership expire last June so I haven't getting builds myself.

Apple better get this whole iPhone thing out of the way so they can get back to producing some real products.

[Chris Kenny]

In terms of taking advantage of eight cores, it basically all comes down to the apps. If an app isn't doing something in at least eight threads, there's really not much (within current software architectures) that an operating system can do to get it to take advantage of eight cores. Operating system vendors can help by making sure their own code (e.g. QuickTime) is well threaded, and they can tune their kernels to minimize barriers to parallel execution, but that's about it.

Fortunately, most video processing tasks are very easy for developers to parallelize. Want to use eight cores? Just process eight frames at once. You don't have to rewrite algorithms or deal with messy synchronization issues.

[Bruce Allen]

I agree in terms of a pragmatic "performance per programmer-hours" way, assigning each thread to its own frame is good because the programmer can spend less time fighting tricky thread issues and can spend more time optimizing their core loop using time-honored methods.

However, here are two disadvantages of processing 8 frames at once versus using 8 cores to process parts of one frame:
1. It doesn't help interactity as much (when you're tweaking a filter's slider and looking at a frame change, only one core out of the 8 cores is working)
2. It's not the most bandwidth-efficient / anti-cache-thrashing way to do things (especially with the current Intel architecture)

The main problem mentioned on BareFeats was that the current Mac OS kept moving threads between cores - in theory this would suck if you were rendering 8 frames at once because each time the thread migrates to a new core you'd need to re-populate the cache.

Of course, in practice, it may make very little difference!

Bruce Allen
www.boacinema.com

[Jeff Kilgroe]

In terms of taking advantage of eight cores, it basically all comes down to the apps. If an app isn't doing something in at least eight threads, there's really not much (within current software architectures) that an operating system can do to get it to take advantage of eight cores.

There's actually quite a bit the OS can and needs to do in order to handle proper thread scheduling and prioritizing of threads/fibers and multiple CPU cores. Applications can't be written with the expectation that they'll be aware of other applications and threading models already in place and operating on a system. Efficiency is lost when you have an 8-core system and two apps running simultaneously trying to distribute themselves across 4 to 8 cores at any given time. If there's no direct intervention or process and thread scheduling at the OS/kernel level, then well.... Hey! that's what we have right now, nada... Or close to it.

This is something that OS developers will have to take more seriously now that multiple CPUs are becoming common in larger and larger numbers. I suppose that if they ignore the issue long enough, people will get by and eventually when there's 60 cores in a system, then Word Photoshop and Maya can all find a happy home somewhere.


Fortunately, most video processing tasks are very easy for developers to parallelize.

Yep. No real worries there... Having multiple processors/cores has always been a good thing for rendering tasks. Process multiple frames at once or multiple segments of a frame at once or however you want to break it down. A lot stands to be gained from a more involved multi-threaded approach though. Some tasks such as interpolations are not so linear or parallel.

[Jeff Kilgroe]

The main problem mentioned on BareFeats was that the current Mac OS kept moving threads between cores - in theory this would suck if you were rendering 8 frames at once because each time the thread migrates to a new core you'd need to re-populate the cache.

This is a real problem with Windows too... And not really fixed in Vista. But this is what I was getting at with the OS intervention, scheduling and thread management. When an application spawns a thread, it's up to the OS to allocate resources and a CPU pathway for execution of that thread. The only way for an application to dictate which CPU(s) the thread(s) will operate on is by assigning affinity to one or more desired CPU(s). This is restrictive and can become problematic if the application can't be aware of assigned affinity of other applications (currently a problem with OSX, Windows and Linux). It's not user-friendly for the person operating the computer to configure and assign affinity for each application either. Although it's something us multiprocessor users have had to do from time to time over the years. I've got a free utility on my site for Windows that will do just this (assign affinity and priority to an application when launching it) since Windows still has no options or parameters to set for such a thing.

In the case of systems like the new Intel 8-core workstations, the benchmarks at Barefeats tell a lot. Without proper thread scheduling at both the OS and application level we're seeing bandwidth and collision issues. In situations where threads complete and leave data in CPU cache for cores 1&2, but a new thread spawns and needs that data and is allocated to core #4, that data must pass out of the CPU cache, over the FSB and into the cache for cores 3&4 before execution. Some of this is made worse by the non-unified design of the Clovertown quad-core CPUs.

But this also brings up some commentary that sprouted up at Intel's IDC last year. Perhaps system vendors and/or mainboard and chipset makers will need to provide proper BIOS or EFI profiles for CPU configurations and optimal thread scheduling. Or perhaps vendors will need to provide thread scheduling profiles in the form of an OS driver or template. After all, how is the OS to know whether a system has unified quad-core CPUs or CPUs with two dual-core processors on each CPU die that can only communicate over the FSB instead of through onboard cache?

[Chris Kenny]

There's actually quite a bit the OS can and needs to do in order to handle proper thread scheduling and prioritizing of threads/fibers and multiple CPU cores. Applications can't be written with the expectation that they'll be aware of other applications and threading models already in place and operating on a system.


Yes, you're right. I was thinking mostly of the single app scenario.