[Warhaven]

... $9100 for 32GB RAM upgrade? Wtf? How about $2600 for 32GB from buy.com. With how much Apple charges, it's no wonder it's sold out.

You could get a whole 'nother system with how much you'd save on the RAM.

[Art Vandelay]

Wrong kind of memory. The Mac Pro and Xserve require FB-DIMMS.

[analogue SPRINKLES]

Apple has always charged waaaaaay too much for RAM. Just don't buy it from them. Simple.

[osiris]

That's been a no-brainer for a while. There's some serious markup going on there.

8 cores... drooool.

[torsoboy]

Originally Posted by osiris 

8 cores... drooool.

Do you get the benefit of 8 cores on regular applications or does the application have to be written for that specifically? It seems that most things wouldn't benefit from it.

[subego]

Originally Posted by analogue SPRINKLES 

Apple has always charged waaaaaay too much for RAM. Just don't buy it from them. Simple.

I have a hazy recollection of Apple having competitive prices for memory back in 2000.

That was also one of the few periods where I'd say you could get an iMac for cheaper than an equivalent PC.

I bought two.

[indigoimac]

Originally Posted by torsoboy 

Do you get the benefit of 8 cores on regular applications or does the application have to be written for that specifically? It seems that most things wouldn't benefit from it.

The programs have to be multi-threaded, just about all of Apple's stuff is, same w. Adobe.

Originally Posted by subego 

I have a hazy recollection of Apple having competitive prices for memory back in 2000.

That was also one of the few periods where I'd say you could get an iMac for cheaper than an equivalent PC.

I bought two.

I bought 1, but I wouldn't say their RAM prices were very competitive at the time, maybe amongst OEM suppliers, but not when compared to Other World or other 3rd parties.

