AMD Threadripper prices undercut Intel's Core i9 by as much as $1,000 | Hacker News Reader

AMD Threadripper prices undercut Intel's Core i9 by as much as $1,000

pcworld.com

126 pointsdoener73 comments

Like I have written in the other thread already: add to that the ECC support of Threadripper [0], 20 more PCIe lanes and no raid key shenanigans (on Intels x299 you have to pay 100$ extra for RAID 1 and 300$ for RAID 5 support with their VROC feature [1]). Unless you really need AVX 512 and better single thread performance (and 2 more cores in case of the not available 18 core part), why would you buy Intels new offering? Because you can reuse the cooler since it's compatible with x99?

[0] https://www.reddit.com/r/Amd/comments/6icdyo/amd_threadrippe...

[1] https://youtu.be/TWFzWRoVNnE?t=11m38s

>on Intels x299 you have to pay 100$ extra for RAID 1 and 300$ for RAID 5 support with their VROC feature [1]

This really bothers me about Intel. It's not like they have a separate die for these chips. They are literally charging you to flip a switch on something you already paid for.

They didn't used to do that. I feel that it became more and more common the less competitive AMD became, in some kind of direct correlation. (Not that this is some kind of big surprise)

So hopefully the fresh wind and competition that AMD is bringing forward will put the pressure back on.

If it makes you feel any worse both AMD and Intel provide cheaper chips by disabling cores on more expensive chips.

To me it's fine -- it's just a method of manufacture. No different than buying different versions of software.

"They are literally charging you to flip a switch on something you already paid for." << To be clear, physically you have the thing in your possession, and you could physically figure out how to flip the bit or re-enable disabled cores (people do try this). I'm 100% for that being legal since it's a physical device -- no DRM for me. But I'm also 100% OK with them doing this to begin with if it makes it cheaper for them to give me their base product.

Don't they generally disable those cores because they have more flawed silicon?

Yes.

So you're saying no to DRM (which I fully agree on). But hen you seem to say DRM is fine if it makes products cheaper.

That's basically you hopping onboard with DRM. It's always the excuse of manufacturers that their DRM makes things cheaper or more secure (the latter is what Intel used on its ridiculous ME).

It's not drm if you're allowed by law to circumvent it when you know how. At that point it's obfuscation.

Not that I really agree with their decision, but to play devil's advocate: they are essentially creating multiple products without having to waste effort and resources on creating separate dies, and without you having to throw away money (e.g. selling your used board) to get new features.

My money says that they were probably set on multiple product levels, and some engineer said "hey, we can be less wasteful here by creating only one board." So now you can pay $100 to unlock RAID 1 whereas before you would've had to either pony up before you needed it, or sold your used $500 board for $350 to buy the new $600 board with RAID.

Again, not saying I agree with the decision to charge for RAID when it's obviously included already, but that it's probably at least less wasteful than the alternative of actually having separate dies.

You have this backwards. Well, mostly. Having a separate die is definitely not the other option. A separate die would cost millions of dollars to develop, test, and produce separately, even for a smallish feature like this. The resulting price hike to cover the R&D would push the product even farther out of the competitive market than they are now.

No, the only two options are the ones Intel and AMD have already taken: artificial segmentation via feature flags, or just opening it up entirely.

I don't really like the artificial segmentation thing but I can't seem to reconcile that feeling with my feelings on software licensing, which doesn't bother me but can be the exact same thing.

The artificial segmentation I don't like because I view it as a market failure. In a more competitive market they probably wouldn't be able to segment it like that

It is important to note that this is the launch retail price.

AMD's design is cheap and high yield so they can cut prices a long way.

I'm just glad AMD are still competitive.

Seemed like for a few years there they might almost gone out of business. I think consoles have helped keep them afloat in the bad years too.

Obviously Intel will respond to this (either via hardware or pricing) but the fact they even need to respond to something is a good thing. The only thing that has been eating Intel's lunch in recent years was mobile.

> I think consoles have helped keep them afloat in the bad years too.

That and their desktop GPUs. Their ATI acquisition turned out to be pretty vital.

I swear I thought ATI had diverted their attention away from CPU so they lost the edge.

I feel like they were doing well until they bought ATI. Then they ran out of cash, less R&D money, and then they had to spin their fab to global foundry.

Now it seems like CPU is slowing down while GPU is growing especially in scientific stuff.

Super glad they're decent now, hopefully good. I don't want to deal with Intel monopoly.

