I'm not sure intel has advantage in avx 2 with the new ryzen. That said I got this information from some unsourced comment in hacker news, it might be totally wrong.
Games!? No Man's Sky had trouble with SSE 4.1 being a requirement, and ended up patching it out... let alone AVX, AVX2, or AVX512.
Typically, games won't take advantage of new instruction sets until it's ready to be a minimum requirement, as otherwise you need to maintain two code paths, the benefit of which is only to be speeding up execution on what are already the more powerful CPUs.
Not now obviously as it is not mainstream yet, but AVX512 makes developer's life way easier than older AVX sets. So I see no reason why game engine developers wouldn't use them in the future. For now only some server-specific workloads use AVX512.
Some LLVM compilers produce code that (possible with GCC too) can jit itself on a per function on first execution e.g. -march=native so no branches required.
This requires good planning of the game, i.e. this reduces inlining so one needs to be careful with putting the important bits in the JITted code
If you're referring to ifuncs, they aren't doing anything like "JIT itself": your rtld simply calls your function to decide which version of the function you want to call and updates the PLT.
I don't know what they call it normally, but I noticed a magic symbol attribute in the LLVM d compiler that invoked a jit at runtime (-dynamic* something like that)
Well, it includes some masking instructions that allow algorithms to use vectorization in cases where it's not natively processing vectors. The benefit should be similar to the thread-local control flow stack introduced in the Volta microarchitecture of Nvidia.
I'd say it's a bit early to be making statements like that; Zen 2 has native 256 bit vector units, and might yet do OK with AVX2 code vs Intel processors.
AVX512 though, even if you don't use the full width registers (eg to avoid throttling), the new instructions are very useful and not at all present on Zen 2. I wouldn't be surprised if Zen 3 kept 256 bit vector units, but supported the AVX512 instruction set.
Moreover, AVX2 operates at full frequency on Zen 2. AVX-512 heavily downclocks CPU; not sure about AVX2 loads on Intel right now (some people complained about AVX2 throttling on Skylake X).
I thought I read somewhere that Zen 2 will downclock based on heat, rather than simple instruction set heuristics. I can't find a source though, so take that as hearsay for now.
Intel CPUs do downclock for both avx and avx-512. Many motherboards let you configure that in the bios.
I bought both a 9940X and a (delidded) 7980XE for avx-512 intensive workloads. I use a water cooler with a 360mm radiator.
The bios for these (overclockable) chips contains "AVX Offset" and "AVX512 Offset" parameters. I haven't really tested avx loads, but the avx512 downclock is necesary. They run at 70-80C when running all cores at 3.5GHz in avx512 heavy loads. I don't want to push the temperatures further than that. I don't think there's any practical way to avoid having to downclock.
It does gives a sizeable speed boost overall (for those workloads).
Re: this thread
I'd bet those avx512 workloads will be faster as avx2 workloads running on two 64 core CPUs with avx2 than one 56 core CPU with avx512, all else equal.
But it sounds like, instead of all else being equal, things like IPC favor Zen2.
The vectorized versions were those with "sleef" or "xsimd" in their name.
They tended to be 1.5 to 3 times faster, while the nonvectorized versions were 1.25 to 1.35 times faster on the 9940X.
Some of my other code is likely to show a much bigger difference. For example, many small matrix multiplication operations get to take advantage of avx512's masks to vectorize efficiently, as well as the fact avx512 has 32 instead of 16 floating point registers to hold larger matrix blocks in registers, increasing the vfma to vmov ratio.
I suspect the 3.2x difference in speed in the "jsleefpowcob!" benchmark is because of the register counts. I suspect with avx512 the compiler was able to avoid register spills, while with avx2 it had to reload a lot of data on each loop iteration.
The biggest problem with avx512 IMO is that compilers seem bad at taking advantage of it (eg, they never use masks) unless you babysit them / write code with vectorization constantly in mind.
gcc for example will not use 512 bit vectors by default. You must explicitly specify "-mprefer-vector-width=512". My tests (mostly just the Polyhedron Fortran benchmarks, as a set of numerical code) seemed to confirm that gcc (gfortran) was doing the right thing.
Meaning unless you intend to go low level and use it yourself (which can be a rewarding hobby!), or have workloads where optimized libraries exist, you won't see any benefit from avx512.
Depends on the structure of your problem. Some lend themselves well to vectorization, others not nearly as much. Or at least the needed vectorized solvers are not yet available for some problem structures.
Try to use perf-tools to determine how you're currently using these execution units, and then you can look how much it might help. Rule of thumb: double the bitwidth of vector instructions gets you 80% more speed, instead of the theoretical 100%.
No, bad idea. Test or check reviews for your common workloads first, then choose. New Zen cores quite powerful and there are many gotchas with AVX execution. In most cases I can see AMD would be better overall or offer good value.
Indeed. With any microarchitecture (or ISA) change (and Intel -> AMD is a huge architectural one) you need to test your workloads. You'll find all sort of odd and surprising performance differences caused by throttling, the way caches behave, the way libraries choose code paths, various inter-core latencies, and so on.
At least this is a move that doesn't require a full recompile.
Back in the early 2000s Apple was getting crushed because Moto/IBM's PowerPC couldn't keep up with the 880lb gorilla Intel. Who could have predicted even a few years ago Apple would wind up in a similar situation, yet this time for having bet on Intel?
Could the 8 core Mac Pro have been $3650 with a $650 Rome CPU, vs. the reality of $6k with a $3k Xeon?
The downside is the motherboard is pretty expensive. And I don’t think many people would buy a motherboard more expensive than the cpu on board. ASRock might offer a few more X570 mb with tb3, but I haven’t checked
If it's baked into an iMac / Mac Pro, what proportion of the potential market are actually going to delve that deeply into the components? I'd wager probably single digit %.
Is that true though? As far as I know the Spec has been donated to USB and will be included / published as USB4 by the end of this year.
So until USB4 is out, it is not Open "yet". And even if USB4 is out, there is no guarantee USB won't mess up with only USB4 4x4 that support Thunderbolt 3 40Gbps.
That's my understanding as well, we only have Intel's word at this moment that TB would be open but it's USB4 that'll have the open "TB features" and they will co-exist; not USB4 replacing TB at all.
Here's the Verge article[1] that also speaks to this:
> Although USB 4 will integrate Thunderbolt 3’s features, Intel says that the two standards will coexist. While USB 4 is open, Thunderbolt 3 is not, and Intel requires manufacturers to be certified to use it. It also offers these manufacturers more support with reference designs and technical support. USB 4 might have the same specs, but Intel provides other Thunderbolt 3 services that go beyond the hardware itself.
If apple complete the switch to arm I guess the hackintosh will go into hiatus for a long time. But the recent release of Mac Pro might delay the change for sometime. However this also depends on whether the t2 chip will be forced on in later os
Probably correct but making mobile CPUs is still a level below making the monsters our desktops are blessed with(Think of all the different SIMD etc. extensions the average Intel CPU) has these days
Practically all mobile chips support virtualization. In fact, Qualcomm always runs your OS (on both Android phones and Windows laptops) under its own tiny hypervisor.
> Think of all the different SIMD etc. extensions the average Intel CPU
Most programmers don't care whether a CPU has AVX512 support. Most programmers will use a library or an OS service that'll abstract that away and pick a certain code path appropriate to the running CPU.
I don't think a human being can get a full understanding of a modern x86 without major brain surgery that is not yet available.
In fairness, they are in a much better situation. They could swap to AMD with no real arch changes but I imagine they also would prefer their own CPUs. The fact of the matter is that these CPUs are built on the same exact process as the A12 by the same fab. I would expect, at the scale they are working, a next Apple ARM cpu could be scaled to Rome core counts and have “close” performance at hilariously lower prices.
That’s not really true. Most of MacOS is optimized for intel processors. Things like branch prediction and media encoding/ deciding are extremely different at a low level on AMD/ Intel, and Apple would need to make an enormous investment to rewrite all their perf specific components for AMD.
Value on a few parameters ( these are relative of course) :
- Stability
- Security
- Ease of use
- Looks
I’m sure the millions of users have found a combination of these factors valuable
Perceived value? If their customers value their products at $X and value their competitors less, they should pay more for Apple than their competitors. Some of this is subjective (branding, UX, etc), other parts have to do with the value add of combining multiple Apple products into one ecosystem (macOS + iOS is more valuable if you use the shared ecosystem).
Is it worth spending $1-3k on a Mac if you just want to browse the web? Probably not unless you're really into their branding. Is it worth it if you have an iPhone, iPad, and Apple Watch and use many of Apple's shared services? Probably, and you get even more value out if it if you use popular software that targets macOS like Adobe products. If you're buying the ecosystem, the price is a lot more justifiable.
Personally, I don't own any Apple devices and I primarily use Linux, so my only one case for macOS is the iOS simulator and XCode so I can build and do basic tests for apps on that platform. And honestly, since that's the only extra value I'd get from them, their hardware seems a bit overpriced (I'm already paying for the developer license and sharing profits, hardware costs and lack of selection are salt in the wound compared to Android).
Economic value = maximum amount a customer is willing to pay for something. It does not matter why. Usually economic value is little higher than market value.
> Could the 8 core Mac Pro have been $3650 with a $650 Rome CPU, vs. the reality of $6k with a $3k Xeon?
The mac pro uses workstation parts (Xeon W) not workstation parts. It doesn't use a $3k xeon for the base configuration (the 8c16t is a $750 chip) and probably wouldn't use an EPYC either (it'd use Threadripper, which hasn't been announced yet for Zen 2 but the 12c24t Zen+ is $650).
Note that the 1P variant costs only $4,955, or under $80 per core. The consumer chips cost roughly $50/core, making this the flattest ramp I can personally remember.
I'm interested in this as well. Of course from a practical POV, especially with escalating NRE costs at recent nodes, we're clearly at a point where "getting the same core size at lower cost" is not going to be a thing unless you can afford to amortize that NRE over a huge volume of chips.
>Does anyone have a graph of recent $/transistor progress?
It wouldn't matter. You can't look at cost / transistor without factoring in Die Size and yield. Not to mention the cost of Higher Performance and Low Power Transistor are different. And the wafer price ( Cost / Transistor ) also exclude all the design cost and tooling around the node.
That is the brilliance of Chiplet strategy. Those 74nm 7nm Die are extremely cost effective. ( For reference they are even smaller than the SoC used in iPhone ) The 14nm I/O die ( 400mm2 ) seems to be most expensive part. I wonder what cost improvement could be done in that area.
And Note: That 5K CPU has 256MB of L3 Cache. May be I could Run the OS not in RAM, but in Cache.
Note regarding Note: It actually has 16*16MB cache. The L3 is split into 16MB segments per CCX, and organized as a victim cache taking lines evicted from the 4 local L2 caches. That is, a single core cannot ever write to more than 16.5MB of cache.
So there's not really any way to run system out of only cache, outside the tiny examples of early boot where all CPUs do this.
There have been a few Intel processors with "L4 cache" (meant to be used as iGPU memory, and only if unused work as L4 cache) as listed here [0]. Broadwell was the only generation to have desktop processors with the eDRAM chip sitting by the side of the processor. Now it's only on a few higher end ultrabook processors [1, 2] -- look for those listed with L4 cache.
Note that Intel has also announced that they're going to use chiplets w/ 3D stacking for newer designs, starting in 2019. So this isn't something that's exclusive to AMD.
But AMD is again the innovator, just like with amd64, real dual-core, on-die memory controllers, hypertransport-style bus, on-die pcie controller, on-die gpu and so on.
I do have an AMD Hackintosh, I don't see any reason you wouldn't be able to use these as a dev Hackintosh machine. It's gorgeously fast with my Ryzen 2700x, eats compilation time like no one's business and it's stable. And it's something around 1/4th the price of the same horsepower from native Intel Macs. I can't imagine the cost delta of a EPYC Rome Hackintosh to its Intel counterpart.
It's not like I cheaped out either, I have the same cheese-grater like anodised dark grey aluminium case with impeccable internal structure for easy upgrades. (Link to case: https://www.youtube.com/watch?v=gcNsHS2U8RM)
Correct, the built-in drivers only cover the "Kepler" architecture, as that was the last one that Apple used in a Mac. The 3rd party Nvidia drivers which support more modern GPUs are only offered up to macOS 10.13 High Sierra.
The technical background for this is that Metal and OpenGL acceleration requires the GPU driver bundle to be loaded into a process's address space. (effectively a dynamic library) With 10.14, Apple has enabled the "library-validation" codesigning flag just about everywhere, which means that only libraries signed by the same developer as the process's main executable or by Apple can be loaded into a process. Hence, 3rd party GPU drivers won't load in WindowServer for example, which makes them dead in the water.
Apple could of course implement an exception or sign Nvidia's driver, but so far it looks like they're not interested. Perhaps there will be a solution to coincide with release of the new Mac Pro which once again contains PCIe slots you conceivably might want to fill with Nvidia cards, but I wouldn't count on it.
(FWIW, my company maintains the macOS driver for one of 2(?) manufacturers of USB graphics adapter chips, so I have a pretty good idea of how the macOS graphics stack works.)
Someone on reddit suspect apple’s stance against Nvidia in this driver signing carnage is because they are not happy with Nvidia about cards in MacBook Pro
They screwed over much of the laptop industry in the late 2000s. Google "Nvidia bad bumps fiasco" or "Nvidia bumpgate".
This left the major computer vendors (Dell/HP/Apple etc) with very large bills due to the high failure rate of these Nvidia GPUs in laptops. It was right after this that Apple stopped using Nvidia, I've always assumed bad blood over this was a major factor.
The cost to Nvidia ended up in the hundreds of millions (based on charges one can see in quarterly filings from this time), the total cost of the failures industry wide is pretty hard to establish given laptop manufacturers weren't exactly in a rush to let customers know the extent of the issues...
As a driver developer, I've been on the receiving end of stuff breaking due to changes in macOS many a time. Based on my experience, I find it much more likely that Apple simply does not care about this problem/does not consider it a problem. By that I mean they are not willing to assign developer resources to the situation because from their point of view it is not a supported configuration, plain and simple. The fact that it ever worked is largely accidental as far as they are concerned.
One of their highest priorities at the moment appears to be to remove any 3rd party code running in the context of Apple processes. For examples, you don't need to look far: kext -> DriverKit/System Extension transition, hardened runtime, etc. The Nvidia driver breaking is just a consequence of that increasing lockdown. The simplest solution would be to allow nvidia's code to run in the context of core system and user processes again (kernel, WindowServer, just about any GUI app) which presumably is not palatable to them or they wouldn't have made the change in the first place. The alternative would be to farm this type of driver out into a sandboxed user process. (Nowadays this means DriverKit.) Aside from potential performance issues, this would be a lot of work, so it's probably never going to happen unless literally millions of end users start complaining.
No, generally if you're doing the Hackintosh the modern way, you pick your components beforehand from those supported by Mac OS natively (which are excellent components you should already be picking regardless, with the exception of GPUs), and then the only thing you need is the SMC driver I mentioned. I didn't build this machine for Hackintosh, so I have a few drivers (4-5 I think? It tends to need fewer and fewer every OS X update), but that's it.
> Threadripper with many NVidia GPUs as well?
Yes, it works with Threadripper, but not with NVidia GPUs, but that's because regular Macs don't work with NVidia GPUs as well. My understanding is that it's a standoff between NVidia and Apple largely due to NVidia's poor behaviour the last time NVidia was included in Macbook Pros around 2012.
> My understanding is that it's a standoff between NVidia and Apple largely due to NVidia's poor behaviour the last time NVidia was included in Macbook Pros around 2012.
Yes, I have one of those famed 15” rMBPs that many devs say “over my dead body” when you suggest upgrading to a newer model. Zero GPU complaints after the initial bugs were ironed out (and the bad batches replaced).
Note that AMD offered virtually no competition to nVidia in either the mobile or the workstation configurations (power or efficiency) up until at least the availability of the R9 Fury a couple of years ago.
I'm actually a designer, but I stopped using Adobe a very long time ago for unrelated reasons — when they switched to the subscription model. For that reason I didn't even try to run them.
I do realise that might be an untenable position for someone in Hollywood since FCPX is not a match for Premiere / After Effects at that level, however, there are plenty of other things that do the job of Photoshop and Illustrator, and they are not alternatives, Sketch is genuinely vastly better than Illustrator, and for Photoshop, there have been quite a few alternatives that the whole class of image manipulation apps got commoditised.
That's Adobe's way of getting you hooked. It was the same for me at my college. It took me a long time to port my muscle memory to Sketch.
If I had an advice to give to my college self, I would advise not even starting with Adobe: if you're a designer and use their tools, the tools you need to make money with isn't even available for sale, you can only rent. So you might end up in a place where Adobe jacks up the price of Creative Suite by 10-100x per month after becoming dominant like Oracle, and you would have to pay your dues to their feudal fiefdom just to be able to continue your profession - else you'll starve. Not a great place to be for anyone.
Indeed. I was pretty well versed in Photoshop but switched to Affinity some years ago and I'm genuinely very, very happy with Affinity Photo. I wouldn't switch back even if Photoshop was free.
Same here - jumped the ship a couple of days ago and thoroughly impressed so far. Plugins system is sorrowly missed at some moments, but should be arriving soon from what I understood. Everything else, including performance (I'm amazed by how fast that WebGL through WebASM works) - better.
How was it getting things working on your AMD hackintosh? I’m very, very tempted to switch to AMD when the new Ryzen chips land but obviously want to be able to run macOS.
I would be cautious about recommending hackintosh to the general public, but for any software guy or gal, it’s a walk in the park. You might need to debug some driver stuff but ultimately there is a possible, perfect state where everything works, given some prior preparation. Same for AMD.
> Do you have power management (and sleep) working on amd?
Yes (null-power-mgmt.kext) and yes. Though mind that this is a desktop, so power mgmt. / sleep needs are much less demanding than a laptop.
Specifically, the kext works by disabling power management from within OS X. However I have a kill-a-watt and the the power from the plug varies based on the CPU load, so it seems to be behaving correctly.
That said, I would not do this on a laptop. Just buy a MacBook Pro if you need that. My hackintosh needs are strictly because Apple (until a week or two ago) just didn’t make a computer as powerful as I needed. I’ll probably just go buy a Mac Pro in the first chance.
With me being a quiet computing / low power fanatic, null power management isn't good enough I'm afraid. Not to mention that amd-osx says "sleep will either work or not".
Using a hackintosh desktop for the same reason as you and yes, considering getting a Mac Pro. But it's good to be aware of your alternatives.
Kubernetes, Minikube, Skaffold, Docker. Skaffold especially hits you very hard, because it effectively compiles a docker image, sticks it into Kubernetes, and refreshes the Kubernetes cluster on every save. This is the only sane way to build a distributed app on K8s locally, but doing it for more than an hour legitimately increases the temperature in my flat by a degree or two.
For those who might be interested for a cheaper alternative -
Intel Xeon 8280 QS is $1,800 USD each, a pair of those (56 cores) on a supermicro mb with 12 x 16G RAM is about $5k USD. It has an impressive Cinebench R15 score of 7,800+
Looking this up it seems like Engineering and Qualification samples are loaned by Intel, so the people selling them don't actually have the legal right to do that. They also might have other issues and limitations because they're not the final product, and you don't have any warranty on them.
That's a lot of caveats to hide behind two letters.
OP said "QS" these are grey market chips, QS means Qualification Sample, Intel sends them to various manufacturers to test with motherboards and then they leak into the grey market. They are not retail so frequency and other characteristics might differ -- but even their stability might not be as high as a retail one. Although QS is usually better at this, it's ES (Engineering Sample) which can be very dicey.
Now that you know that they are all property of Intel, yes it does.
Trafficking in stolen property is illegal in all 50 states, although the severity and specifics vary. If you buy them across state lines, 18 U.S. Code § 2315 also applies, making it a federal crime.
And taking and selling the QS/ES chips is not "voiding your contract". It is theft, and given the value of the chips, would qualify as a felony.
The person selling you the chip is not the owner of the chip, they were loned to them by Intel, and they didn't pay a dime. You are buying stolen merchandise.
It's exactly the same as if I were to lend you my bike and you were to sell it to someone else. That someone else is buying stolen merchandise.
They offering a very wide range of core counts but only a narrow range of watts per socket.
Question: for single threaded performance (*n where threads are independent) do I want higher watts per core or higher number of cores? By "performance" I mean throughput.
I'm curious why they aren't charging more for it. Wouldn't that be free profit margin?
Or perhaps they are trying to hurt Intel by selling it at a price where Intel can't make a profit if they lower their prices to be competitive?
Or, maybe it has to do with trying to quickly grab market share. Maybe AWS and other purchases of servers have a somewhat fixed budget, so cheaper chips translates directly to more chips sold?
Only AMD execs truly knows but I think there might be two factors involved. They really want to attract new customers and build echo system and the second part is hard when everyone has been buying almost entirely intel. The second is their cost for such a cheap should be enormously cheaper than intel because of chiplet design. A single chip die for the intel chip is way bigger and yield and cost dramatically increases as die size gets bigger from what I read. So at same profit margin AMD chips would be cheaper and to gain the market share they are probably willing to lower their profit too so those two element adds up.
Note that this chip cost increase is due to silicon defects, a larger chip has more defects, thus your failure rate significantly increases with each increase in chip area.
AMD is working around this by using 8 separate CPU chips, wired together with one interconnect chip.
Intel is the standard and that has amazing sticking power. AMD is trying to make an offer DC operators can't refuse to break that.
Intel is reeling from major design flaws and process stagnation right now. It makes sense for AMD to punch hard. Now is the time.
Also note that the eternally predicted ARM64 wave into servers, workstations, and cloud is not materializing. So far nobody has been willing to build such high performance chips and price them aggressively enough. All things considered it's an amazing window for AMD to take the market lead.
I just ninja edited to add that. Hah. Anyway that could happen but keep in mind that a new ISA (for server workloads) is a much harder sell than a new chip brand. An ARM64 would need to be priced much lower (at least in $/perf/watt terms) than this already mega aggressive AMD offering.
Personally I think Epyc this cheap really harms ARM's chances in the data center.
If Apple goes ARM64 for Mac it could indirectly help ARM get into the DC by showing that ARM is not just for small stuff.
Longer term you also have the RISC-V wildcard. A mostly free core and ISA could in theory move the whole game to the foundry and lead to a race to the bottom on price/performance.
> a new ISA (for server workloads) is a much harder sell than a new chip brand
It really depends. As long as performance is there and the apps work as expected, I'll deploy my workloads on whatever runs them for the best cost per transaction. Additionally, we don't have a say on what architecture our hosted services are on - if AWS decides my RDS databases are to move to ARM64, or Google decides my CloudSQL will run on POWER9 - I probably won't notice as long as the performance is right.
In the past I have deployed production Python-based workloads to amd64 and SPARC (I did POWER too, but for fun) without change. I'm most certain I can do the same with ARM64 or RISCV.
ARM does allow for customized silicon. But right now I’ve heard the architecture is slower than x86 at division because it doesn’t have devoted registers to the operation.
It’s going to be a huge factor in the DC. Never before have people been able to customize silicon. And now (ish) they can for figures that make sense to more than just the usual suspects.
You are in the minority. Most IT and devops people are massively change averse and tend to blame all problems on the most recent change. They would rather pay more for a known quantity. This is even more the case for non technical management.
My suspicion is it matters a great deal on OS stack until Microsoft supports ARM in Server. I’m sure the bsd/Linux OSes will have a much easier time transitioning.
Edit-I’m seeing some articles that make it look like arm might already be usable on Windows. There’s still legacy software issues though.
In 2 to 3 cycles the OS will disappear as a variable in the deployment target. You won't know about it, you won't care about it, it won't be a dimension you think about.
The instruction set as a moat is almost over with the continual rise of Wasm. This is really AMDs last push into the datacenter and with it a huge infusion of cash.
Note, that the list price for Intel Xeons is something that nobody really pays. Behind the closed doors bulk pricing is negotiated and the price-per-chip in practice is only a fraction of the list price.
AMD also doesn't have a heard of salespeople, pay list with AMD, haggle with Intel. Smaller shops that didn't have the time of day with Intel sales, they will go AMD. All of the small clouds with go AMD.
There is no oxygen down at 8k for Intel, they will have to move to chiplets to get the yields up, to drop the prices that far. AMDs costs for these parts is probably double what the consumer versions are, so we are probably looking at 7k+ of profit per chip.
They are forcing Intel to move to chiplets or be really really wounded. Clearly AMD is not participating in a duopoly game, which would be the expected anticompetative behavior.
If I were AMD I would give away the mobos. This is going cause a lot of Intel parts to be EOLd early.
It seems to me that if they are trying to gain market-share in the server market, it is wise to price their chips such that the costs for the required chasis-and/or-mb-swap are obviously covered.
If they priced at intel-$1k, for instance, many organizations would rule it out because the operational and additional hardware costs to switch would easily dwarf the $1k discount.
Sort of like people still buy gas cars even though the long-term economics of electric make so much more sense. The math has to be obviously beneficial (e.g. same sticker price, same range) for the switch to happen en masse.
Enterprise and data centers must consider the risk of a supplier not been able to fulfill their contracts. AMD is inherently more risky in the long term than Intel as AMD does not produce chips themselves. So they must offer cheaper products just to account for that. Add extreme inertia in the enterprise sector and one can see why AMD cannot have the same profit margins as Intel.
Both Intel and GF had problems ramping up their new node. Intel has been stuck with chip shortages for the past year and is still on 14nm because of this, AMD was able to (partially) switch to TSMC. I'd say that AMD's ability to pick a vendor and potentially multi-source for fabrication puts them at significantly less risk of supply shortages.
Over time they'll be able to show that. It's going to take them several more years before the memory of their previous architecture (i.e. the 5-10 years, depending on who you ask, prior to Ryzen) truly fades and they are seen as a serious long-term alternative to Intel by risk averse buyers.
Customer acquisition. You have a farm of Intel, you know Intel will be back in some years, what will get you to take a risk and bother with having some AMD in there? Less than half the price of the competition.
AMD is not trying to get as much money out of it, they're trying to get market share, in a segment of the market where "single product line all identical all across" is a big thing.
Last time they were on top they didn't, and Opteron failed to take enough market share (a story that is not as well known because the bigger one was the customer chips and Intel abuses with oem). They don't want a repeat.
Finding mainstream vendor offerings has been a bit more difficult with AMD. We recently bought 2 E-2146G servers from Dell (preferred vendor at the org.) because anything AMD was only offered as a 2 processor server which was overkill for the application. I would have gladly purchased AMD based servers instead if they were priced closely.
159 comments
[ 6.0 ms ] story [ 4693 ms ] threadTypically, games won't take advantage of new instruction sets until it's ready to be a minimum requirement, as otherwise you need to maintain two code paths, the benefit of which is only to be speeding up execution on what are already the more powerful CPUs.
What games can benefit from AVX512?
If the consoles go ARM before AVX-512 has been standard on new PCs for years, it may just not be worth it.
Gotta love the price segmentation.
This requires good planning of the game, i.e. this reduces inlining so one needs to be careful with putting the important bits in the JITted code
It might work in theory, but it increases the cost of testing too much for it to be worth it.
I saw it the other day and was amazed I hadn't seen it before.
FreeBSD kernel uses ifuncs for SMAP, XSAVE, ERMS (Enhanced REP MOVSB/STOSB), RDSEED.
Edit: I checked and they're not ifuncs
AVX512 though, even if you don't use the full width registers (eg to avoid throttling), the new instructions are very useful and not at all present on Zen 2. I wouldn't be surprised if Zen 3 kept 256 bit vector units, but supported the AVX512 instruction set.
Intel CPUs do downclock for both avx and avx-512. Many motherboards let you configure that in the bios.
I bought both a 9940X and a (delidded) 7980XE for avx-512 intensive workloads. I use a water cooler with a 360mm radiator. The bios for these (overclockable) chips contains "AVX Offset" and "AVX512 Offset" parameters. I haven't really tested avx loads, but the avx512 downclock is necesary. They run at 70-80C when running all cores at 3.5GHz in avx512 heavy loads. I don't want to push the temperatures further than that. I don't think there's any practical way to avoid having to downclock. It does gives a sizeable speed boost overall (for those workloads).
Re: this thread I'd bet those avx512 workloads will be faster as avx2 workloads running on two 64 core CPUs with avx2 than one 56 core CPU with avx512, all else equal. But it sounds like, instead of all else being equal, things like IPC favor Zen2.
EDIT: If folks happen to be interested, I compared a bunch of different "^" (aka, "pow") functions in Julia, running on my 9940X here: https://discourse.julialang.org/t/slow-arbitrary-base-expone...
Someone else shared results with their Ryzen 2950X here: https://discourse.julialang.org/t/workstation-advice-for-mos...
The vectorized versions were those with "sleef" or "xsimd" in their name. They tended to be 1.5 to 3 times faster, while the nonvectorized versions were 1.25 to 1.35 times faster on the 9940X.
Some of my other code is likely to show a much bigger difference. For example, many small matrix multiplication operations get to take advantage of avx512's masks to vectorize efficiently, as well as the fact avx512 has 32 instead of 16 floating point registers to hold larger matrix blocks in registers, increasing the vfma to vmov ratio.
I suspect the 3.2x difference in speed in the "jsleefpowcob!" benchmark is because of the register counts. I suspect with avx512 the compiler was able to avoid register spills, while with avx2 it had to reload a lot of data on each loop iteration.
The biggest problem with avx512 IMO is that compilers seem bad at taking advantage of it (eg, they never use masks) unless you babysit them / write code with vectorization constantly in mind.
gcc for example will not use 512 bit vectors by default. You must explicitly specify "-mprefer-vector-width=512". My tests (mostly just the Polyhedron Fortran benchmarks, as a set of numerical code) seemed to confirm that gcc (gfortran) was doing the right thing.
Meaning unless you intend to go low level and use it yourself (which can be a rewarding hobby!), or have workloads where optimized libraries exist, you won't see any benefit from avx512.
My use case is solving large LP/MIP problems for power markets, do those algorithms benefit?
Try to use perf-tools to determine how you're currently using these execution units, and then you can look how much it might help. Rule of thumb: double the bitwidth of vector instructions gets you 80% more speed, instead of the theoretical 100%.
At least this is a move that doesn't require a full recompile.
Could the 8 core Mac Pro have been $3650 with a $650 Rome CPU, vs. the reality of $6k with a $3k Xeon?
So until USB4 is out, it is not Open "yet". And even if USB4 is out, there is no guarantee USB won't mess up with only USB4 4x4 that support Thunderbolt 3 40Gbps.
Here's the Verge article[1] that also speaks to this:
> Although USB 4 will integrate Thunderbolt 3’s features, Intel says that the two standards will coexist. While USB 4 is open, Thunderbolt 3 is not, and Intel requires manufacturers to be certified to use it. It also offers these manufacturers more support with reference designs and technical support. USB 4 might have the same specs, but Intel provides other Thunderbolt 3 services that go beyond the hardware itself.
[1]: https://www.theverge.com/2017/5/24/15685096/intel-thunderbol...
Most programmers don't care whether a CPU has AVX512 support. Most programmers will use a library or an OS service that'll abstract that away and pick a certain code path appropriate to the running CPU.
I don't think a human being can get a full understanding of a modern x86 without major brain surgery that is not yet available.
Huh? That Xeon in the base-spec MP is a $750 part: https://ark.intel.com/content/www/us/en/ark/products/193739/...
What value?
Is it worth spending $1-3k on a Mac if you just want to browse the web? Probably not unless you're really into their branding. Is it worth it if you have an iPhone, iPad, and Apple Watch and use many of Apple's shared services? Probably, and you get even more value out if it if you use popular software that targets macOS like Adobe products. If you're buying the ecosystem, the price is a lot more justifiable.
Personally, I don't own any Apple devices and I primarily use Linux, so my only one case for macOS is the iOS simulator and XCode so I can build and do basic tests for apps on that platform. And honestly, since that's the only extra value I'd get from them, their hardware seems a bit overpriced (I'm already paying for the developer license and sharing profits, hardware costs and lack of selection are salt in the wound compared to Android).
The mac pro uses workstation parts (Xeon W) not workstation parts. It doesn't use a $3k xeon for the base configuration (the 8c16t is a $750 chip) and probably wouldn't use an EPYC either (it'd use Threadripper, which hasn't been announced yet for Zen 2 but the 12c24t Zen+ is $650).
I think you mean *server parts
While not addressing your points specifically, which I agree with, and more for anyone else reading as I assume you already are aware...
It is important to remember that the (relatively) high-core-count Zen2 Ryzen chips do differ from Threadripper by more than just core count.
TR has a lot more PCIe lanes and it's quad channel memory (as opposed to Ryzen's dual channel).
Its obvious that moore's law is stagnant, and clock speed is dead, etc, etc.
But are we at least getting the same core size at a lower cost ?
It wouldn't matter. You can't look at cost / transistor without factoring in Die Size and yield. Not to mention the cost of Higher Performance and Low Power Transistor are different. And the wafer price ( Cost / Transistor ) also exclude all the design cost and tooling around the node.
And Note: That 5K CPU has 256MB of L3 Cache. May be I could Run the OS not in RAM, but in Cache.
So there's not really any way to run system out of only cache, outside the tiny examples of early boot where all CPUs do this.
I wonder if one day we put even more cache in the I/O Die. Or even Stacked DRAM directly on top of it.
[0] https://en.wikichip.org/wiki/intel/microarchitectures/broadw...
[1] https://en.wikipedia.org/wiki/Skylake_(microarchitecture)#Mo...
[2] https://en.wikipedia.org/wiki/Kaby_Lake#Mobile_processors
It's not like I cheaped out either, I have the same cheese-grater like anodised dark grey aluminium case with impeccable internal structure for easy upgrades. (Link to case: https://www.youtube.com/watch?v=gcNsHS2U8RM)
The technical background for this is that Metal and OpenGL acceleration requires the GPU driver bundle to be loaded into a process's address space. (effectively a dynamic library) With 10.14, Apple has enabled the "library-validation" codesigning flag just about everywhere, which means that only libraries signed by the same developer as the process's main executable or by Apple can be loaded into a process. Hence, 3rd party GPU drivers won't load in WindowServer for example, which makes them dead in the water.
Apple could of course implement an exception or sign Nvidia's driver, but so far it looks like they're not interested. Perhaps there will be a solution to coincide with release of the new Mac Pro which once again contains PCIe slots you conceivably might want to fill with Nvidia cards, but I wouldn't count on it.
(FWIW, my company maintains the macOS driver for one of 2(?) manufacturers of USB graphics adapter chips, so I have a pretty good idea of how the macOS graphics stack works.)
https://www.macworld.com/article/1154456/nvidiagpu-macbookpr...
This left the major computer vendors (Dell/HP/Apple etc) with very large bills due to the high failure rate of these Nvidia GPUs in laptops. It was right after this that Apple stopped using Nvidia, I've always assumed bad blood over this was a major factor.
The cost to Nvidia ended up in the hundreds of millions (based on charges one can see in quarterly filings from this time), the total cost of the failures industry wide is pretty hard to establish given laptop manufacturers weren't exactly in a rush to let customers know the extent of the issues...
One of their highest priorities at the moment appears to be to remove any 3rd party code running in the context of Apple processes. For examples, you don't need to look far: kext -> DriverKit/System Extension transition, hardened runtime, etc. The Nvidia driver breaking is just a consequence of that increasing lockdown. The simplest solution would be to allow nvidia's code to run in the context of core system and user processes again (kernel, WindowServer, just about any GUI app) which presumably is not palatable to them or they wouldn't have made the change in the first place. The alternative would be to farm this type of driver out into a sandboxed user process. (Nowadays this means DriverKit.) Aside from potential performance issues, this would be a lot of work, so it's probably never going to happen unless literally millions of end users start complaining.
> Threadripper with many NVidia GPUs as well?
Yes, it works with Threadripper, but not with NVidia GPUs, but that's because regular Macs don't work with NVidia GPUs as well. My understanding is that it's a standoff between NVidia and Apple largely due to NVidia's poor behaviour the last time NVidia was included in Macbook Pros around 2012.
Yes, I have one of those famed 15” rMBPs that many devs say “over my dead body” when you suggest upgrading to a newer model. Zero GPU complaints after the initial bugs were ironed out (and the bad batches replaced).
Note that AMD offered virtually no competition to nVidia in either the mobile or the workstation configurations (power or efficiency) up until at least the availability of the R9 Fury a couple of years ago.
I do realise that might be an untenable position for someone in Hollywood since FCPX is not a match for Premiere / After Effects at that level, however, there are plenty of other things that do the job of Photoshop and Illustrator, and they are not alternatives, Sketch is genuinely vastly better than Illustrator, and for Photoshop, there have been quite a few alternatives that the whole class of image manipulation apps got commoditised.
If I had an advice to give to my college self, I would advise not even starting with Adobe: if you're a designer and use their tools, the tools you need to make money with isn't even available for sale, you can only rent. So you might end up in a place where Adobe jacks up the price of Creative Suite by 10-100x per month after becoming dominant like Oracle, and you would have to pay your dues to their feudal fiefdom just to be able to continue your profession - else you'll starve. Not a great place to be for anyone.
Even if Microsoft is gauging companies with licenses.
https://affinity.serif.com/en-us/photo/
Do you have power management (and sleep) working on amd?
> Do you have power management (and sleep) working on amd?
Yes (null-power-mgmt.kext) and yes. Though mind that this is a desktop, so power mgmt. / sleep needs are much less demanding than a laptop.
Specifically, the kext works by disabling power management from within OS X. However I have a kill-a-watt and the the power from the plug varies based on the CPU load, so it seems to be behaving correctly.
That said, I would not do this on a laptop. Just buy a MacBook Pro if you need that. My hackintosh needs are strictly because Apple (until a week or two ago) just didn’t make a computer as powerful as I needed. I’ll probably just go buy a Mac Pro in the first chance.
With me being a quiet computing / low power fanatic, null power management isn't good enough I'm afraid. Not to mention that amd-osx says "sleep will either work or not".
Using a hackintosh desktop for the same reason as you and yes, considering getting a Mac Pro. But it's good to be aware of your alternatives.
Making it with AMD is very tempting, but the fear is less compatible and will break even more than intel hackintosh?
Intel Xeon 8280 QS is $1,800 USD each, a pair of those (56 cores) on a supermicro mb with 12 x 16G RAM is about $5k USD. It has an impressive Cinebench R15 score of 7,800+
https://ark.intel.com/content/www/us/en/ark/products/192478/...
That's a lot of caveats to hide behind two letters.
You voiding your contract with Intel does not make me a criminal. At best this is a civil tort.
Trafficking in stolen property is illegal in all 50 states, although the severity and specifics vary. If you buy them across state lines, 18 U.S. Code § 2315 also applies, making it a federal crime.
And taking and selling the QS/ES chips is not "voiding your contract". It is theft, and given the value of the chips, would qualify as a felony.
It's exactly the same as if I were to lend you my bike and you were to sell it to someone else. That someone else is buying stolen merchandise.
> [...] are the sole property of Intel [...] Are not for sale or resale.
So, whoever sells ES/QS chips is selling the property of someone else without authorization to do so.
Incidentally, the cost of the Xeon Platinum 9200 are also given in the article.
Looks like clickbait to me.
Question: for single threaded performance (*n where threads are independent) do I want higher watts per core or higher number of cores? By "performance" I mean throughput.
Or perhaps they are trying to hurt Intel by selling it at a price where Intel can't make a profit if they lower their prices to be competitive?
Or, maybe it has to do with trying to quickly grab market share. Maybe AWS and other purchases of servers have a somewhat fixed budget, so cheaper chips translates directly to more chips sold?
Both those explanations seem unlikely to me.
AMD is working around this by using 8 separate CPU chips, wired together with one interconnect chip.
Intel is reeling from major design flaws and process stagnation right now. It makes sense for AMD to punch hard. Now is the time.
Also note that the eternally predicted ARM64 wave into servers, workstations, and cloud is not materializing. So far nobody has been willing to build such high performance chips and price them aggressively enough. All things considered it's an amazing window for AMD to take the market lead.
Personally I think Epyc this cheap really harms ARM's chances in the data center.
If Apple goes ARM64 for Mac it could indirectly help ARM get into the DC by showing that ARM is not just for small stuff.
Longer term you also have the RISC-V wildcard. A mostly free core and ISA could in theory move the whole game to the foundry and lead to a race to the bottom on price/performance.
It really depends. As long as performance is there and the apps work as expected, I'll deploy my workloads on whatever runs them for the best cost per transaction. Additionally, we don't have a say on what architecture our hosted services are on - if AWS decides my RDS databases are to move to ARM64, or Google decides my CloudSQL will run on POWER9 - I probably won't notice as long as the performance is right.
In the past I have deployed production Python-based workloads to amd64 and SPARC (I did POWER too, but for fun) without change. I'm most certain I can do the same with ARM64 or RISCV.
It’s going to be a huge factor in the DC. Never before have people been able to customize silicon. And now (ish) they can for figures that make sense to more than just the usual suspects.
Edit-I’m seeing some articles that make it look like arm might already be usable on Windows. There’s still legacy software issues though.
A serverless environment cares even less.
There is no oxygen down at 8k for Intel, they will have to move to chiplets to get the yields up, to drop the prices that far. AMDs costs for these parts is probably double what the consumer versions are, so we are probably looking at 7k+ of profit per chip.
They are forcing Intel to move to chiplets or be really really wounded. Clearly AMD is not participating in a duopoly game, which would be the expected anticompetative behavior.
If I were AMD I would give away the mobos. This is going cause a lot of Intel parts to be EOLd early.
If they priced at intel-$1k, for instance, many organizations would rule it out because the operational and additional hardware costs to switch would easily dwarf the $1k discount.
Sort of like people still buy gas cars even though the long-term economics of electric make so much more sense. The math has to be obviously beneficial (e.g. same sticker price, same range) for the switch to happen en masse.
AMD is not trying to get as much money out of it, they're trying to get market share, in a segment of the market where "single product line all identical all across" is a big thing.
Last time they were on top they didn't, and Opteron failed to take enough market share (a story that is not as well known because the bigger one was the customer chips and Intel abuses with oem). They don't want a repeat.