And 32gigs of the right RAM for 2650
32.0GB Mac Pro Memory Matched Set (4GB... (OWC53FB4MPK32GB) at OWC

[goMac]

Originally Posted by indigoimac 

And 32gigs of the right RAM for 2650
32.0GB Mac Pro Memory Matched Set (4GB... (OWC53FB4MPK32GB) at OWC

That RAM doesn't fit the new Mac Pro. You need 800 mhz memory.

[analogika]

GamePC - Apacer DDR2-800 2 GB FB-DIMM

$4200 for 32 GB, but those are 2GB sticks, not 4GB.

[mduell]

Originally Posted by goMac 

That RAM doesn't fit the new Mac Pro. You need 800 mhz memory.

It fits, and even works (if Apple hasn't gone out of their way to cripple the chipset), just fine in the new Mac Pros. About 17% less memory bandwidth than 800Mhz, but the Intel 5400 chipset supports both speeds.

[Helmling]

Oh my god, I hadn't heard.

I just soiled myself...those things are insane.

Can't help but notice that there's still nothing better than a SuperDrive! How long until we get some Blu-Ray action here, Apple?!?

[Helmling]

Oh, and this is interesting coming the week before Mac World.

These beasts weren't even worth mentioning in the Keynote next week? Must be something pretty good up Jobs's sleeve.

[- - e r i k - -]

Are Mac Pros ever included in Macworld keynotes? Only time I can remember a keynote being about pro machines was when they released G5s.

[Lateralus]

Why is this thread in the Lounge?

[imitchellg5]

Originally Posted by - - e r i k - - 

Are Mac Pros ever included in Macworld keynotes? Only time I can remember a keynote being about pro machines was when they released G5s.

Not often. NAB or other events normally cover the Mac Pro.

[mduell]

OWC now has Mac Pro compatible 800Mhz FB-DIMMs... about $100/GB instead of Apple's $250/GB.

[ghporter]

I agree with Lateralus-why is this in the Lounge? It's about the new Mac Pros and their stratospheric memory (both amount and price), right?

[chris v]

Originally Posted by ghporter 

I agree with Lateralus-why is this in the Lounge?

Well then, move it.

32 GB. Crimony day. My dual 2.0 is finally starting to look a bit old.

[mduell]

The machines should support 64GB as soon as someone gets those 8GB FB-DIMMs out; the chipset supports 128GB in 16 slots.

[henjin]

I was told by sales at Apple that all the new MacPro have their CPUx2 soldered or worse to the motherboard! Was this some kind of crazy sales pitch to make my at least buy the 3ghz?
I was about to order so I could have the base system arrive for Friday. And I had been waiting. And I was going to update Logic Pro, FCStudio and so on.
I had the idea of buying the dual 2.8 and then when the prices come down dropping in a 3.2ghz as part of my usual Mac Desktop upgrade path.
I know Apple needs to make money but they are hardly suffering and I need to make money too. I recently bought an HP blackbird 002 gaming desktop which is amazing and can be upgraded across the motherboard. Also HP Xeon workstations can have their dual CPU upgraded.
I could not bring myself to buy. My partner refused to release the funds and we're looking into buying an Avid system...

Surely I am wrong... without being rude... please tell me I am wrong and it's possible to drop in new cpu.

[mduell]

Anyone know if Apple is using the cheaper ($956) 120W part (X5472) or the more expensive ($1022) 80W (E5472) part for the 3Ghz model?

Originally Posted by henjin 

I was told by sales at Apple that all the new MacPro have their CPUx2 soldered or worse to the motherboard!

Intel ARK doesn't even list a solderable Xeon part. I'm pretty confident they're all socketed and upgradeable.
What's worse than soldered?

[Don Pickett]

Originally Posted by indigoimac 

The programs have to be multi-threaded, just about all of Apple's stuff is, same w. Adobe.

Adobe's multi-core support is anemic at best. They've done some hacking for Photoshop, but Illustrator, ID and (most frustratingly) Distiller are still retarded.

[henjin]

Originally Posted by mduell 

Anyone know if Apple is using the cheaper ($956) 120W part (X5472) or the more expensive ($1022) 80W (E5472) part for the 3Ghz model?



Intel ARK doesn't even list a solderable Xeon part. I'm pretty confident they're all socketed and upgradeable.
What's worse than soldered?

Why would Apple tell me that it is soldered? By worse she suggested that even if I undid the solder it ... "be like a lobotomy" ....

There is no difference between intel products for notebooks that say Dell or Apple decides to solder onto the board. So not sure what you mean.

But thanks for answering... it seems that perhaps the Apple rep did not know what she is talking about... I hope but until I know... no buy.

Does anyone know for sure?

[Tesselator]

Originally Posted by torsoboy 

Do you get the benefit of 8 cores on regular applications or does the application have to be written for that specifically? It seems that most things wouldn't benefit from it.

I upgraded my MacPro from a 4-core 2.66 to a 8-core 2.66 for about $750 (before selling the old
chips) and have been using it for a loooong time now.

Applications that are not multithreaded do benefit and the scaling is linear. Almost everything will
"go" twice as fast on 8 as it did on 4. The deal is though that a multi-threaded application will "go"
6 or 7 times the speed as a non multithreaded app on a 8-core and 3 to 3.5 times faster on a 4-core.

So while both multithreaded and non-multithreaded apps scale linearly at aprox 0.99 per processor
core the two scales are at very different levels.

A typical non-multithreaded app on my 8 core 2.66 moves as if it's on a single proc at about 7.5Ghz.
A typical non-multithreaded app on my 4 core 2.66 moved as if it were on a single proc at about 4.0Ghz.

A typical multithreaded app on my 8 core 2.66 usually moves as if it's on a single proc at about 20.5Ghz ~ 21.0Ghz.
A typical multithreaded app on my 4 core 2.66 usually moved as if it were on a single proc at about 10Ghz ~ 10.5Ghz.

--
PS: No CPU on ANY MacPro is soldered - they are all socketed and the CPUs between ALL MacPro models are interchangeable!
PS: PS: Apple Reps and Genius Bar employees lie. They are NOT merely mistaken... They actually lie on purpose - and in MANY
different countries the lies are the same across the board. For this reason I /assume/ that Apple is instructing their employees
to lie or to "use any means" to achieve the result of informing you that your Macs are NOT upgradable when in fact they are.

[newtech]

[QUOTE=mduell;3573002]Anyone know if Apple is using the cheaper ($956) 120W part (X5472) or the more expensive ($1022) 80W (E5472) part for the 3Ghz mod

Seeing as the 3.0 shares the 2.8 MLB and cooling components it is a safe bet it uses the E5472 ( 80W TDP ), the 3.2 ( X5482 120 W TDP) uses uprated cooling components and has a different part number for the MLB.

All 5000 sequence Xeon processors are LGA 771/socket J not soldered to the board in any sense.

[Photocro]

The question is: what do you REALLY need. Are you drooling over the latest and greatest or just being a business person and watching the overhead.

[rnicoll]

Originally Posted by Tesselator 

Applications that are not multithreaded do benefit and the scaling is linear. Almost everything will "go" twice as fast on 8 as it did on 4. The deal is though that a multi-threaded application will "go" 6 or 7 times the speed as a non multithreaded app on a 8-core and 3 to 3.5 times faster on a 4-core.

Single threaded applications only benefit in terms of other applications/the OS can use a different core, so there's less overhead. Generally they may seem more responsive, but you're unlikely to see a significant speed boost (and if you do, it is due to not having to share resources, rather than it being able to use more than one core directly).

[Leonard]

Originally Posted by henjin 

Why would Apple tell me that it is soldered? By worse she suggested that even if I undid the solder it ... "be like a lobotomy" ....

Because they are salespeople and not engineers or computer geeks! If you want real info on the machines you talk to an engineer, which of course you can never talk to at Apple.

Do you believe everything BestBuy or other electronic stores' salespeople tell you?

[MarkLT1]

Originally Posted by Tesselator 

Applications that are not multithreaded do benefit and the scaling is linear. Almost everything will
"go" twice as fast on 8 as it did on 4. The deal is though that a multi-threaded application will "go"
6 or 7 times the speed as a non multithreaded app on a 8-core and 3 to 3.5 times faster on a 4-core.

So while both multithreaded and non-multithreaded apps scale linearly at aprox 0.99 per processor
core the two scales are at very different levels.

Bwahahahaha.. now that is rich.

I make my living writing parallel code.

1) If an application is not multi-threaded, and doesn't use MPI, it can only make use of a single processor, period. There is no speed-up for a non-multithreaded, non-mpi app with multiple cores, other than the fact that on a multi-core system, you may have an entire core that is 100% free used by your process (think: OS and other junk on one core, your app on the second core). Once that core is saturated, however, that is all she wrote.

2) Anything even approaching linear scaling for multi-threaded or MPI apps is pretty much the "Holy Grail" of parallel programming. Unless a problem is embarrassingly parallel, you probably wont see speed-ups even close to linear.

If your machine is really showing linear increases in speed for all of your apps, you can probably make quite a bit of money with it, and scientists around the world would love to see it, as it not only breaks all of the barriers set in front of parallel programmers, but also completely defies logic.

[MacosNerd]

Originally Posted by Leonard 

Because they are salespeople and not engineers or computer geeks! If you want real info on the machines you talk to an engineer, which of course you can never talk to at Apple.

Do you believe everything BestBuy or other electronic stores' salespeople tell you?

There was an old joke floating around when I worked at a computer store back in the day.

What's the difference between a car salesman and a computer salesman.

The car salesman knows what he's talking about.

[Tesselator]

Originally Posted by MarkLT1 

If your machine is really showing linear increases in speed for all of your apps, you can probably make quite a bit of money with it, and scientists around the world would love to see it, as it not only breaks all of the barriers set in front of parallel programmers, but also completely defies logic.

I've heard this before too. I think you're overlooking something.

The typical non-multithreaded app uses about 33% of all processors -1. So if there are 8 cores
it uses 33% of seven cores or 33% of 3 cores in the case of a 4-core box. This mostly (but not
always) the case and why I said "typically". About 5% of the apps I have (and I have about 400gigs
occupying the Applications folder) installed will for some reason use only one core - and usually
those never max out the core it's assigned to. Typically <80%. So there seems to be 3 kinds of
scheduling with the VAST majority falling into the categories I outlined above.

So, how do I make this money you're talking about as my figures are both scientific and correct.

Although it's not perfectly linear, it IS very close at .98 or .99 for ALL multithreaded apps I have
tested and .90 to .97 from all non-multithreaded app I have tested. Close enough IMO to go ahead
and call it linear.

[mduell]

Originally Posted by henjin 

Why would Apple tell me that it is soldered? By worse she suggested that even if I undid the solder it ... "be like a lobotomy" ....

There is no difference between intel products for notebooks that say Dell or Apple decides to solder onto the board. So not sure what you mean.

To try to scare you into an up-sell?
I'm not sure why you're bringing Dell notebooks into this... Intel offers both socketed and soldered mobile chips (Apple uses soldered for the MacBook/Pro and socketed for the Mac mini/iMac), but they only offer socketed workstation chips.

Originally Posted by Tesselator 

Applications that are not multithreaded do benefit and the scaling is linear. Almost everything will
"go" twice as fast on 8 as it did on 4. The deal is though that a multi-threaded application will "go"
6 or 7 times the speed as a non multithreaded app on a 8-core and 3 to 3.5 times faster on a 4-core.

A typical non-multithreaded app on my 8 core 2.66 moves as if it's on a single proc at about 7.5Ghz.
A typical non-multithreaded app on my 4 core 2.66 moved as if it were on a single proc at about 4.0Ghz.

In short, you've got it completely wrong. A single-threaded app will be just as fast on a dual core machine as a quad core machine as an 8 core machine.

[Tesselator]

Originally Posted by Warhaven 

... $9100 for 32GB RAM upgrade? Wtf? How about $2600 for 32GB from buy.com. With how much Apple charges, it's no wonder it's sold out.

You could get a whole 'nother system with how much you'd save on the RAM.

Just so that ALL my posts in this thread aren't off-topic I think this is a pretty good deal on MacPro
memory: Item Info at OtherWorldComputing.com

$155 for 4 Gigs. (although those are 2gig SIMMS )

[rnicoll]

Originally Posted by Tesselator 

I've heard this before too. I think you're overlooking something.

The typical non-multithreaded app uses about 33% of all processors.

The term is single threaded. This is because it has one single thread. Each thread can only run on a single processor at a time. As such, a single threaded application uses a single processor. It will continue to use a single processor, irrespective of how many processors you add.

Scaling depends on the interaction between the threads. If the task being performed can be sliced neatly into pieces that do not depend on each other, it will scale near perfectly. On the other hand, if threads depend results from other threads, scaling will be quite poor. Consider the calculation:

(1 + 1) * (2 + 2)

There's three parts here:

1. Calculate 1 + 1
2. Calculate 2 + 2
3. Multiply the results.

Each of these can be a separate thread, but because the third depends on the results of the first two, it makes no difference, and you might as well use two threads. Make sense?

[MarkLT1]

Originally Posted by Tesselator 

I've heard this before too. I think you're overlooking something.

The typical non-multithreaded app uses about 33% of all processors -1. So if there are 8 cores
it uses 33% of seven cores or 33% of 3 cores in the case of a 4-core box. This mostly (but not
always) the case and why I said "typically".

If only that was the way it worked. A single-threaded app, can only use up to 100% of 1 core. So if you have a 4-core, 2.66ghz machine, it can use up to (but not exceeding) 100% of a 2.66ghz core. Now, if you have an 8-core, 2.66ghz machine, it can use up to (but not exceeding) 100% of a 2.66ghz core. Notice that both processes are using the same size/speed resource. A single thread, can not span multiple processors, so there would be no way for the single thread to use 33% of all 8 cores. How are you coming up with these percentages anyway? And why the magical "33%" value? It makes no sense.

So, how do I make this money you're talking about as my figures are both scientific and correct.

Actually, they are not. Your claims make no sense at all when it comes to how a threaded or non-threaded app is run. A single thread can only be on a single processor. So a non-threaded app can only run on ONE processor.

Although it's not perfectly linear, it IS very close at .98 or .99 for ALL multithreaded apps I have tested and .90 to .97 from all non-multithreaded app I have tested. Close enough IMO to go ahead and call it linear.

And what "multi-threaded" apps are these? If you are looking at 3D or video rendering applications, then yes, you may see close to linear speed increases, as they are typically embarrassingly parallel algorithms.

[Tesselator]

Originally Posted by mduell 

In short, you've got it completely wrong. A single-threaded app will be just as fast on a dual core machine as a quad core machine as an 8 core machine.

Well those numbers are based on actual tests so I dunno what to say. Was I testing really really
crappy multithreaded apps that claimed not to be multithreaded at all? <shrug>

[thetman]

Originally Posted by Tesselator 

PS: PS: Apple Reps and Genius Bar employees lie. They are NOT merely mistaken... They actually lie on purpose - and in MANY
different countries the lies are the same across the board. For this reason I /assume/ that Apple is instructing their employees
to lie or to "use any means" to achieve the result of informing you that your Macs are NOT upgradable when in fact they are.

It's not lieing. They are omitting the word "user" upgradeable. It would be bad for them to tell a Mac Pro user that he can upgrade his Xeon processors only to have him come back later with a machine that won't turn on because he tried to put 2 CPUs in that aren't compatible. He/she is covering his butt.

[rnicoll]

Originally Posted by Tesselator 

Well those numbers are based on actual tests so I dunno what to say. Was I testing really really
crappy multithreaded apps that claimed not to be multithreaded at all? <shrug>

More likely something else changed in the move from a single core to multicore system. Want to give us details of the hardware you tested, applications you were testing with, times for each test, test dataset, and what you were running at the same time?

[MarkLT1]

Originally Posted by Tesselator 

Well those numbers are based on actual tests so I dunno what to say. Was I testing really really
crappy multithreaded apps that claimed not to be multithreaded at all? <shrug>

Probably not.. but what was your testing method? Benchmarking is more an art than a science, and many times people dont benchmark the same thing.

[thetman]

Originally Posted by MacosNerd 

There was an old joke floating around when I worked at a computer store back in the day.

What's the difference between a car salesman and a computer salesman.

The car salesman knows what he's talking about.

here is the reason for that - pay someone $8 dollars an hour with no incentives to make a sale, or pay someone more money plus commission and see who cares more about their job

[Tesselator]

Mark Wrote:
If only that was the way it worked. A single-threaded app, can only use up to 100% of 1 core. So if you have a 4-core, 2.66ghz machine, it can use up to (but not exceeding) 100% of a 2.66ghz core. Now, if you have an 8-core, 2.66ghz machine, it can use up to (but not exceeding) 100% of a 2.66ghz core. Notice that both processes are using the same size/speed resource. A single thread, can not span multiple processors, so there would be no way for the single thread to use 33% of all 8 cores. How are you coming up with these percentages anyway? And why the magical "33%" value? It makes no sense.

Hey, I never said I knew why.


Actually, they are not. Your claims make no sense at all when it comes to how a threaded or non-threaded app is run. A single thread can only be on a single processor. So a non-threaded app can only run on ONE processor.

Now see to me that makes no sense and is almost never my experience. The 1st portion of this
graph represents a non-multithreaded app running all out. Notice the average usage is about 33%
on each core. It's not a magic number. Sometimes it's 25% other times it's 36%. The app appears
to be time sliced across all 8 cores (usually there is one core left at 5% or less and thus I said "-1"
above. Then a multithreaded app is started and as you also see it utilizes 100% of all 8 cores.





And what "multi-threaded" apps are these? If you are looking at 3D or video rendering applications, then yes, you may see close to linear speed increases, as they are typically embarrassingly parallel algorithms.

Yes, Maya, Lightwave3D, Modo, C4D, are the tools I use to test with and what I use most professionally
as well. This graph is a "SlickMotion" render (single threaded app AFAIK) followed by a LightWave 3D
UB (multithreaded - threads set to 8) render.

[Tesselator]

Originally Posted by rnicoll 

More likely something else changed in the move from a single core to multicore system. Want to give us details of the hardware you tested, applications you were testing with, times for each test, test dataset, and what you were running at the same time?

I started out on a MacPro 2.66 stock 4-core system. I opened it up and dropped in a pair of X5355
to make it a MacPro 2.66 8-core system.

[Tesselator]

Originally Posted by MarkLT1 

Probably not.. but what was your testing method? Benchmarking is more an art than a science, and many times people dont benchmark the same thing.

Yeah, I've been computing for a loooog time now. I started out before there were such things as
PeeCees - yup me is ancient! I started on a PDP1 in early 70's. I went the CBM and Amiga rout
till they went bust and then to Mac/PCs. I wrote for DoD in CPM, a few games on C=64 and two
on the Amiga. Doesn't mean that I know everything but I guess I can benchmark apples to apples.
I know a little about multi-tasking but not much about multi-processor code. <shrug>

[MarkLT1]

Originally Posted by Tesselator 

Ahhh, there is your problem- activity monitor doesn't show you nearly enough to know what is going on. Try this-

Open up the terminal. In the terminal type "top -u" and hit return.

Now, run your non-threaded app (dont run anything else). You should see the "CPU percentage" of your app in the list in your terminal window. Now, this CPU percentage is for a single core. I.E.- if that one app is running on multiple cores, and is using more than a single CPU, you will see a CPU % for that app of greater than 100. For example, when I am running one of my simulations that has a nearly linear speedup (it is embarrassingly parallel) on my 4-core system, I'll see 360-370%. If your non-threaded app never exceeds 100%, it is only using 1 CPU. Also, note the "CPU usage" statistic on the second line. This shows the total usage on the system, so 100% would mean all 8 cores, totally in use. My guess, if your non-threaded app is taking up 100% of one core, and you aren't running much else, is that your CPU usage stat at the top will show somewhere around 12-14% user.

By your account, that the one process is using 33% of all 8 cores, should show a 33% usage of the total system, and should show a process usage percentage of ~264%

[Tesselator]

rnicoll Wrote:
The term is single threaded. This is because it has one single thread. Each thread can only run on a single processor at a time. As such, a single threaded application uses a single processor. It will continue to use a single processor, irrespective of how many processors you add.

Is that the term? Not to be rude but then what do you call an app that utilizes one of the Core
facilities in OS X? Almost all apps do - or all worth using as benchmarks. Sure, a file compressor
application working on a single file might only use one processor. Even so I see a second one
kick in a bit for the RAID I/O and etc. So an app that uses Core Graphics for example - even tho
the app itself is non-multithreaded "single-threaded" doesn't seem to describe it very well either.


Scaling depends on the interaction between the threads. If the task being performed can be sliced neatly into pieces that do not depend on each other, it will scale near perfectly. On the other hand, if threads depend results from other threads, scaling will be quite poor.

Each of these can be a separate thread, but because the third depends on the results of the first two, it makes no difference, and you might as well use two threads. Make sense?

Sure. But why would anyone use poorly multi-threaded code to test the hardware scalability/ability?
To me the fact that coders aren't smart enough or paid well enough to come up with code that multi
threads better than "poor" is not a reflection on the system - but rather a reflection on the coders
ability and the state of current software engineering tools. I dunno, it's just how I look at it I guess.

[MarkLT1]

Sure. But why would anyone use poorly multi-threaded code to test the hardware scalability/ability? To me the fact that coders aren't smart enough or paid well enough to come up with code that multi-threads better than "poor" is not a reflection on the system - but rather a reflection on the coders ability and the state of current software engineering tools. I dunno, it's just how I look at it I guess.

In many cases it is not a matter of "smart" or a matter of technology. The cliche is "While 1 woman can have a baby in 9 months, 9 women can't have a baby in 1 month". In other words, many problems, processes, etc.. are serial in nature, and simply can not be parallelized. A very simple example is the fibonacci sequence: which goes 1 2 3 5 8 ... Each value is the sum of the two proceeding values. Lets say I task you with finding the 1 millionth Fibonacci value. Well, since you need to know all of the sums, up to the current value, you can not parallelize it at all- it is an inherently serial problem.

So, why benchmark on serial problems? Well, much of what we need to do can not be parallelized, so serial performance, from a desktop POV, is also very important.

As to what you would call something that does much of its processing using multi-threaded APIs or libraries- I call that multi-threaded. The issue is that while the multi-threaded APIs from the OS do help some, it usually isn't the bulk of the computation during a programs run time. Until the software developer actually takes the time to multi-thread their app, and not just rely on the various OS supplied APIs, they wont see much of a performance boost.

One other example I can give you is a truly single threaded app, that you have on your machine now, that uses no multi threaded APIs. It is a command line app (you can run from your terminal) called bc (basic calculator). Try this-

1) Open your activity monitor
2) Open a terminal window. At the command prompt type:
echo "scale=3000;4*a(1)" | bc -l -q
3) watch your activity monitor. What this is doing, is calculating the first 3000 digits of Pi. You'll notice that one processor will peg, and the others will stay idle.

