Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Single Processor only for the new Pro?
- Thread starter JesterJJZ
- Start date
- Sort by reaction score
8GB dimms could still be over $400 each in the first half of 2011. I agree with you about ripoff vendors. I would add any that sport massive heatsinks and weird names
.They put a spoiler on the ram!
Shocking. OS X specific software should be optimized to run fastest on Macs. Why woud Apple be motivated to do that?
No. If they succeed the whole Mac line up will be more powerful in their respective market positions. All of them. Since as of 10.9, they are all capable of OpenCL any OpenCL speed up will potentially enhance performance on all Macs. The impact is bigger on the Mac Pro because it has two of the highest performaning GPGPUs. But as of 2013 all Macs have GPGPUs. Most of the "Pro" line up ( MBP + MP ) and the iMacs will have two.
Again if they success this is limited to the entire Mac market which currently stands at 6-10% of the overall PC market. That is actually substantially larger (by approaching an order of magnitude) than the Pro workstation market.
Because frankly, if engaging in a "core count war", the GPGPUs are leaving CPUs in the dust. Go price how much 7 TFLOPS of just pure x86 Xeons E5s will cost you. (leaving the Xeon Phi off the table) A E5 2690 is about 390-400 GFLOPs. You'd need 10 to get to 3-4 TFOPs and another 20 to get to 6-8 Peak.
That is one reason there are two. Split data set up and process concurrently. Frankly to get linear speed up on x86 the data has to be tiled and work distributed also.
There is less copying but if the FLOPs throughput is significantly different it can be a reasonable trade-off.
It isn't so much overhead ( although status quo can be giant inertia for companies with limited development resources. ) but wide spread, almost ubiquitous availability.
Frankly any academic software that doesn't want to run on GPGPUs systems also doesn't want to run on the top 10 of the TOP500 supercomputer list. In about a year that is going to be doesn't want to run on the top 20. Couple years later top100.
When the new list comes out later this month and look at the new monster on top come back tell how GPGPUs are having limited impact. ( it will probably be an x86 based GPGPU, but those aren't "normal" x86 cores. )
It is going to happen over a broader range because relatively quickly Nvidia is going to go to second place in most widely deployed OpenCL infrastructure. Intel is going to power right past them and it won't take more than 12 months. CUDA basically wil be put into the niche postion relatively quickly.
There are going to be extremely high priced software that will attempt to mutate/skew the hardware bought to run it. Those software vendors will chase smaller and smaller niches. Software vendors who actually want a broad user base will be unwinding themselves as fast a possible from CUDA. For many it will take some time but it will start happening.
This tends to be the vendors who are skewing themselves into a corner of higher cost hardware and fewer customers.
That happens. How many older software packages are fully going to exploit the new 256-bit fused math pipeline of the new E5 v2's. Few if any.
It isn't whether it is initially not used. It is whether long term there will be no use for it. if buy a machine that goes to 100% optimization and utilization the day you plug it in then probably will have to buy a new machine very soon. That isn't the profile of most Mac Pro users.
It is aligned with current pricing. The top end 8 cores are in the $1723-2057 zone
http://www.cpu-world.com/news_2012/2012030701_Intel_rolls_out_Xeon_E5-1600_and_E5-2600_CPUs.html
The v2 versons that are 10 cores will probably take on the old 8 core price points.
The 12 cores are certainly not going to be priced lower than all of the 10 core modes. Unless someone at Intel takes major drugs and prices it out of company standards, 12 is going to cost more than 10.
The 12 cores may toss some lower GHz to be priced less than the highest 10 core ( that has the higher GHz boost), but doubtful it is going to drop down into the 8 core range ( the current 6 cores are going to be 8's and the new 8's will take over the old 6 core range. )
There are going to be 4, maybe 6 , 8 , 10 , and 12 core E5 2600 v2 offerings (that 2 core is kind of dumb with Intel's other 2013 Xeon line up and upcoming server focused Atom chips. I suspect that will disappear) . All the other entries are going to push the 12 core higher in price.
Yah, that single processor only has 12 cores. I want 24 cores!!!
And you are ready to pay for that?
If you need it for your work, the Mac Pro should meet your needs. If you're just wanting to show off that you have the latest and the greatest, go buy a BoXX and make the jump to Windows/Linux.
Exactly.Meaning we could have 24 physical cores if they kept the current form factor.
Apple seems to have forgotten the purpose of a Mac Pro is to be a Mac workstation, not a Super Mac mini.
There are more than 24 cores in the 2013 Mac Pro. A lot more. No, they really didn't forget.
The issue is whether only x86 cores are worth counting. Apple has been and is still increasingly detaching itself from that viewpoint for future Macs ( not just the Mac Pro ). So is AMD. So is Intel. In fact, every major system vendor is.
The nature of the problem being solved by the software has far more to do with how the programs are built than wether or not the developers want to use the top how ever many super computers. Even small tasks in my field still often require 4GB of RAM per process or are simply naturally linear computations. So you just can't load that into a GPGPU. With some tasks you can do some gymnastics to make it work, but there are trade offs being made that cut back the gains from being able to use 50 cores or more. Anyway point is, your use of "want" above is just incorrect. Of course everyone would love to throw an extra 50+ cores at a problem, but sometimes it just doesn't work that way.
Last edited:
You must be confused because Apple said up to 12 cores. Additionally the 2013 Mac Pro has not even been released yet so stop spreading false information.
HTT ≠ a physical core
Virtual core ≠ Physical core
Oh, I see. That is a good point. If OS X could leverage the GPU and pass that seamlessly to the developers or as an API that would greatly distance it from other operating systems.
I'm sorry, but "there are more cores because they're on the GPU" is marketing speech and nothing more.
I was speaking sarcastically. I mean, I would never complain about having 12 freakin cores!
I'll probably get flamed here, but I think it's worth saying. (So pre-sorries for making people angry )
We have up to 12 CPU cores @~3GHz, with up to 128GB RAM (which will be outrageously expensive) and we also have up to 4000 GPU cores @~1GHz, and 12GB VRAM.
12 CPU cores is a LOT of cores (doubled for H/T). If your software requires more than 12 cores, wouldn't it be better to use the GPU instead? If it doesn't use more than 12 cores, then the entire argument is pointless.
Furthermore, any specific software that could use more than 12 cores, but won't benefit from using 4000, is hardly justifying Apple redesigning their entire computer for the vanishingly small number of cases where this would be true.
Sure, there may be software developers who refuse to update their can-use-over-12-cores software to GPGPU, but people who use that software need to be the ones putting pressure on said software company to change their mind.
The other subset of tasks that could be better off running with more than 12 CPU cores is highly parallelised software that requires more than 12 GB of RAM to run calculations, but less than 128 GB. Less than 12, and everything could just be loaded straight into VRAM, no loss in speed. More than 128GB, and the data must be stored on the PCI SSD, which then becomes the bottleneck. Only between 12 and 128GB does information need to be repeatedly transferred through the PCI bus, that otherwise wouldn't if performed purely on CPU. And again, that range is pretty specific, and could probably be fixed with a little code optimisation.
________________
TL;DR: Apple (and the rest of us) shouldn't be held back by either extremely specific tasks that can be done better on >12 CPU cores, but not on 4000+, or lazy programmers who CAN be bothered to hyper-thread their software, but not take the next step to GPGPU.
P.S. I am, however, willing to review my opinion if someone can come up with a reasonably popular task that fits between low-core, high GHz, low H/T optimised (which would be better off with a 4GHz quad, or even O/C dual), and massively parallel computing optimised (which is clearly better off with GPGPU).
)We have up to 12 CPU cores @~3GHz, with up to 128GB RAM (which will be outrageously expensive) and we also have up to 4000 GPU cores @~1GHz, and 12GB VRAM.
12 CPU cores is a LOT of cores (doubled for H/T). If your software requires more than 12 cores, wouldn't it be better to use the GPU instead? If it doesn't use more than 12 cores, then the entire argument is pointless.
Furthermore, any specific software that could use more than 12 cores, but won't benefit from using 4000, is hardly justifying Apple redesigning their entire computer for the vanishingly small number of cases where this would be true.
Sure, there may be software developers who refuse to update their can-use-over-12-cores software to GPGPU, but people who use that software need to be the ones putting pressure on said software company to change their mind.
The other subset of tasks that could be better off running with more than 12 CPU cores is highly parallelised software that requires more than 12 GB of RAM to run calculations, but less than 128 GB. Less than 12, and everything could just be loaded straight into VRAM, no loss in speed. More than 128GB, and the data must be stored on the PCI SSD, which then becomes the bottleneck. Only between 12 and 128GB does information need to be repeatedly transferred through the PCI bus, that otherwise wouldn't if performed purely on CPU. And again, that range is pretty specific, and could probably be fixed with a little code optimisation.
________________
TL;DR: Apple (and the rest of us) shouldn't be held back by either extremely specific tasks that can be done better on >12 CPU cores, but not on 4000+, or lazy programmers who CAN be bothered to hyper-thread their software, but not take the next step to GPGPU.
P.S. I am, however, willing to review my opinion if someone can come up with a reasonably popular task that fits between low-core, high GHz, low H/T optimised (which would be better off with a 4GHz quad, or even O/C dual), and massively parallel computing optimised (which is clearly better off with GPGPU).
Very well put. This is the point I was trying to make, but perhaps not clearly enough.
Additionally, in research and development particularly, there is often the need to produce code to quickly try something. The code needs to be written quickly and also run quickly. This is a very different model to a team developing a commercial product that will then be used by lots of people over a long period of time.
In the latter case it might make sense to craft a parallel solution with GPGPUs, in the former case it makes no sense to do so.
Regarding the growth of GPGPU in the HPC community:
HPC is a bit like Formula 1, fun to watch and good to look at the leader board but you're not going to want to go on an expedition across the Sahara in a 4x4 designed by an F1 team!
Last edited:
In the case of requiring 4GB+ RAM per thread, and those threads are linear, so can't be divided further, would not a cluster of 6+ quad Mac Minis be better, and likely cheaper, than a 24 core Mac Pro?
Wouldn't this be fixed if someone (e.g. Apple) made a library of easy to use GPGPU functions? Kind of like OpenCV, but for OpenCL? (Assuming it doesn't already exist)
Partially true but depends on what you need to do.
For example, if you're simulating an electronic circuit you probably are going to be manipulating matrices and so could fairly easily make use of library functions that did LU decomposition perhaps.
On the other hand, if you're working on an automated theorem prover requiring rapid searching using complex data structures then there wouldn't be anything in the library that would help.
As an aside, this is one area where CUDA is still a bit ahead of openCL in that they have spent longer developing libraries, but openCL is catching up I think (I'm not an expert).
Libraries would certainly be good, but I don't see Apple putting a lot of resources into this - their main target market is graphics/video professionals so any programming effort they have available would go in that area I would think.
In that particular kind of issue, yes. But the same computing investment may also need to cover processes that use 64+ GB of RAM. So there is a happy medium there somewhere. For a lot of people it may make more sense to get the base or 6 core Mac Pro plus a couple minis, instead of opting for the 10 or 12 core Mac Pro by itself.
even if the OS uses the GPGPU cores as well as CPU cores it won't matter until all of our professional applications get on board the GPGPU bandwagon.
Heck we only just crossed over from 32 to 64 bit not too long ago, and we still dont have 100% 64 bit apps.
Also a good point. Many times in research you end up creating something and using it once or a very low number of times. Then that thing can go on to guide other projects and eventually you might reach a point were a lot of time optimizing code is worth it, but its best to only do that when you have to.
Indeed, super computers are great and all, if you can transfer your data and make it through the queues in reasonable times, or even get approved to get on them. Otherwise, it's often the case you have access to this or that cluster and that's it. You make due with what you have. And the majority of the clusters out there still don't have many GPGPU nodes.
Don't tell that to the people living in the dream world where everything uses OpenCL and GPGPUs with perfect efficiency.
I think the days of dual CPU's are over. Intel is moving toward a ton of cores, it's just not efficient or cost effective anymore to manufacture, and add multiple CPU's.
Apple knows this, and already moved toward single CPU enclosure. You can complain all you want about how you do 3D VFX at 12k resolution, but Apple is also probably going to enable ip over Thunderbolt so you can have a nice render farm if you have lots of cash to blow.
Apple knows this, and already moved toward single CPU enclosure. You can complain all you want about how you do 3D VFX at 12k resolution, but Apple is also probably going to enable ip over Thunderbolt so you can have a nice render farm if you have lots of cash to blow.