AMD screwed up when they decided to make something similar to the P4 arch (high clock speed, long pipeline) after they spent the previous 5-7 years beating it using high IPC, lower clock speed cores. I still don't get why they did this...

AMD cannot go out of business, in my opinion. They are the only other company licensed to produce x86, and the license is non-transferable. If they die, Intel faces instant monopoly issues.

AMD will stay around. Next time their stock dips big one day, get some.

This was my opinion 5 - 7 years ago. I wish I wasn't afraid to buy stocks.

Interesting that their console microarch (Jaguar) was really great. So good that even after Intel one-upped them with non-crappy Atoms (Silvermont) they released competetive offering which was basically just an evolution (Puma).

The 12 core threadripper (1920) is comparable with the 10 core 7900X in temrs of milticore performance, while still $200 cheaper. You can't compare only on the basis of core count as this review did.

More detailed review here:

http://wccftech.com/amd-ryzen-threadripper-1950x-cpu-perform...

I have an FX 8350 which is serving me ok at the moment but would love to upgrade to ThreadRipper soon. I was tempted to build a dual E5-2670 system but glad I held off now. I have some fairly weighty OpenStreetMap crunching that could definitely benefit from loads of cores, and nested VMs might be an interesting usage.

Any reason not to prefer AMD CPUs for VR applications, given the price difference?

Some applications need 70+ cores. AMD doesn't have that.

64 cores on 2P EPYC 7601/7551/7501. Intel has its 4P platform, which in theory almost doubles the ceiling (4 * 28 cores in the top tier Xeon Platinum aka new E7). If you really need that many cores, you should either use specialized hardware (GPUs, FPGAs etc.) or clustering anyways.

There's a thing in between. Think Thunder ARM chips or Power8

The Intel top x-series (that competes with Threadripper) only has 36 cores (not 70+), is limited to a single socket, and it's not shipping yet.

Even with dual sockets 70+ cores is not easy (or cheap) and other things like memory performance become more important than core count. AMD has a bandwidth advantage with single and dual sockets having 8 channels per socket instead of Intel's 6.

Intel doesn't have competition with 4 or more socket systems, but that topic drifting pretty far from a thread discussing Threadripper.

Which Intel part has 36 cores? Do you mean threads, or is there a Knights Landing card with so few cores I'm not aware of?

I scale my CAD-like software to high core counts. Memory performance from the hardware side isn't a tunable parameter.

If you need the performance, AMD has no product in this space.

Memory performance is just as tunable as core count. Ryzen = 2 channels, Threadripper = 4 channels, and Epyc is 8 channels per socket for 1 or 2 sockets. So there's a factor of 8 to pick from.

I'd be surprised that a CAD program prefers cores over memory bandwidth. Generally if you have a complicated 3D object doing anything with that object isn't going to be cache friendly.

Have you tried your CAD-like software on two platforms with the same core count but double the memory channels?

Yeah, so a large part of my optimization is to move from memory to compute bound. But things like matrix inversion, for example, thanks to the hard work of library authors can scale pretty well. This happens on the CPU because the data typically exceeds GPU memory. So, you can get out the box scaling for much of your code.

The 3D rendering is taken care by the GPU.

CAD 'needs' 70 cores and CAD is VR? Let's not get carried away.

Some OSes are terrible at NUMA

What VR application needs 70 cores?

Also AMD is going to have dual socket 32 core Epyc available this year.

Sad that the cheapest skylake-x with 4 memory channels (double the bandwidth) is $390 (i7-7800X) and the cheapest threadripper is $800.

So AMD is competitive with a $2k chip that sells in extremely low volumes, but not at $400.

Are there any applications that are RAM bandwidth-bound, though? The main bottleneck is supposed to be RAM latency.

Going from single channel to dual channel offers like an 8% performance increase, IIRC. Is there any reason to expect any different with quad channel RAM?

I can chime in and say that memory bandwidth is our primary bottleneck on servers at my current company.

The only situation where I imagine that could happen is if you need to apply a small number of instructions to a massive data set that's fully loaded in memory. What sort of application are you running? If you can say, obviously.

That's exactly the case.

I run dedicated gameservers. We preload "phases" which you can affect and transition to/from as a player.

> The only situation

There are many more:

- Caches/Databases that should keep as much stuff in memory as possible (i.e. if you have a 32gb es instance you actually gain a lot from "fast memory")