[Tesselator]

Originally Posted by MarkLT1 

Ahhh, there is your problem- activity monitor doesn't show you nearly enough to know what is going on. Try this-

Open up the terminal. In the terminal type "top -u" and hit return.

Now, run your non-threaded app (dont run anything else). You should see the "CPU percentage" of your app in the list in your terminal window. Now, this CPU percentage is for a single core. I.E.- if that one app is running on multiple cores, and is using more than a single CPU, you will see a CPU % for that app of greater than 100. For example, when I am running one of my simulations that has a nearly linear speedup (it is embarrassingly parallel) on my 4-core system, I'll see 360-370%. If your non-threaded app never exceeds 100%, it is only using 1 CPU. Also, note the "CPU usage" statistic on the second line. This shows the total usage on the system, so 100% would mean all 8 cores, totally in use. My guess, if your non-threaded app is taking up 100% of one core, and you aren't running much else, is that your CPU usage stat at the top will show somewhere around 12-14% user.

By your account, that the one process is using 33% of all 8 cores, should show a 33% usage of the total system, and should show a process usage percentage of ~264%

Right that makes sense. I'm not trying to be difficult or anything but isn't that useful for process
profiling? Here the question is weather 8 processors are faster or not for apps that aren't multi-
threaded. I find generally that most apps (or most apps I use) are typically interacting with the
system components rather heavily. If one confines their benchmarks to the speed of a lone process
how is that a reflection of real world usage?

