I'm talking about Netflix CDN servers. The workload is primarily file serving. The twist is that we use a non-NUMA aware OS (FreeBSD).

We're not latency sensitive at all. The problem we run into with NUMA is that we totally saturate QPI due to FreeBSD's lack of NUMA awareness.

The results you link to don't match with what we've seen on our HCC Broadwell CPUs, at least with COD disabled. Though we only really look at aggregate system bandwidth, so potentially the slowness accessing the "far" memory on the same socket is latency driven, and falls away in aggregate.

If you remove things from the instruction set, any code that uses them will either crash or run very slowly in emulation.

Most uses of special instructions will check feature bits or CPU version, but not all will do so correctly.

(I'd say that the additional area cost of something like this is small, and the big cost of special instructions is reserving opcodes and feature bits)

Short story: because its role as a crypto hash function is sort of obsolete given that it's been proven to be broken, and faster, more secure alternatives exist.

But for all practical purposes, SHA1 isn't about to disappear. MD5 has been shown to be broken since forever and people still write new code using it today.

And still is ;) Partly because some key work loads just did not run well on GPU's due to lack of addressable memory. Lots of amdahls getting in the way. Some of the key use cases required stupendous large memory machines (genome assembly using only short reads).

Then a lot of code is very branchy but massively parallel leading to clusters of pure CPUs to be more flexible, which is important in research settings, and with higher utilization than mixed CPU/GPU clusters.

GPU code takes longer to get to market and has more specialized skills required then standard CPU orientated programming. Late to market means you miss a whole wave of experimental methods from the lab. i.e. GPU short read aligners came when long reads started to come out of the sequencing lab. Leading to people to stop doing short reads or at least stop doing pure short reads.

Secondly quite a bunch of the key staff at the large research institutes had been burned by previous hardware acceleration attempts and where not going to throw money at it until market proven.

Bio-informatics tends to cutting edge (the hemorrhaging kind) on the bio/lab tech side yet the production IT tends to balance that to doing the things we know as we already have enough risks. i.e. focus on the algorithms and robustness not on pure power.

Hmmm, isn't deep learning starting to pick up for genetics? No idea if it is actually is, but everyone in DL seems to be talking about it, I thought I'd ask someone actually in bioinformatics :)

Xeon Phi tried to crack this nut and seems to have mostly failed so far.

AdoredTV has a pretty objective video on this subject[1]. TL;DW he expects it to move past Intel perf in the future - based on how an older AMD chip is now beating a then-better Intel chip.

My opinion: if Microsoft is able to pivot the Scorpio over to the Ryzen (or indeed, any CPU with more than 4C/8T) it will drastically alter the lowest common denominator in terms of what game developerss target - i.e. we'll see games moving towards more modern threading architectures (e.g. futures/jobs as-per Star Citizen, which more thoroughly exploit CPU resources).

Furthermore, there is hearsay evidence that supports AMDs claims. Ashes of the Singularity currently runs better on Intel but the developers claim:

[2]> Oxide games is incredibly excited with what we are seeing from the Ryzen CPU. Using our Nitrous game engine, we are working to scale our existing and future game title performance to take full advantage of Ryzen and its 8-core, 16-thread architecture, and the results thus far are impressive.

In addition to that, if you look at the CPU usage/saturation alongside the benchmarks (13:08 in [1]) it's strikingly obvious that the CPU is not the bottleneck - Intel is upwards of 90% on all cores while the Ryzen hovers around ~60%. I'm holding my credit card close until the aforementioned optimizations and rumored bios patches land, but I'm willing to give AMD a little benefit of the doubt - what we're seeing largely matches what they are saying.

[1]: https://youtu.be/ylvdSnEbL50 [2]: http://wccftech.com/amd-ryzen-launch-aftermath-gaming-perfor...

Sorry but for years the mantra was for a gaming pic to invest in a i5 or even an i3 and spend the extra money in a good GPU. But for some bizarre reason suddenly everything that is not performing as an i7 7770k is a "bad cpu for gaming". It's ridiculous.

Hell in 30 million households there are 8 jaguar x86 core gaming machines active now with an IPC that is probably (I assume) atrocious.

I build my i7 4770 4 years ago and the sad part is that it will probably still take a lot of time for it to become a bottleneck in 90% of the games.

CPU intensive != single threaded

Were you around for when bulldozer came out? There were huge problems with Windows task scheduling that were later fixed with updates.

Think of it this way, the original Niagara (T1) was an in-order CPU. That is, instructions were executed in the order they occur in the program code. This is simple and power efficient but doesn't produce very good single thread performance, since the processor stalls if an instruction takes longer than expected. Say, a load instruction misses L1 cache and has to fetch the data from L2/L3/Lwhatever/memory. Now, one way to drive up the utilization of the CPU core is to add hardware threads. And the simplest way to do that? Well, just run an instruction from another available thread every cycle (that is, if a thread is blocked e.g. waiting for memory, skip it). So now you have a CPU that is still pretty small, simple and power efficient, but can still exploit memory level parallelism (i.e. have multiple outstanding memory ops in flight).