- In-Memory Databases

- In-Memory RPC/message broker which of course has as a limitation factor the memory bandwidth.

In all cases the memory bandwidth might be a important factor.

For all the cases you mention, the critical factor is the product of the average transaction size and the transaction count per second. As long as this value is smaller than the RAM bandwidth, the application will not be RAM bandwidth-bound.

Generally speaking, databases are kept in memory to minimize latency, not maximize throughput. Bandwidth is not really a problem. Having to update 10 GB/s of a database would be highly unusual. Having to get data from random positions in a disk or SSD is much more common.

As for the message broken, it's not clear to me why the bandwidth would "of course" be the limiting factor.

For sufficiently large values of small. An 8 core CPU @ 3 GHz runs 24 Billion clocks/sec. In any of which a CPU can execute multiple instructions.

Two channel memory systems assuming DDR4@2400 can do about 40GB/sec. Thread ripper is about double that (of the skylake-x, but NOT the kabylake-x). The new skylake xeons are 6 channel (about 120GB/sec) and the new AMD Epyc is 8 channel (about 160GB/sec).

Assuming a perfectly sequential access pattern and something simple like a=b+c (which reads 16 bytes and writes 8 bytes) you can run 1.6 billion of those a second.

So to not be memory bound you need to run an extra 15 times more instructions... without adding any cache misses, just to execute one instruction per cycle (a fraction of the possible). If it's less you are memory bound.

Now imagine it's not perfectly sequential, and instead you have to retrieve something from memory before you know where to go next. Like say a database index, binary tree, or linked list. Instead of getting 8 bytes @ 2400 Mhz you get 8 bytes per 70 ns. Keep in mind that's 8 bytes per 1/2.4 ns vs 70 or 168 times worse.

Suddenly instead of needing 15 times more instructions you need 2500 instructions per memory load, all without a extra cache miss.

So as you can see it can be quite easy to be memory limited. Sure some things do an amazing amount of calculations on very little data. But many things are data intensive, which justifies the large ram and large memory bandwidth machines that make up pretty much all servers shipped today. Memory bandwidth is expensive (CPU package, pins, sockets, motherboard traces, additional motherboard layers, power, etc), but well justified in many cases.

You are again conflating high bandwidth and low latency.

> So to not be memory bound you need to run an extra 15 times more instructions... without adding any cache misses, just to execute one instruction per cycle (a fraction of the possible). If it's less you are memory bound.

Yes, if you do operations in a lineal access pattern like this the performance will be bound by the bandwidth. This is the situation I was referring to above.

> Now imagine it's not perfectly sequential, and instead you have to retrieve something from memory before you know where to go next. Like say a database index, binary tree, or linked list. Instead of getting 8 bytes @ 2400 Mhz you get 8 bytes per 70 ns. Keep in mind that's 8 bytes per 1/2.4 ns vs 70 or 168 times worse.

> Suddenly instead of needing 15 times more instructions you need 2500 instructions per memory load, all without a extra cache miss.

> So as you can see it can be quite easy to be memory limited.

No, in this case you will not be limited by the bandwidth, but by the latency. Having more bandwidth will do nothing, because at 8 bytes per 70 ns you're only moving about 109 MiB/s. If 100% of the memory accesses are cache misses (they won't be) and the application uses all cores then yes, doubling the number of memory channels will double the multi-thread performance (unless channel count = core count), although the single-threaded performance will stay unchanged. Additionally, in this particular load you could get away with relatively low frequency RAM, which won't significantly affect the latency but will lower the total bandwidth (it will still be way higher than 109 MiB/s) and will be cheaper.

Er, when I say "memory limited" you say I'm wrong because it's latency limited not bandwidth limited. I think we are violently agreeing. Latency limited is just one specific form of memory limited.

In my testing (to my surprise) it turns out that throughput keeps increasing at up to 2 times the number of memory channels. So with 8 memory channels throughput keeps increasing at up to 16 threads, which upon reflection makes sense. Generally it takes 25-40ns to miss through L1, L2, and L3 -> memory controller. So with 16 misses and 8 channels you end up with all 8 channels busy, and 8 more misses queued and waiting in the memory controller. So your throughput approximately doubles from just 8 threads.

In any case, I agree that single thread performance isn't improved by multiple channels and that latency limited workloads get a small fraction of the potential memory bandwidth.

