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.
2016 nMP
- Thread starter ManuelGomes
- Start date
-
- Tags
- nmp
- Sort by reaction score
- Status
For some people some type of "Pro" work is just not good enough.
P.S. Polaris 11 is 115mm2 die chip that would go into Macbook Pro.
P.S.2 http://forums.anandtech.com/showpost.php?p=38179658&postcount=2016
GTX 1080 649$
GTX 1070 499$
Last edited:
Mago, you're setting the bar high with Purley. Like I said, and your article confirms that, Purley is for Servers/HPC, 2S systems and up. This is not the nMP ballpark as you know.
nMP will always be 1S workstation, which is Basin Falls, not Purley. These are both SKL-EP platforms, but with different targets, 1S W or servers.
PCIe4 seems to be out of the equation for now.
Will C620 be based on Purley or Basin Falls? Who knows. Right now all is just speculation. Only Intel knows.
Serban, those are not for the nMP for sure, those are BDW-E and nMP gets BDW-EP (Xeon).
I'm confident we won't get Fiji but Polaris, it would be shooting themselves in the foot to go with Fiji now. Not only mem limited, but power constrained and heat. And it would again allow for the outdated GPUs comments.
nMP will always be 1S workstation, which is Basin Falls, not Purley. These are both SKL-EP platforms, but with different targets, 1S W or servers.
PCIe4 seems to be out of the equation for now.
Will C620 be based on Purley or Basin Falls? Who knows. Right now all is just speculation. Only Intel knows.
Serban, those are not for the nMP for sure, those are BDW-E and nMP gets BDW-EP (Xeon).
I'm confident we won't get Fiji but Polaris, it would be shooting themselves in the foot to go with Fiji now. Not only mem limited, but power constrained and heat. And it would again allow for the outdated GPUs comments.
Of course not, but considering the power and heat constrains of the nMP, going with a 28nm GPU instead of with a more efficient Polaris on 14nm would be suicide. I find the nMP powerful enough for my needs and prefer the quietness but others will prefer the extra performance even with the additional noise or heat output.
I would take any of Pascal or Polaris in the nnMP, they might be much alike performance wise.
I would take any of Pascal or Polaris in the nnMP, they might be much alike performance wise.
Next console generation is coming out.. Sony and Nintendo.. but AMD said last year that there's also a customer they cannot reveal yet...
If Apple, it could be a special custom Zen.. or A10 + Polaris on chip combination for VR hub (= next gen Apple tv)
Whatever I believe this mid2016 MP will be the final last generation on Xeon cpu, then will be on Zen for a while until suitable ARM, PowerX or whatever another architecture takes on amd64Mago, you're setting the bar high with Purley. Like I said, and your article confirms that, Purley is for Servers/HPC, 2S systems and up. This is not the nMP ballpark as you know.
nMP will always be 1S workstation, which is Basin Falls, not Purley. These are both SKL-EP platforms, but with different targets, 1S W or servers.
PCIe4 seems to be out of the equation for now.
Will C620 be based on Purley or Basin Falls? Who knows. Right now all is just speculation. Only Intel knows.
Serban, those are not for the nMP for sure, those are BDW-E and nMP gets BDW-EP (Xeon).
I'm confident we won't get Fiji but Polaris, it would be shooting themselves in the foot to go with Fiji now. Not only mem limited, but power constrained and heat. And it would again allow for the outdated GPUs comments.
PowerPC even on the desktop was not a huge success. And Itanium is pretty much dead.
Where you are? It's 2016, not 1980, most code now it's cpu agnostic, and most code just requires few optimization as endian avx-like extension etc, not to say that languages as Swift or Python you don't need to know the cpu architecture.
Further initiatives as HSA are working to do that almost automatic.
On PowerPC and Itanium the first was miss managed by IBM, and unless IBM get into an scheme like ARM holdings I don't believe on PowerX beyond vertical solutions markets, Itanium depends most on how hungry gets Intel on x86 future decline, Itanium certainly is its only architecture that can extend Moore law a bit more and has potential to beat ARM on performance/watt and Zen on IPC.
CPU architecture has nothing to do with Moore's law. Moore's law only observed that the density of transistors tends to double every 2 years. This has more or less come to an end regardless of the chip's architecture.
Intel makes very good laptop and desktop processors. Its naive to think that because Intel's x86 processors have stopped getting twice as fast every generation that some other architecture can magically beat it.
I am not sure why you think that Itanium is some sort of performance savior, it hasn't been produced since 2013. If Apple did move away from x86, it would almost certainly be to its own ARM based processors.
It's not a secret the x86 architecture has many legacy compromises that make difficult to improve its efficiency, as the way it handles page faults, or how it handles to decode legacy instructions and newer, basically an x86 are two cpu in one, one decodes a micro code that it's what teaches it how to decode the actual instructions. On ARM you don't need this, arm cpu doesn't use micro code, they just decode the instructions and process it on the same step.
On the other hand there is Itanium optimized from ground up to handle 64bit WISC it's approach , further having complex instructions sets it's potential to increase IPC performance it's beyond the reach of any other architecture.
Just compare ARM cortex A72 with Intel's Silvermont core (the same on Xeon Phi, Xeon d-1587, others, Intel's most efficient core yet) it use to run at 2.2ghz and it's performance it's just about twice that ARMs a72 at 1.2-1.8 ghz at the times it requires about 8x the power than ARM cortex A72
Apple os gaining experiencie making ARMs faster it's A9 are closer to x86 single thread performance than any other.
http://forums.anandtech.com/showpost.php?p=38180442&postcount=46
This guy is PS4 game developer.
I suppose he is talking about Primitive Discard Accelerator.Zlatan said:
This guy is PS4 game developer.
To be honest I don't know enough about computer architectures to refute your comparisons of the different architectures. My only question is if Itanium is so great than why was it abandoned by Intel?
Uhhhh what? Not even close to true. The first problem is Swift applications are still shipped in a specific processor architecture, which means everyone would need to update their applications. And Swift is just as processor independent as Obj-C is, which is to say this CPU-agnostic nirvana you're talking about would be the same amount of hurt as the Intel switch in 2005. The Intel switch wasn't awful, all things considered. But let's not suggest we should all do that again and that it would be easy.
Yep. x86 is not the problem here. ARM or PowerPC is not going to get past the process barrier Intel is hitting. It's a manufacturing problem, not an architecture problem. Switching architectures would just add more needless churn.
Originally itanium was adopted to replace x86, but at these times (circa 1990) re-write program code to support another platform wasn't so easy, these times people didn't care on efficiency but to handle more than 4 gb of ram, then AMD launched its amd64 cpu capable to run 32 bits binaries and to address more than 4 gb if ram, then the market quickly ditched itanium, then at the time Microsoft do the same (itanium survived for a while as workstation/server solution) finally hp (itanium actual developer and IP owner) keep offering it as server solution running Linux, Itanium isn't officially dead, just it's development was frozen, maybe this sudden rise on HPC market would resurrect it, but this depends more on Power9 success than the x86 fate.
Two main reasons: Intel charged a fortune for the processors, and they were not cost effective compare with Xeons; also, nobody wanted to recompile their code, let alone figure out how to get the early compilers to keep all six pipelines busy. After you figured out how to get the compiler to feed the functional units in parallel, code did generally run at very high IPC rates, but I think most people didn't have that much patience. Also, for those on IA-64 Linux, gcc sucked badly. It was totally incapable of generating anything remotely efficient for the Itanium, so at the time the only good compiler for IA-64 on Linux was Intel's compiler. If you ran HP-UX on HP hardware, the HP compiler was quite good, if not better. Also, the early versions of IA-64 included a small x86 core for running x86 code very slowly. This turned out to be a horrible idea, as people would then just grab some x86 executables and run them on their expensive Itanium machine really really slowly, which gave the processor a bad name. It turns out that then, as now, people just want faster hardware to run their old code without changing anything. This is why we still have x86.
FYI Swift code runs on x86 (osx) and arm (iPhone, iPad, ATV).
I just translated an open source code in Java to swift to do Delaunay Triangulations, I use exactly the same library I coded w/o switches or pragmas on both my Mac and iPad applications (I code Apps for vertical markets).
Python goes far beyond, you can run the same code either on a pc x86, arm like raspberry Pi, IBM Power8, on any OS and you'll never get aware where it is running, neither Java achieve its portability.
Not your day to troll here.
Ahh
ARM is being manufactures on the same 14nm process as Skylake, just to name few: Qualcomm Snapdragon 820, Apple A9x
That guy, Zlatan, over AT forum has lots of interesting posts, for example:
"They switched for FirePro because of OpenCL, but the main reason for the full switch is Metal. Intel GENx, and AMD GCNx is well documented for Apple to write a Metal drivers for these architectures. On the other hand they don't able to create a first class support for NV, because the lack of documentation. Apple won't care too much about OpenGL, OpenCL, Vulkan, anything. They are now focusing to the Metal API."
"They switched for FirePro because of OpenCL, but the main reason for the full switch is Metal. Intel GENx, and AMD GCNx is well documented for Apple to write a Metal drivers for these architectures. On the other hand they don't able to create a first class support for NV, because the lack of documentation. Apple won't care too much about OpenGL, OpenCL, Vulkan, anything. They are now focusing to the Metal API."
Swift runs on x86 and ARM. That doesn't mean you don't have processor specific code, or that a Swift app can run on any platform. A Swift Mac app can only run on x86. If Apple added Mac ARM, everyone would have to recompile and port any processor specific stuff, exactly the same as Obj-C. Swift adds nothing special here.
I have Swift code that contains things that only run on ARM. It's not magic. Swift does not run in a virtual machine. It's not Java's compile once, run anywhere. It's the same as Obj-C, even sits on top of the Obj-C runtime.
Nobody wants to do the same process done for PPC -> Intel again. It wasn't all that fun.
Swift run everywhere what you talk about are OS specific operation as its done on cocoa or cocoa touch it doesn't have to do with the cpu but the OS, on swift as on many languages you can invoke assembler or objective-c or c for specific purposes in most cases you don't care on cpu specific switches, only when you invoke bit-wise level specific operations where cpu' s endian has some importance on regard to the operation it's self is when you write cpu specific code, all other code it's cpu agnostic (not OS agnostic).
Ahh, Swift it's cpu agnostic, the binaries resultant from a Swif code usually are cpu specific (usually not always there are ways to create generic binaries that run everywhere, and I don't speak about java)
This it's true also when you code for a gpu, if you invoke an kernel from an x86 or form an ARM if you use a language as Swift your code won't change no matter if it's on x86 or arm much less your kernel code (which is gpu specific but mostly C99 std).
I suggest you before teaching about programming get a degree on CS, Reading Mac World don't make you an authority.
- Status