EDIT:
I wrote this before reading your response above. While this still a valuable consideration your
explanation (above) answers it to some degree.

[MarkLT1]

Originally Posted by Tesselator 

Right that makes sense. I'm not trying to be difficult or anything but isn't that useful for process profiling?

No worries.. its a good discussion (and a topic that I happen to be very vested in ). As for profiling, the plot itself that Activity monitor gives you is practically useless. There is much more detailed info in the app on a process by process basis that will give you a much better idea of what the machine is doing.

Here the question is weather 8 processors are faster or not for apps that aren't multi-
threaded. I find generally that most apps (or most apps I use) are typically interacting with the
system components rather heavily. If one confines their benchmarks to the speed of a lone process how is that a reflection of real world usage?

In my field, it happens to be huge. As I alluded to before, there are many processes that simply can not be parallelized, and I come across these every day. And your claim that 8 processors is faster for a non-multi-threaded app is false. If your processes is relying heavily on threaded components for the bulk of its computation, then for all intents and purposes it is a threaded app. If you try running the bc sample I posted, you will see that for truly non-threaded applications the number of processors does you little to no good.

Since you do a lot of work with rendering, and rendering is an inherently parallel problem (each frame can be rendered independently of the others- so if you had 10,000 cpus, you could render 10,000 frames independently, with no communication between processors), you are likely to see nice speed boosts with multiple processors (thus why multi-processor machines are targeted towards your market).