Well what exactly do you mean by latency? Say 8 cores are randomly accessing memory. A quad channel system will have twice the throughput of a 2 channel because there can be twice as many cache misses being handled at once.

For this reason many generations of HEDT and server chips have had 4 channels for many years and are quite justified. Take a 5 year old opteron or xeon for instance, or even an sandy bridge ( i7 like the i7-3820). Sandy bridge is 5 generations old, if 4 channels was justified then it's definitely justified today with today's faster and more numerous cores.

The X-series is new branding, but Intel has been selling i7 chips with the LGA-2011 socket supporting 4 memory channels for years.

So sure if you are cache friendly, great, as many cores as you can fit in a socket. But many applications aren't that cache friendly.

> A quad channel system will have twice the throughput of a 2 channel because there can be twice as many cache misses being handled at once.

Sure, that's the theory, but in practice it doesn't seem to make much of a difference, at least not for dual vs. single.

There exists cache friendly applications that see zero to minimal change with more bandwidth or more channels.

There also exists cache unfriendly applications that see large changes with more bandwidth or more channels.

Games generally are cache friendly, many easy benchmarks are cache friendly. But generally more aggressive use of a machine (which is presumably why you buy a top spec CPU) is generally less cache friendly. Also people notice worst case performance much more than average or best case. Audio skipping, user interface lag, etc.

You can see this effect in action when you compare single thread performance to multithead performance using every CPU. L1 caches are generally note shared, so if it's less than N times faster for N CPUs you are seeing software overhead (the cost of synchronization) or cache misses (in L1, L2, or L3) or of course main memory bottlenecks.

I've seen plenty of cases on older servers where running on all CPUs of single socket was FASTER than all CPUs of two sockets, but that's much less common these days because each socket has it's own memory system.

I can assure you that the entire server market and high end desktop market isn't running 2 to 8 time the memory bandwidth just for fun. The bandwidth is expensive and justified.

An application being cache-unfriendly doesn't imply that it will be bandwidth-bound. If the application reads single words from random locations it will be cache-unfriendly and latency-bound. If it reads 1K contiguous bytes from random locations it will be cache-unfriendly and possibly bandwidth-bound. If it scans the entire memory space sufficiently quickly it may be both cache-friendly and still bandwidth-bound.

I can't speak for the server market, but I'm certain that the high-end desktop market is composed primarily of people who do run top-of-the-line specs just for fun.

Correct, an application that reads single words from random locations will be cache unfriendly and latency bound. However additional memory channels means you can run more of them and get better throughput.

Personally I bought more cores when I can and find that the average and best case are very similar to CPUs with less cores, but the worst case performance is much better. With 8 CPUs I find that the browser, plex, processing batches of photos, transcoding video, running a minecraft server and other random duties have much less of an impact on normal desktop use.

It used to be MUCH easier to be I/O bound with spinning disks, but with the new M.2 SSDs some pretty impressive I/O rates are possible (random or sequential), which makes it easier to be CPU limited.

Would it not make more sense to compare the price of a 6 core and 12 thread intel chip with a 6 core and 12 thread ryzen like the 1600X?

EDIT: ah the 1600X only has duo channel for memory.