Now, the other approach, is that you have a CPU with out of order (OoO) execution. Meaning that the CPU contains a scheduler that handles a queue of instructions, and any instruction that has all its dependencies satisfied can be submitted for execution. And then later on a bunch of magic happens so that externally to the CPU it still looks like everything was executed in order like the program code specified. This is pretty good for getting good single thread performance, and can exploit some amount of MLP as well, e.g. if a bunch of instructions are waiting for a memory operation to complete, some other instructions can still proceed (perhaps executing a memory op themselves). So in this model the amount of MLP is limited by the inherent serial dependencies in the code, and on the length of the instruction queues that the scheduler maintains. The downside of this is that the OoO logic takes up quite a bit of chip area (making it more expensive), and also tends to be one of the more power-hungry parts of the chip. But, if you want good single-thread performance, that's the price you have to pay.. Anyway, now that you have this OoO CPU, what about adding hardware threads? Well, now that you already have all this scheduling logic, turns out it's relatively easy. Just "tag" each instruction with a thread ID, and let the scheduler sort it all out. So this is what is called Simultaneous Multi-Threading (SMT). So in a way it's a pretty different way of doing threading compared to the Niagara-style in-order processor. Also, since you already have all this OoO logic that is able to exploit some MLP within each thread, you don't need as many threads as the Niagara-style CPU to saturate the memory subsystem. So, this SMT style of threading is what you see in contemporary Intel x86 processors (they call it hyperthreading (HT)), IBM POWER, and now also AMD Zen cores.

As for benchmarks, I'm too lazy to search, but I'm sure you can find e.g. some speccpu results for Niagara.

Yes, but those are widely implemented and thus available more or less everywhere. I'd rather use a slightly less ideal hash function, than use an untested one.

Your noise scale is off. 60dB is restaurant conversation level noise.

For comparison, Notebookcheck's system noise scale is 30dB=silent, 40dB=audible, 50dB=loud.

> Recommendations for office spaces is that noise be kept < 60 dB IIRC.

I'd quit if I had to work in an office space with 60 dB noise. That's like sitting next to a rack of 1U servers at "moderately angry bee swarm" fan level.

I personally cannot stand to be near a noise source above 40 dB for any extended length of time (more than a few hours).

But 60 dB... wow. Can't imagine how shitty that must be to work in for 8 hours per day.

The Ryzen 7 1800X has a TDP of 95W and beats the 140W Intel i7-6900K by 4% in performance. They've made some huge jumps in power efficiency.

I don't know if AMD will make a new architecture or not, but I can't see why they wouldn't just release 32 Ryzen cores side-by-side and underclocked at the stock configuration.

Ryzen is highly-efficient up to 3.3GHz:

https://forums.anandtech.com/threads/ryzen-strictly-technica...

They will likely drop the clock. I don't think the market cares at all about how much a CPU takes. If a 1U box has competitive performance AND better performance/watt then it's attractive. It if has worse performance/watt than it's not.

AMD might well steal some of the dual socket market with a dual socket, and maybe some of the quad socket market with dual sockets.

Considering that the current ryzen at $500 is relatively competitive with the $1,000 intel (basically a relabled Xeon with 4 memory busses in the LGA2011 server socket) a quad module (32 core/64 thread) in a socket sounds pretty good. Even if it's more watts than the intel.

The E7's go to 160W each. If you can drive better than 1.7x the performance and stay within the maximum thermal output per physical volume, I see no reason why not to use this.

One reason, perhaps, is if my binaries are compiled with Intel-specific optimizations and it's inconvenient to deploy separate AMD-optimized binaries.

I can see a use case for it, as long as it delivers on performance. No one minds high TDP, as long as it offers a performance advantage. Hell, some servers have 4-8 Titans in them, and no one is complaining about their TDP. If a 260W CPU TDP is justified by the performance, no one will care.

On highly concurrent PG systems by when using parallel queries you are sacrificing throughput for better latency. You really don't want to use more than a fairly small number of workers per single select.

Is that still a problem with cheap NVMe drives that can do 500k IOPS?

AFAIK probably a bit of both. A majority of genetics/biology workloads are I/O bound (mapping, blast, etc) and/or require a lot of memory (i.e. de novo assembly of genome)

On the other hand many of the bioinformatics software solve a specific scientific question and usually are written by people with mostly non-computational background. They use higher level languages such as Python/Perl/R and people often don't have the expertise or time to implement them for GPUs.

However now that machine learning and deep neural network approaches are being picked up by the field, the workloads might change a and also there are frameworks that make it easer to leverage GPUs (Tensorflow, etc)

I don't think it is because no one has tried it as much as the fact that the workloads need the cpu architecture / are not easily parallizable (as far as I understand). Comp bio in genetics is largely sequence alignment & search, which is still largely CPU / memory bound; but I don't understand programming enough to speculate if development in algorithms will allow GPUs to be used because the problem itself is not parallelizable. I think of it as the difference between a super computer & a cluster..

(More than a decade ago, I struggled to / barely succeeded in building a Beowulf cluster; I am just amazed at how far both the hardware & the software tools have come..)

In other areas of comp bio though, GPUs I think are finding use. Protein folding, molecular dynamics. Also, with STORM & such: super resolution microscopy? I think increasingly, gpus will become important.

Also, whole cell simulations?

FPGA type applications will probably pay way bigger dividends than GPU acceleration ever will.

GPUs excel at problems where you can apply exactly the same logic to lots of data in parallel. CPUs can handle branching cases, where each operation requires a lot of decisions, a lot better.

Sufficiently large FPGA chips could accelerate certain parts of the workflow, if not the whole thing, since they're extremely good at branching in parallel. This is why early FPGA Bitcoin implementations blew the doors off of any GPU solution, each round of the SHA hashing process can be run in parallel on sequentially ordered data if you organize it correctly.

In the past several years, quite a few developers have tried GPUs for analyzing bio-sequences, but found the speedup is modest. Good GPUs are expensive. It is usually better to put that money on CPUs or RAM.

I think he is trying to argue that TDP is a figure about the cooling requirement during peak power usage. Actual power usage may or may not be less during typical workload.

same here