For something like, say, large scale weather simulations, multiple processors are beneficial, but you are very very far from having a linear increase in speed. While going from one processor to 4 may net me a 3x increase in speed, going from 32 processors to 128, may only see a 1.5-2x increase.

[Tesselator]

Originally Posted by MarkLT1 

In many cases it is not a matter of "smart" or a matter of technology. The cliche is "While 1 woman can have a baby in 9 months, 9 women can't have a baby in 1 month". In other words, many problems, processes, etc.. are serial in nature, and simply can not be parallelized. A very simple example is the fibonacci sequence: which goes 1 2 3 5 8 ... Each value is the sum of the two proceeding values. Lets say I task you with finding the 1 millionth Fibonacci value. Well, since you need to know all of the sums, up to the current value, you can not parallelize it at all- it is an inherently serial problem.

So, why benchmark on serial problems? Well, much of what we need to do can not be parallelized, so serial performance, from a desktop POV, is also very important.

As to what you would call something that does much of its processing using multi-threaded APIs or libraries- I call that multi-threaded. The issue is that while the multi-threaded APIs from the OS do help some, it usually isn't the bulk of the computation during a programs run time. Until the software developer actually takes the time to multi-thread their app, and not just rely on the various OS supplied APIs, they wont see much of a performance boost.