No, core count is meaningless. What matters in most desktop cases is price per performance , especially price per performance in your specific use (what's your percentage of single thread vs multi thread work, mostly). In a server scenario often performance per watt will be king.

If Ryzen can deliver a similar Cinebench score to a CPU hundreds and hundreds dollars more expensive then they have a something. Whether they do that by occult magic or squeezing more cores/threads in, doesn't matter to the end user.

Why is that sad? Intel didn't even have those chips on the roadmap until AMD punched them in the face with Ryzen.

Furthermore, how about that ECC memory? What good are 4 memory channels if I can't actually rely on the memory?

Competition is a good thing... and you can't exactly expect AMD to match every last SKU Intel has been holding back.

I keep hearing this sentiment from, what I suspect are, people rooting for the underdog that is AMD. And there's nothing wrong with that, competition for Intel is a good thing, but it's pretty naive (at least in my opinion) to think Intel doesn't plan product lines out more than a few months.

I can believe Intel might change prices in response to competition, but I don't get why people are acting like Intel can magic up a chip line because "AMD finally made some competitive chips"

I could imagine them stockpiling chip designs for when they experience competition or sales pressure.

I think you are right and wrong. Yes silicon pipelines take $billions and many years to go to from a new implementation to a fabricated, tested, and shipped product. Around a year for a minor revision.

However Intel has significant flexibility on hitting price/performance points by tweaking enabled features (memory channels, ecc, virtualization support, accelerated crypto, etc) and of course playing with clockspeed and power.

So the new x-series for instance has all the marks of a rushed product launch rebranding existing chips (the LGA20XX xeons). So things like overheating VRMs, poor heat spreader design, minimal clock headroom, and poor availability. In fact the top x-series isn't expected to ship until the end of the year.

Also Intel knew Epyc was coming so while quietly shipping skylake based xeons to large cloud providers while waited for AMD to show their hand with the Epyc launch. Only after Epyc did Intel announce details on the already shipping skylake xeons.

Suddenly Intel's talking about desktop chips with more than 4 cores after a decade of quad cores (Q6600 in 2007). Think that would have happened without Ryzen?

I also expect sudden changes when AMD ships the the Ryzen based APUs.

The 18 core i9-7980XE is widely thought[1] to be a direct response to the 16 core Threadripper announcement. It was announced late, with much less info. It has a expected release date months later than the rest of the i9 lineup, and is using higher core count silicon that Intel has previously only ever used in Xeons.

[1]http://www.anandtech.com/show/11464/intel-announces-skylakex...

Mainly I was hoping to buy a thread ripper instead of a RYZEN 1700 (for $300) and getting more memory bandwidth. I was hoping that with AMD pushing so far on more cores that AMD would push more memory bandwidth to lower price points.

I'm all for ECC, but the Ryzen ECC situation is a mess. Some boards don't mention it, some boards mention ECC, but don't differentiate between ECC dimms "working" and actually correcting errors.

If ECC is your priority seems like a Xeon E3-1230 or similar is an easier decision. With that said is there a known motherboard + ryzen combination that A) works, B) is available, C) is verified to actually correct bits, and D) talks to the Linux MCE widgets to the OS can track it?

My Asus + Ryzen build definitely does not talk MCE in a way that Linux understands

https://serverfault.com/questions/858884/spontaneous-reboot-...

There is a list being actively managed around ECC support:

http://www.overclock.net/t/1629642/ryzen-ecc-motherboards

Are there Intel specific instructions that may not be implemented on the AMD processors? I do allot of EM simulation, and my software installs the Intel MPI Library:

https://software.intel.com/en-us/intel-mpi-library

Will I take a performance hit; maybe that question can only be answered by the software developers?

I know the VOLK library used by GNU Radio is used to abstract away vector operation, so your code can take advantage of specific instructions on Intel, ARM, etc.

They support pretty much everything up to AVX2, though that is more of a compatibility implementation.

Though its dubious Intel MPI and other software will use the correct accelerated path even if an AMD processor supports it.

From that MPI link:

"Optimization Notice: Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804"

http://www.agner.org/optimize/blog/read.php?i=49#49

TLDR; Intel purposely chooses slower code gen paths for AMD processors in ICC.

> The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.

This is surely legal but distasteful. They are attempting to manipulate people's perception of competitors' products do that they do not switch, even when the potential performance would be the same if a fair analysis were applied.

I have been an Intel guy my whole life but I can only hope that their near monopoly is destroyed by AMD.

Do you know if it's easy to patch the binaries so that this effect is nullified?

From my experience, Clang 5 on O2 will beat ICC with its libraries on its most aggressive optimization setting in real world large applications.

Has this recently changed (e.g. was it different from v4)? Or was it always the trend?

For numerically heavy software it's fairly recent.

That said I cross compile a 15k LoC numerically heavy app with ICC 2017 and Clang 5 (also MSVC which is not really in the running) and clang handily beats ICC.

Most of the win from clang seems to come from small vector and small string optimizations along with better inlining and whole program optimization.

ICC has better vectorization, but it's a smaller part of the performance than it might seem. Moreover, if a core loop is banking on vectorization, you should probably code it in intrinsics at that point to make sure it's always correctly optimized

Oh cool, okay thanks!

Source?

My work

Let's see a link then.

I believe, (don't quote me), that the intel MPI can be replaced by any other compliant MPI library. MPI tends to be used for distributed computing not single processor computing so most likely it won't affect your personal machine.

AMD does not have AVX512 support, which could have an effect on very heavy numerics.

VT-x and VT-d are definitely not on AMD. AMD has its own versions of these sets that do basically the same, though, and AFAIK all hypervisors support both.

Reply on news.ycombinator.com