One other example I can give you is a truly single threaded app, that you have on your machine now, that uses no multi threaded APIs. It is a command line app (you can run from your terminal) called bc (basic calculator). Try this-

1) Open your activity monitor
2) Open a terminal window. At the command prompt type:
echo "scale=3000;4*a(1)" | bc -l -q
3) watch your activity monitor. What this is doing, is calculating the first 3000 digits of Pi. You'll notice that one processor will peg, and the others will stay idle.

Even this illustrates my point as well as yours. Here is the graph from

echo "scale=30000;4*a(1)" | bc -l -q //* Added a zero. 3000 finished much too quickly


As you can see even a simple calculation increases the system usage (red) in parallel and therefore
will preform better on a multi-processor system than a single core system. Such a simple task
however can't scale measurably beyond about 3 cores (?) let's say. And for sure scaling across
even two cores is quite poor. I guess it looks like

Priority 1 Core: 100%
Priority 2 Core: 10%
Priority 3 Core: 2%

Just for the activities of the actual math. Whatever system calls are being used are extra to that of
course. I guess most of the system activity is buffer handling and string assembly? So in conclusion
even in this example where one would expect no scaling at all some has indeed occurred. Now for
most "useful" utilities like sorting, adding, or IDCP tag editing my 253,782 songs in iTunes or video
sequence editing, etc. etc. we can or /should/ be able to compound this example and come up with
results much closer to my initial drivelings.

[Tesselator]

MarkLT1 Wrote:
No worries.. its a good discussion (and a topic that I happen to be very vested in ). As for profiling, the plot itself that Activity monitor gives you is practically useless. There is much more detailed info in the app on a process by process basis that will give you a much better idea of what the machine is doing.

Yeah, I find it interesting too. It just goes to show what huge nerds we are. And yes of course
there are much better techniques for profiling an app like using Activity Monitor's Sampling feature
for a start - etc..

In my field, it happens to be huge. As I alluded to before, there are many processes that simply can not be parallelized, and I come across these every day. And your claim that 8 processors is faster for a non-multi-threaded app is false. If your processes is relying heavily on threaded components for the bulk of its computation, then for all intents and purposes it is a threaded app. If you try running the bc sample I posted, you will see that for truly non-threaded applications the number of processors does you little to no good.

Yeah, true... perhaps all things considered 150% over one core.


Since you do a lot of work with rendering, and rendering is an inherently parallel problem (each frame can be rendered independently of the others- so if you had 10,000 cpus, you could render 10,000 frames independently, with no communication between processors), you are likely to see nice speed boosts with multiple processors (thus why multi-processor machines are targeted towards your market).

Yep. It's usually not frames per core tho.
Parallel rendering - Wikipedia, the free encyclopedia (frames per system or per core - embarrassingly parallel )
Scanline rendering - Wikipedia, the free encyclopedia (multi-core/frame)
Tiled rendering - Wikipedia, the free encyclopedia (multi-core/frame)
Bucket rendering - Wikipedia, the free encyclopedia (multi-core/frame)


For something like, say, large scale weather simulations, multiple processors are beneficial, but you are very very far from having a linear increase in speed. While going from one processor to 4 may net me a 3x increase in speed, going from 32 processors to 128, may only see a 1.5-2x increase.

Yes, it's less. But I see better scaling than that in fluid dynamics (simulations) or hard/soft body
dynamics (simulations) in /some/ apps.. I can often see .9 scaling from four to eight cores with
such tasks.

I only WISH I had a 32 core box to test with so I can't really say. But if the nodes are local bus I
would imagine better than 2x from 32 to 128 cores... no? That sounds reasonable for fiber channel
networked nodes tho.