Intel Flagship Core i7-6950X Broadwell-E To Offer 10-Cores, 20-Threads, 25MB L3 (hothardware.com)

MojoKid writes: Intel has made a habit of launching enthusiast versions of previous generation processors after it releases a new architecture. As was the case with Intel's Haswell architecture, high-end Broadwell-E variants are expected and it looks like Intel is readying a doozy. Recently revealed details show four new processors under the new HEDT (High-End Desktop) banner for Broadwell, which is one more SKU than Haswell-E brought to the table. The most intriguing of the new chips is the Core i7-6950X, a monster 10-core CPU with Hyper Threading support. That gives the Core i7-6950X 20 threads to play with, along with a whopping 25MB of L3 cache. The caveat is the CPU's clockspeed — it will run at just 3.0GHz (base), so for applications that aren't properly tuned to take full advantage of large core counts and threads, it could potentially trail behind the Core i7-6700K, a quad-core Skylake processor clocked at 3.4GHz (base) to 4GHz (Turbo).

Comments

20 cores DOES matter

[Anonymous Coward]

make -j 20

That right there would make this thing bloody nice to have... not that I'd be able to afford it!

I can't see Joe Sixpack getting much benefit from it, but for nerdy endeavors: creating software, mathematical simulations, etc, I think this would be the cat's meow.

Me... I'll have to limp along on my existing 2 core 4 thread CPU.

Re:20 cores DOES matter

[Anonymous Coward]

Let me correct my own title: 20 *threads*, not cores.

Re:20 cores DOES matter

[Anonymous Coward]

Last time I checked, if you start 2 threads on the same core then each runs at 55% performance. This means that on a 10-core chip the first 10 threads matter, but threads 11-20 don't matter much.

Re:20 cores DOES matter

[Anonymous Coward]

Sadly a make -j 20 will be limited either by the memory bandwidth or the storage bandwidth, not by the CPU speed.
Some math intensive applications on small-ish data sets now...

Re: 20 cores DOES matter

[iamacat]

How is your SSD speed and thermal envelope doing with make -j20?

Re:20 cores DOES matter

[ArchieBunker]

You can pick up hex core boxes dirt cheap on eBay now. Look for the X5650 or W3680 Xeon boxes.

Re:20 cores DOES matter

[fyngyrz]

I was under the (admittedly vague) impression that was true only if the thread was using floating point.

CPUs that offer more cores and/or threads than they do FPUs is one of the reasons I write a lot of my multi-threaded stuff (image and baseband RF processing) utilizing appropriately scaled integer math.

I have 8 cores with 8 FPUs on my desk, but many of my users are stuck with some of the wheezier I5 variants.

Re:20 cores DOES matter

[Anonymous Coward]

Both of which have such slow single threaded performance that most people are better off with an i3.

I have a W3680 box that runs 8 VDI boxes through citrix xendesktop and the performance is pretty good for that purpose but for gaming its 25-30% slower than my dual core i3 4160 in my cheapy shit gaming box

Re: 20 cores DOES matter

[Anonymous Coward]

Good question - it might end up clamped by other things, but at least up to -j 8, it scales decently well on a current CPU. It's still a big win over -j 4, say.

Compilation has a lot of non-local data access that pays a heavy price for cache misses, so it's not so much memory bandwidth sensitive as it seems. During those cache miss latency periods, other cores can still be doing something.

It might be that 20 is too much to hope for, I don't know. I'm pretty sure it'll scale beyond 8 though.

Re:20 cores DOES matter

[Anonymous Coward]

As a side benefit, "appropriately scaled integer math" can be better in other ways too, depending on the nature of your problem. It doesn't pile all its precision up right near zero, but gives you an even distribution of the precision across the range. That might (or might not) be a much better fit for your problem, depending on what you're doing.

Re:20 cores DOES matter

[beelsebob]

Apparently the last time you checked was in 2004. Hyper threading gets you a lot more than a 10% gain on modern CPUs.

Re:20 cores DOES matter

[Anonymous Coward]

Speaking as someone with a 12 core/24 thread Xeon in his MacPro, no, the memory bandwidth and storage keep up just fine... if you have an SSD like the one in the MacPro.

Re: 20 cores DOES matter

[Anonymous Coward]

Since make is most likely used with C and C++ most I/O will happen on cached header files.

Re:20 cores DOES matter

[U2xhc2hkb3QgU3Vja3M]

Me... I'll have to limp along on my existing 2 core 4 thread CPU.

You think your CPU isn't good enough? I'm still using a Core 2 Duo here!

Re: 20 cores DOES matter

[fyngyrz]

I have my SSDs shipped without a thermal envelope. I just give them time to warm up in the winter before I try to install them or expose them to humidity.

Mods, PS: That was an attempt at humor. I actually do know what a thermal envelope is. :)

PPS: Although I do have my salt water fish shipped to me in thermal envelopes. Otherwise, UPS either overheats them or chills them, and they really don't do well with that.

PPPS: Sometimes I wear a thermal envelope to bed. In winter. Montana, y'see.

PPPPS: Flannel is awesome. :)

Re:20 cores DOES matter

[fyngyrz]

Yep. Although I have to say, I really enjoy working with the domain 0.0-1.0; there are so many neat tricks that can be pulled. You can do them in integer too, but there is hoop-jumping involved.

Re: 20 cores DOES matter

[m.dillon]

Actually, parallel builds barely touch the storage subsystem. Everything is basically cached in ram and writes to files wind up being aggregated into relatively small bursts. So the drives are generally almost entirely idle the whole time.

It's almost a pure-cpu exercise and also does a pretty good job testing concurrency within the kernel due to the fork/exec/run/exit load (particularly for Makefile-based builds which use /bin/sh a lot). I've seen fork/exec rates in excess of 5000 forks/sec during poudriere runs, for example.

-Matt

Re:20 cores DOES matter

[gman003]

You likely have not checked for a while. I saw figures of 120% performance ("each core at 60% performance" as you put it) back under the Pentium 4 HT, 140% under Nehalem/Sandy Bridge, and 150% under Haswell.

Re:20 cores DOES matter

[m.dillon]

Hyperthreading on intel gives about a +30 to +50% performance improvement. So each core winds up being about 1.3 to 1.5 times the performance with two threads verses 1.0 with one. Quite significant. It depends on the type of load, of course.

The main reason for the improvement is of course due to one thread being able to make good use of execution units while the other thread is stalled on something (like memory or TLB, significant integer shifts, or dependent Integer or FPU multiply and divide operations).

-Matt

Re: 20 cores DOES matter

[Anonymous Coward]

It's not what I see when I build a whole arm linux distro with, say, yocto. 100% CPU utilization is rare, while the hard drive never stops whirring.
It very much depends on your particular task.

Re:20 cores DOES matter

[Anonymous Coward]

Still on spinning rust... me cheap bastard.

Re:20 cores DOES matter

[SolarAxix]

If you run at stock speed, you are right.

If you have the right motherboard and the right CPU, you can get some pretty good overclock on these CPUs (if you are into overclocking). I've got a few X5650s setup at home. I can get 4.2 GHz on one and 4.6 GHz @1.34 volts on the other 24/7. With 6 cores (12 cores /w HT), water cooling is almost a requirement at these speeds (unless you are really lucky with the CPU). Max temps for both is ~75 C in a 20 C room. I got each CPUs on eBay for $60 a piece and I already had the MBs.

These days the most expensive part could be the X58 motherboard unless you already have one. Some of them are selling for more used than their new MSRP. One drawback is most X58 boards don't have USB3 or SATA3. You could always get PCIe cards for those, but the bill of material (BOM) would increase.

If anyone is interested, there's an Anandtech forum thread that has a lot of information on it: http://forums.anandtech.com/sh...

Re: 20 cores DOES matter

[m.dillon]

Urm. And you've investigated this and found that your drive is pegged because? Of What? Or you haven't investigated this and you have no idea why your drive is pegged. I'll take a guess... you are running out of memory and the disk activity you see is heavy paging.

Let me rephrase... we do bulk builds with pourdriere of 20,000 applications. It takes a bit less than two days. We set the parallelism to roughly 2x the number of cpu threads available. There are usually several hundred processes active in various states at any given moment. The cpu load is pegged. Disk activity is zero for most of the time.

If I do something less strenuous, like a buildworld or buildkernel, almost the same result. Cpu is mostly pegged, disk activity is zero for the roughly 30 minutes the buildworld takes. However, smaller builds such as a buildworld or buildkernel, or a linux kernel build, regardless of the -j concurrency you specify, will certainly have bottlenecks in the build subsystem that have nothing to do with the cpu. A little work on the Makefiles will solve that problem. In our case there are always two or three ridiculously huge source files in the GCC build that the Make has to wait for before it can proceed with the link pass. Similarly with a kernel build there is a make depend step at the beginning which is not parallelized and the final link at the end which cannot be parallelized which actually take most of the time. Compiling the sources in the middle finishes in a flash.

But your problem sounds a bit different... kinda sounds like you are running yourself out of memory. Parallel builds can run machines out of memory if the dev specifies more concurrency than his memory can handle. For example, when building packages there are many C++ source files which #include the kitchen sink and wind up with process run sizes north of 1GB. If someone only has 8GB of ram and tries a -j 8 build under those circumstances, that person will run out of memory and start to page heavily.

So its a good idea to look at the footprint of the individual processes you are trying to parallelize, too.

Memory is cheap these days. Buy more. Even those tiny little BRIX one can get these days can hold 32G of ram. For a decent concurrent build on a decent cpu you want 8GB minimum, 16GB is better, or more.

-Matt

Re: 20 cores DOES matter

[JoeyRox]

NVME SSDs can do 100k random IOPs. That's an I/O completing every 10us. That's plenty fast to keep a 20-thread compiling pipeline busy with data.

Re:20 cores DOES matter

[ArchieBunker]

Interesting link. My Lenovo box has the an X58 motherboard but I don't think the stock bios will allow for much tweaking. This was still a huge speed boost from my old Q6600 box.

Re:20 cores DOES matter

[nadaou]

It depends on the task. For double precision FP calculations using MPI multi-processing (e.g. FORTRAN CFD), the extra overhead of the extra cores talking to each other mostly cancel out the gains.

For many many small short-lifetime processes you'll probably do better.

Re: 20 cores DOES matter

[Anonymous Coward]

Thermal envelope: what does this term mean to you?

Re: 20 cores DOES matter

[PopeRatzo]

I do have my salt water fish shipped to me in thermal envelopes.

Where do you buy your salt water fish? I have a taste for some sea bass, broiled with olives and capers.

Re:20 cores DOES matter

[BLKMGK]

Video compression. I have tested faster speed CPUs with fewer cores against slower speed with more cores - more cores won. I'm VERY interested in this but suspect the 8 core overclocked might be the fiscally responsible way to go. I'd use a XEON but you cannot overclock them...

I do have an ESX server but I've never been able to find a good compression appliance to use. Something I could use with say a web front-end to upload and just settings for ffmpeg would rock. Anyone?

Re:20 cores DOES matter

[Ambassador Kosh]

Use MPI BETWEEN nodes and OpenMP WITHIN a node. MPI is always going to be slower on a single node than threads are and for HPC type loads it can easily be 100x slower to use processes instead of threads due to communications overhead.

Re:20 cores DOES matter

[Anonymous Coward]

I have a couple of said Xeon boxes. They aren't bad at all. And recently, for about twice the price you can get a dual e5-2660 or 2670, which is the next gen beyond ($1500-$2000). A pair of e5-2670s is actually pretty competitive, CPU-wise, with the super-expensive current-gen Xeons, which might give you 50% more CPU for 4x the price. Servers and hi-end workstations are typically leased, and as they come off lease can be good deals.

Re:20 cores DOES matter

[Anonymous Coward]

In my opinion as an ASIC engineer designing image processing accelerators(ISPs), you are well ahead of the game.

Re:20 cores DOES matter

[Anonymous Coward]

Hyper-threading halves the cache and TLB, so if you a have single threaded memory bound application it will likely suffer.
Also if you have two very heavy FP threads it too could suffer (or at least not benefit) from the second thread.

But for most people, under most work loads, it's a good-thingTM, especially on lower core count machines. The more cores you have, the less likely you are to need virtual ones. I'm not sure I'd turn on HT on a desktop 10-core machine!

Re:20 cores DOES matter

[Carewolf]

I was under the (admittedly vague) impression that was true only if the thread was using floating point.

No, that is the AMD Bulldozer design. Hyper-threading provides no extra CPU power for the additional threads, how much performance you get out of the extra threads depend on how much the threads are forced to stall due to memory access, if they all do integer/fp instructions and memory access that hits the cache, you get only 50% normal performance out of each hyper thread.

Re: 20 cores DOES matter

[MrKaos]

Let me rephrase... we do bulk builds with pourdriere of 20,000 applications. It takes a bit less than two days. We set the parallelism to roughly 2x the number of cpu threads available. There are usually several hundred processes active in various states at any given moment. The cpu load is pegged. Disk activity is zero for most of the time.

Have you ever considered using sar to check the amount of minor page faulting going on? It would be interesting to measure the activity between L3 cache and memory, it's possible that memory is thrashing as the CPU scheduler attempts to divide time between logical cores, that are actually the same physical core.

My applications are messaging systems so they aren't transient processes, like a compile. Over 20,000 applications that is a lot of context switching and from what you have described he amount of latency introduced by the CPU scheduler when it context switches would be high enough to consider tuning your your build process.

In our case there are always two or three ridiculously huge source files in the GCC build that the Make has to wait for before it can proceed with the link pass.

they're probably a good candidate for CPU affinity however I don't think you can isolate a cpu at runtime so unless you bump up it's priority the cpu scheduler can still kick it off L3 and the core it is using. The point I'm making here is if you dedicate a core to these bigger source files the efficiencies you gain may be enough to allow the link to proceed sooner, if that is important to you.

It would also follow that when your processes start generating I/O to write the objects prior to your link phase the processes would all be vying for IO attention and as each gets priority I am almost certain you would see very high levels of minor page faults as the scheduler tries to balance them. You might find that being *unfair* about which process gets access to CPU resources actually reduces your overall compile time.

So its a good idea to look at the footprint of the individual processes you are trying to parallelize, too.

Absolutely! Parallelism is great however you really have to know your processes and behaviour of the CPU and IO schedulers to get the most out of them.

Memory is cheap these days. Buy more. Even those tiny little BRIX one can get these days can hold 32G of ram. For a decent concurrent build on a decent cpu you want 8GB minimum, 16GB is better, or more.

Agreed! Even so it's so slow compared to CPU cache and the expense of throwing a process off a core when you do a context switch is worth investigation as you may still be able to yield good gains. Having more memory is great however having a bigger CPU cache is much better as the CPU scheduler has to context switch less often.

I'm actually more excited about the cache on these things than the cores as that has a greater potential for increasing system efficiency than just increasing the cores alone.

Re:20 cores DOES matter

[DigiShaman]

Since the inception of HT, is there a reason CPU design hasn't advanced to the point of executing 4 threads per core rather then the 2 it always has been? Is it an L3 cache limitation or diminishing laws or return in performance?

Re:20 cores DOES matter

[Big Hairy Ian]

This will kick in in Data Centers where you'll be able to run twice as many virtual machines per physical processor

Re:20 cores DOES matter

[Bengie]

A quick Google returns many people asking this question and others showing Make having a 20%-33% improvement with hyperthreading. That's a decent improvement.

Re:20 cores DOES matter

[Bengie]

Hyperthreading doesn't just benefit on memory stalls. Intel Haswell has 8 execution units and can retire 4 instructions per cycle. Any time there is a free execution unit and 4 instructions are not in flight, hyperthreading can schedule on the other thread. Intel put a lot of effort into increasing out of order execution performance, but not all work loads benefit a whole lot of OoO. This is where HT comes in. When a work load can not fully utilize OoO, much of the CPU core will be idle, and HT allows these idle parts to be utilized. Of course these situations are pathological and each thread has to split some shared resources, which reduces performance a bit. HT is very situation, but work great when it works.

Re:20 cores DOES matter

[TFloore]

Since the inception of HT, is there a reason CPU design hasn't advanced to the point of executing 4 threads per core rather then the 2 it always has been?

Workload and system balance, mostly.

If you look back several years (2008? earlier?) you'll see some Sun Sparc designs, and some IBM POWER designs, that supported 4 or 8 threads per core. They worked well for very specific workloads and applications.

The Sun Sparc designs with 8 threads per core were mostly tailored for "simple" highly-scalable web servers, where a thread is blocking on I/O most of its time, and a web server could spawn many many threads to support many simultaneous connections. Worked very well for that purpose.

IBM did stuff like that with their POWER architecture for terminal servers and financial transaction processing, where, again, the thread spends most of its time blocking on I/O.

You don't get that so much for Intel x86/x64 systems, because, on the desktop side, frankly, most users don't use 4 cores well, and the few that do aren't doing I/O-blocking tasks, they are doing CPU-bound tasks, video encoding, stuff that hits the SIMD units hard. HT doesn't benefit nearly as well for CPU-bound tasks, and that market is small enough not to be worth the extra architecture/development time. For x64 servers, there is a bit more of a market there, but Intel would much rather serve that market with their high-end Xeon 4-socket systems. 10 cores per CPU, 4 CPUs, you get 40 cores and 80 threads. Oh, and you pay about $4,000 per CPU that way. That also gets you ridiculous amounts of RAM, and better networking support too. Usually you want both of those on your 80-thread server system, anyway.

So I suppose the answer is, basically, it has, but only where it's worthwhile.

Tim

Re:20 cores DOES matter

[TheRaven64]

SMT addresses two problems. The first is that, when a thread is completely stalled waiting for memory, you can try to run another thread. This doesn't happen that often with superscalar out-of-order cores, as you can also schedule other instructions from the same thread if there are no dependencies. The second is that a fetch granule from one thread may not be able to issue instructions to all of the execution units in a single cycle, giving you more to choose from.

The down side of SMT is that you increase contention on various resources. Cache is the biggest one, as sharing the cache between 4 or 8 threads increases contention a lot. Things like the cache and TLB depend on associativity and you can't arbitrarily scale associativity and still get single-cycle access, so you're going to hit diminishing returns quite quickly. Most of these things also increase power consumption a lot as you try to scale them.

In particular, on a modern system, register renaming takes a lot of the die area, and the more thread you have, the more rename registers you need to get the full throughput.

Re:20 cores DOES matter

[TheRaven64]

As someone who does -j32 on our existing systems and sees almost linear speedup, I disagree. If you've got a decent amount of RAM, you won't hit the storage at all - everything will be in the buffer cache. Memory bandwidth is not an issue either - compiling generally has good locality of reference and so the cache works well.

Re:20 cores DOES matter

[Anonymous Coward]

I'm certain I'm not the only one out here with access to dual-CPU, 12-cores (the real ones) per node, on huge HPC clusters. If we count HT, I've had access to "make -j 32" machines for the past 3 years. Doesn't sound too amazing, sorry.

Re:20 cores DOES matter

[Anonymous Coward]

I think we shouldn't make this a too broad statement. Perhaps make -j benefits some from HT, but it doesn't work for everything. In HPC, HT is routinely turned off. I remember testing for a specific software that is widely used in computational chemistry and we got 0% improvement out of using HPC. I didn't test it with a million different codes, but in this case it offered no benefit at all...

Re: 20 cores DOES matter

[Coren22]

Even those tiny little BRIX one can get these days can hold 32G of ram.

Do you have a link for what you are talking about? My desktop has 32 GB at home, and it has a pretty shitty MB, but I am not sure what you mean by a BRIX.

I found this on Google:
http://www.gigabyte.us/product...

But as far as I see, they only support 2 SoDIMM (DDR3L), which many of the specs pages list as 2x8GB max, so I don't know if this is what you are talking about.

Re: 20 cores DOES matter

[Coren22]

Is the CPU cooler able to keep up with the CPU doing that much work, or is the CPU forced to throttle back to prevent overheating.

Re:20 cores DOES matter

[Coren22]

I would love a video conversion appliance. I want to pull movies off the Tivo and autoconvert them to MP4, as well as any movies in my collection in random video formats do the same. That would be very nice to have something that I could throw on the ESX box to do all that work with some minimal configuration.

Re: 20 cores DOES matter

[m.dillon]

If we're talking about bulk builds, for any language, there is going to be a huge amount of locality of reference that matches well against caches. shared text RO, lots of shared files RO, stack use is localized (RW), process data is relatively localized (RW), and file writeouts are independent. Plus any decent scheduler will recognize the batch-like nature of the compile jobs and use relatively large switch ticks. For a bulk build the scheduler doesn't have to be very smart, it just needs to avoid moving processes around between cpus excessively so and be somewhat HW cache aware.

Data and stack will be different, but one nice thing about bulk builds is that there is a huge amount of sharing of the text (code) space. Here's an example of a bulk build relatively early in its cycle (so the C++ compiles aren't eating 1GB each like they do later in the cycle when the larger packages are being built):

http://apollo.backplane.com/DF...

Notice that nothing is blocked on storage accesses. The processes are either in a pure run state or are waiting for a child process to exit.

I've never come close to maxing out the memory BW on an Intel system, at least not with bulk builds. I have maxed out the memory BW on opteron systems but even there one still gets an incremental improvement with more cores.

The real bottleneck for something like the above is not the scheduler or the pegged cpus. The real bottleneck is the operating system which is having to deal with hundreds of fork/exec/run/exit sequences per second and often more than a million VM faults per second (across the whole system)... almost all on shared resources BTW, so it isn't an easy nut for the kernel to crack (think of what it means to the kernel to fork/exec/run/exit something like /bin/sh hundreds of times per second across many cpus all at the same time).

Another big issue for the kernel, for concurrent compiles, is the massive number of shared namecache resources which are getting hit all at once, particularly negative cache hits for files which don't exist (think about compiler include path searches).

These issues tend to trump basic memory BW issues. Memory bandwidth can become an issue, but it will mainly be with jobs which are more memory-centric (access memory more and do less processing / execute fewer instructions per memory access due to the nature of the job). Bulk compiles do not fit into that category.

-Matt

Re: 20 cores DOES matter

[doublebackslash]

Replying to undo incorrect moderation. Sorry!

Re: 20 cores DOES matter

[stoatwblr]

"Memory bandwidth can become an issue"

Bandwidth is almost never an issue. _Latency_ is another matter.

There are a lot of tricks and bits to optimise things regarding locality (mainly around row based and lookahead accessing. CPUs aren't the only devices trying to predict what will be read next) and controller optimisation, but the underlaying dynamic ram itself hasn't actually improved much over the last 20 years in terms of time between addressing a random cell and getting an answer back from it. The big improvements have been around the number of requests you can make while waiting for that answer instead of being in request-answer lockstep and there is only so far that can be taken.

_true_ 1GHz ram would have 1ns latency, not 12-30ns - and the reason that L1/L2/L3 is so important is because of that poor response time.

Re:20 cores DOES matter

[gman003]

It is a complicated subject. Some tasks do not benefit from HT - those whose memory access fits entirely within cache, and who make use of operations that cannot be spread among execution units in a core (or where the pattern of operations is superscalar with a single thread).

Simultaneous multithreading (the non-trademark name for HT) offers benefits in certain situations. First, where the memory access pattern is unpredictable and/or uncachable - it essentially lets one thread keep the core working while the other thread waits on the memory access (this breaks down when the task is purely memory-bound - it can actually hurt performance due to cache fighting). The second is when the two threads use different execution units - one is doing mainly compares and branches, while the other is crunching on floating-point. This puts more of the core to work at once. The third is when the two threads use the same execution units, but the core has multiple copies (a Haswell core has like three integer ALUs).

I'm not surprised it failed with computational chemistry. That's about as memory-bound a task as you can find. You probably would see 0% performance improvement from doubling your actual, physical cores, unless you upgraded the memory controller alongside it.

I cited the anecdotal averages I've seen. Some tasks saw 200% speedup at long ago as Nehalem. Others are actually hurt by HT even under Haswell. It's a complicated feature and the variance is substantial.

Re: 20 cores DOES matter

[MrKaos]

"Memory bandwidth can become an issue"

Bandwidth is almost never an issue. _Latency_ is another matter.

Thanks stoatwblr, that's exactly what I was talking about.

There are a lot of tricks and bits to optimise things regarding locality (mainly around row based and lookahead accessing. CPUs aren't the only devices trying to predict what will be read next) and controller optimisation, but the underlaying dynamic ram itself hasn't actually improved much over the last 20 years in terms of time between addressing a random cell and getting an answer back from it.

Which is why I'm always trying to tune the amount of application latency so the CPU cycles can be used for actual work. Obviously everyone's workloads are different but it makes sense to provide a bit of a helping hand to the machine (usually so I can go home)

The big improvements have been around the number of requests you can make while waiting for that answer instead of being in request-answer lockstep and there is only so far that can be taken.

That's an interesting development I hadn't heard off. That would have a major impact on reducing application latency, I think I'll have to get my head around how it will affect CPU scheduler behaviour though.

In a similar vein, I've heard of new methods to move CPU scheduler functions to the cpu and arrange the on-chip memory so that it can load tasks physically closer to the actual core processing them so perhaps the two developments are somehow related. I appreciate you completing the picture of what's coming.

In the context of what I'm doing, I'm trying to get more work out of the machine.

_true_ 1GHz ram would have 1ns latency, not 12-30ns - and the reason that L1/L2/L3 is so important is because of that poor response time.

Precisely, if my calculations are correct, it's about the amount of time an instruction on a 1Ghz CPU would take. When I see a lot of context switching and minor page faulting my application is really exposed to that and the cpus are doing a whole lot of nothing useful waiting for L3 to write(mainly) to ram or to fill.

I've seen memory thrashing on productions systems, it's never pretty being in a PIR.

Re:20 cores DOES matter

[Anonymous Coward]

OK, but your comments could be read as "HT is a wash". It isn't a wash. I've seen numerous substantive performance comparisons. You can reliably get 20% more throughput on diverse workloads. Sometimes more. HT is nearly always a net benefit.

If you are working on a narrow subject area, with a stereotypical workload and experts available to code and fine-tune solutions, well then frankly they are already well aware of the issues and can change course as needed.

For average users the message needs to be: "HT speeds up the computer. An HT core isn't as good as a real core but it's still beneficial and makes your programs go faster."

Now that wasn't so complicated, was it?

integrated face system

[Anonymous Coward]

The integrated face system uses the 10 cores from the intel processor to verify faces at high speed.

Software needs to catch up

[iamacat]

Mainstream programming languages are still sequential by default and the likes of OpenCL are too hard to learn for simple tasks. UI code is still single threaded in most systems, and that drags most computation into that thread as well through programmer laziness. It's time for languages which are parallel by default and where ability to parallelize a loop is verifiable at compile time. Yes I know FORTRAN is much closer to that then C/Java, but that's due to being primitive to a degree that will not fly in 2015.

Re:Software needs to catch up

[buchner.johannes]

Julia and Rust have some intriguing parallelisation mechanisms.
What I would like to write is code that has a dependency graph (or the compiler figures out the dependencies and parallelises by itself).

In the meantime I simple write code for 1 processor, and run that on many data sets in parallel (using make or doit).

Re:Software needs to catch up

[Anonymous Coward]

If you want a decent parallel story, you should check out Golang. It's kinda like a more modern take on Erlang.

Re:Software needs to catch up

[Anonymous Coward]

Golang has a pretty good parallel story. Kinda like a more modern erlang. https://en.wikipedia.org/wiki/Go_(programming_language)#Concurrency:_goroutines.2C_channels.2C_and_select

Re:Software needs to catch up

[Anonymous Coward]

If yet another language is a problem, the OpenMP and OpenACC are about to make it all little easier than pure OpenCL or CUDA. One day Java runtime may have some HSL capabilities as well.

Re:Software needs to catch up

[viperidaenz]

Java is pretty easy to write multi-threaded code.

Re:Software needs to catch up

[TeknoHog]

Julia and Rust have some intriguing parallelisation mechanisms. [...] I simple write code for 1 processor, and run that on many data sets in parallel

I haven't found Julia's parallelism very efficient, but maybe it's just my lack of coding skills. Then again my work is rather parallel by nature (independent pixels), so I simply run several processes using shell scripts.

For example, it would be nice if something like map() were always parallelized as it kind of assumes independent data points, but there are still other considerations like memory management. Julia's pmap() seems to have too much overhead to be of any help, especially when the separate processes scale so well.

Re:Software needs to catch up

[iamacat]

Multithreading requires every instance of concurrent execution to be micromanaged by the programmer, leading to a lot of code which is not parallelized in practice. Potential concurrency should be the default case for, say, all for loops and serialization an explicit paradigm that a programmer is aware of. Coupled with strong compile time checking that can detect safe and unsafe code.

Re:Software needs to catch up

[Dutch Gun]

It's not just the programming languages. Most *tasks* of any complexity tend to be highly sequential in nature. There are some rare exceptions, but the notion that a language can just automatically parallelize loops and get some massive speedup is not very feasible, I hate to say. It tends to work best in highly contrived or specialized situations. You have to be running some serious computation in a LOT of loops for that to pay off in any way, or the overhead is simply a non-starter. Moreover, those computations can't have any global side-effects or interaction with non-thread-safe data.

Your example, a UI library, is the antithesis of this, which is why they tend to be single-threaded. A UI system would need so many locks for all the interacting data that it would be largely pointless to try to make it multi-threaded. Every single property on every single widget would need to be atomic, and every method would need to be lockable or re-entrant. That's a hell of a design constraint, and the net result might be to make the performance significantly worse, not better.

Re:Software needs to catch up

[angel'o'sphere]

Basically every Java program I have ever seen is multithreaded. (that only excludes hello world programs etc.)
No idea why you explicitely mentioned Java and C# ... the first one is a particular bad example.

Re:Software needs to catch up

[viperidaenz]

Here's an example from Oracle:
double average = roster .parallelStream() .filter(p -> p.getGender() == Person.Sex.MALE) .mapToInt(Person::getAge) .average() .getAsDouble();
Lamba's and extensions to the Collections framework have made parallel loops simple.

You can't have the compiler parallelize loops if the methods you call can be overridden. Forcing every method called to be final, just so you can optimize some loop is a little daft. It's also pointless (read: slower) parallelizing a loop that only runs a few iterations. It's something the programmer needs to think of and isn't always something the compiler can tell at compile time.

Re:Software needs to catch up

[Anonymous Coward]

Very much this!

So many languages need to catch up, and not just catch up in some cases, make their concurrency systems less SHIT.
Some of them are horribly obtuse to work with and require an insane amount of framework to support it.

Equally more people need to learn how to write code that isn't as branch-heavy either, because that can lead to loads of problems with optimization.
Giving hints and depending on automatic algorithms to do the hard work can only go so far.
On top of that, also writing code that is less sequential-heavy. There are many techniques you can use to minimize loads of seemingly sequential code, or even split it up so it can be run on multiple threads.
Of course, there are ones that simply can't be, specifically those that depend on previous code or data to go forward. Recursion can be very tricky to deal with as well. (it is generally tricky anyway!)
Trying to eliminate self-referential code is quite a tricky issue.

So many people look at concurrency and think it is a huge nightmare, but really it isn't all that hard to wrap your head around.
The issue is that languages themselves make it a bigger issue than it need be.
Definitely needs to be addressed.

Re:Software needs to catch up

[Anonymous Coward]

So use Java + Akka or Scala + Akka.

This is designed to give very good multi-threaded performance using an Actor based model (e.g. see Spark)

Re:Software needs to catch up

[iamacat]

Nothing has to be made final, subclasses just need to obey the contract declared by superclass. This can be accomplished, in the worst case, by making everything synchronized.

Make default for loop potentially parallel and have compiler complain if it can not prove that by either code inspection or, as a last resort, explicit annotation on the loop or methods that it calls. Then introduce an sfor keyword for when you really have to make things sequential.

Re:Software needs to catch up

[iamacat]

Really? Every browser window or tab should hang if Javascript in one of them is slow? Loading and decoding an image for one of the icons on screen should prevent the UI from processing touch events? Many of those problems have been solved by important applications ad-hoc, but sane behaviour by default would be great.

Re:Software needs to catch up

[Dutch Gun]

A web browser is somewhat of a unique case, as each tab is more or less equivalent to a separate application - or at least, it should be. Chrome certainly proved it can effectively be done that way, I think. I agree - a single page should not be able to slow down the entire browser - that's terrible design.

When I was talking about UI, I was talking more like .NET's WPF or Qt, perhaps, neither of which are thread-safe because of performance concerns. It's critical for the programmer to do the work of handling any potentially long-running tasks to avoid blocking the UI thread.

All I'm saying is that there isn't a magic bullet here. Multi-threaded programming simply requires careful design and implementation.

Re:Software needs to catch up

[Megol]

IMHO there should be 3 basic types of loops: FOR, PAR, SEQ. FOR loops can be parallelized if possible by the compiler, PAR loops have parallel semantics and SEQ loops have sequential semantics.

Then most loops can use the FOR variant but when advantageous the programmer can use PAR or SEQ depending on the situation and/or to help the compiler and improve readability.

Re:Software needs to catch up

[viperidaenz]

Slapping synchronized on a method doesn't solve all your multi-threaded problems.

The simplest example is probably a Hashtable, all methods are synchronized.
If you want to replace a value in the map, calling get, then set is effectively a read-modify-write, that operation needs to be protected by enclosing it all in a synchronized block.

You'll also risk dead locks.
If Object A's synchronized method calls Object B's synchronized method and vise versa, having two threads calling both those methods risks a dead lock.

If your parallel loop is:
ObjectA.method();
ObjectB.method();

You're screwed. If doesn't need to be that simple, and if the methods aren't final, someone else can come along and easily introduce a race condition.

The only way to protect that code is wrap both calls in two synchronized blocks, acquiring first ObjectA's lock and then ObjectB's. That then makes your parallel loop serial, due to synchronization. Congratulations, you've used a bunch of memory and CPU creating new threads and a whole lot of lock contention and made your loop slower, while wasting resources on multiple CPU's

If you don't always acquire locks in the same order in all threads, you risk dead lock.

Synchronization is also very slow when there is contention.

Re:Software needs to catch up

[Bengie]

My first non-homework program ever was a threaded in C# 2.0 and was for my first job. Threading is pretty easy. With .Net 4 and even more so with 4.5, they took a lot of the boring parts and let me simply connect my parts together is pre-made legos.

I can understand how threading can be hard for systems that are very latency sensitive like 3D games, but anything that just needs scaling and throughput, threading is brain dead easy.

Wrong specs on Skylake

[SeeManRun]

I have been seeing this a lot lately for some reason. The i7 6700K runs at 4.0 ghz base clock and turbo's up to 4.2. So it will be quite a performance beatdown by Skylake if clockspeed instead of threads is important.

Re: Wrong specs on Skylake

[Nemyst]

Yeah, which is pointless because comparing clock speeds between different manufacturers has never meant anything. Your A10 still tanks against most Intel processors in any but the most parallel of use cases. Oh, and you do need a separate video card if you actually care about having a GPU. APUs are still laughably underpowered.

Re: Wrong specs on Skylake

[alvinrod]

The current AMD architecture has crummy IPC (instructions per clock) compared to Intel so you'd likely have to get it running close to 5.5 GHz for it to have competitive performance and the FP units are shared between each module's cores, which means for non-integer workloads you really have 6 cores.

However, for what AMD is selling it for, it's a better deal than the comparatively priced Intel chip, especially if you're doing anything that can make use of all of those cores.

Re: Wrong specs on Skylake

[Anonymous Coward]

I really wish I could upload the slow clap gif here... a masterful bit of trolling sir.

Re: Wrong specs on Skylake

[Anonymous Coward]

Wrong spec. I meant 7850K. Base is @3.7 but a-tuning can push it to 4.5 with a reboot. The I7 base is @3.0 I believe. 3-4 is still respectable. All I need now sd the grand to buy it. As for parralellization, this is how the supercomputer on Maui works. So doing an ant-man on the architecture makes perfect sense. Parallelization requires specific instruction sets. Not a gamer but if nothing else, gaming does tend to push computing limits on every front.

Re: Wrong specs on Skylake

[Anonymous Coward]

Sure but I'm more of a FirePro type of guy. I want the pc to just get results. A visual barrage is not what I would consider 'results'. Laughable is a gamer's perspective.

Re: Wrong specs on Skylake

[Anonymous Coward]

5.5? My 7850k replaced an Intel P4 @3.1. At 5Ghz I would need liquid nitrogen cooling. Not worth it imo. I'll take a hign end xeon over any skylake or other I7 flagship any day all day. Thanks for pushing my envelope and opening my eyes.

Re: Wrong specs on Skylake

[Blaskowicz]

Underpowered, but for most people that would be the most powerful GPU they ever had on a PC.
You need more for games but we're long past diminishing returns and with passing times you get to use uglier versions of Windows, also games are all tied to "app stores" like Steam and others so you can't sell or lend them and the store spies on you. Boring.

I can see myself upgrading to the next generation of APUs (better CPU, ddr4 support, supported by the new free driver + non-free blob architecture for linux) and after that there would be no need to upgrade ever.

Re: Wrong specs on Skylake

[Anonymous Coward]

> I don't gas
Mean you don't fart?

Re: Wrong specs on Skylake

[Anonymous Coward]

The shared FP isn't as much of a penalty on Steamroller which is used in AMD's current crop of desktop APUs (Excavator is in Carrizo, but for now, that's mobile/embedded only). In multi-threaded FP-heavy workloads, my A10-7700k loses anywhere from 30-40% of its processing power moving from 2m/4t to 2m/2t.

Re: Wrong specs on Skylake

[sexconker]

I wonder if AMD will ship an APU package with HBM / HBM2 slapped right on it. A true "system on a chip" - CPU, integrated GPU, integrated memory controller, integrated memory, PCIe, etc.

Re: Wrong specs on Skylake

[FlyHelicopters]

5.5? My 7850k replaced an Intel P4 @3.1. At 5Ghz I would need liquid nitrogen cooling. Not worth it imo. I'll take a hign end xeon over any skylake or other I7 flagship any day all day. Thanks for pushing my envelope and opening my eyes.

You missed the point...

A 2.4GHz Core2Duo would crush that P4 outright, even in single thread work.

A P4 955 EE running at 3.64GHz (dual core) is outright crushed by a 3.3Ghz Core2Duo, sometimes by a factor of 4.

Clock speed is just one measure of performance. A Skylake 6700K is, even at stock speeds, generally faster than anything AMD makes, even overclocked.

Re: Wrong specs on Skylake

[Anonymous Coward]

Physical stores track your purchases as well, you know. I actually like GOG's DRM free games. You can copy those wherever without a problem.

Re: Wrong specs on Skylake

[One With Whisp]

Really, they track my cash-only purchases do they?

400 Thread Count

[Anonymous Coward]

C'mon Intel, everyone knows that 400 thread count is the minimum needed for a good night's sleep.

Re:400 Thread Count

[U2xhc2hkb3QgU3Vja3M]

Nope, 400 still isn't enough. A lot of us are still waiting for a CPU with over 9000 threads.

Re:400 Thread Count

[KGIII]

Pfft... 1500 count Egyptian, or I'm going home!

(No, not really. I don't actually know what the thread count is. One, I'm in a hotel STILL and, two, I don't actually buy my own bedding at home.)

Re:400 Thread Count

[Anonymous Coward]

that isn't a cpu -- it's a supercomputer. https://en.wikipedia.org/wiki/Blue_Gene up to 65,536 cpus. which is one cpu more than the total number of ports allowed on a unix machine. interesting.

Re:400 Thread Count

[U2xhc2hkb3QgU3Vja3M]

That wasn't a supercomputer reference, it was a DBZ reference.

AMD's response?

[Khyber]

Assuming Intel doesn't go Xeon-scale in pricing for this CPU (who am I kidding, of course they will) I wonder how AMD plans to respond to this.

For now, they've got the consoles holding them afloat. And while I am an AMD fan, I see they are rapidly losing out on the desktop space when it comes to performance (despite both companies having rather meager performance gains for the past several years.)

They'd better figure out what the fuck they're doing, and come up with some competing responses, quickly. Hell, I've got ideas for them, all involving that HBM tech.

1. Use a modified version of that HBM tech to stack their CPU cores and load it up with tons of cache memory (for their non-APU line.) And don't forget to drop a process node, for fuck's sake.
2. Use modified HBM tech to create stacked CPU/GPU/RAM/CACHE on the same die (for their APU line.)
3. Use modified HBM to create stacked single-die CrossFire GPUs that don't consume gobs of power (GPU line.)
4. Use modified HBM tech to create a true monolithic SOC package that integrates EVERYTHING, thus eliminating the need for motherboards - at that point and time, it just becomes a breakout board with a socket. They could probably do away with the interposer as well if They were clever enough in the design.

Re:AMD's response?

[Nemyst]

HBM only works for stacking memory (hence why it's called High Bandwidth Memory). You can't stack CPU cores because they output waaaaaay too much heat. You can dissipate heat from memory passively, so stacking them and slapping an active cooler can work. Good luck stacking CPU cores in the same way.

Re:AMD's response?

[Khyber]

"You can't stack CPU cores because they output waaaaaay too much heat."

Microfluidic cooling to an IHS. Easy-peasy.

Re:AMD's response?

[Kjella]

Assuming Intel doesn't go Xeon-scale in pricing for this CPU (who am I kidding, of course they will) I wonder how AMD plans to respond to this.

Fighting the battles they can win, or are at least less likely to lose. This is a halo product of a server line of chips and getting Opterons back in the data center takes more time for validation and convincing conservative enterprises than AMD has. Zen will launch to compete with Intel's mainstream dual/quad-core chips, even if it pulls off a miracle I'm guessing it'd take at least a year or two until AMD is back to a full top-to-bottom stack.

Re:AMD's response?

[gman003]

AMD has been developing a new microarchitecture, Zen, which will replace the horribly-designed Bulldozer. It's rumored to be made on a 14nm node, and they re-hired the guy who designed the K10 architecture (aka the last good CPUs AMD made), so I expect it to be reasonably competitive with Intel. I really hope it is, at least.

Your terminology is completely out of whack ("stacked single-die CrossFire GPU" is a phrase with more contradictions than whitespace characters), but I'll analyze what you were trying to say instead of what you actually said:
#1: Current chip-stacking tech doesn't allow for all that much bandwidth between chips, especially when going above two layers. CPU cores need a pretty hefty amount of bandwidth to their cache, so that's already problematic. Stacking dies also limits thermal performance - if you stack two dies, you have 2x the heat in 1x the heat-conducting surface area. For low-power stuff, that's fine, but CPU cores get pretty hot. Many high-performance dies are already performance-constrained by how much heat they can conduct to their cooler.
#2. This is a good idea. Or rather, the good idea is "APU on an interposer using HBM for main memory". You'd need bigger CPU caches - HBM is ridiculously high-latency even by VRAM standards, it will really hurt CPU performance otherwise. And it will limit upgradability - no way to just pop another DIMM of DDR3 in there. But the GPU gains should be worth it.
#3. Again, thermals will absolutely prevent you from stacking GPU dies. HBM and stacking doesn't do ANYTHING for the power efficiency of the chips you're stacking, so that's two 100W+ dies on top of each other. Not gonna happen. You could stack them side-by-side on an interposer, but at that point why not just fabricate them as one die?
#4. The cost of an interposer is significantly greater than that of a printed circuit board, and a lot of stuff won't benefit from the greater bandwidth to the CPU - stuff like a USB controller or audio chipset. Stacking the dies is also more expensive than just using a PCB - it's done in phones where space is REALLY constrained, but even the smallest desktops aren't that tight for space yet. So all that's left is putting everything onto one die - which runs into yield problems, because with bigger individual dies, a single defect will wipe out a lot more silicon. AMD actually *is* already doing this with their lowest-end laptop/desktop parts - look at Socket AM1, there's not much on the motherboard besides external connectors and power-delivery circuits. But they're also pretty low-end in performance.

Re:AMD's response?

[Anonymous Coward]

And how many microfluidic systems are available on the consumer market? Oh right, None of importance. IBM is doing it's damnedest with Microfluidics, and even Big Blue has problems making Microfluidics in bulk. Not to mention that attempting it would massively cut initial yields, because you're combining multiple bleeding edge pieces of tech, and hoping that you can contract that out to someone else to make it. Is it workable, yes. But could you make a million of them tomorrow, or even next year? Nope. AMD had trouble with traditional liquid cooling, even when using 3rd party supplied cooling systems. What exactly makes you think any of them are qualified to design Microfluidics, or that they could create good masks for it? Not to mention that a Process shrink is itself problematic. And at the lowests process sizes, the transistors themselves must become 3D (Finfet), making it even harder to stack them, while admittedly improving cooling in theory, as more surface area is available.

But AMD and global foundries have not had too many big advances recently of their own. You're asking for no less than 3 major innovations in a single chip, and mass manufacturing of same.

Re:AMD's response?

[gman003]

Being able to describe something in five words does not make it easy.

Re:AMD's response?

[Khyber]

It's that easy as we're doing it to make large linear high-power LEDs run very cool.

Protip for AMD: Start with a thicker wafer, do the underside with your required cooling channels, do the topside with your typical litho. You CAN wick heat from the underside.

Re:AMD's response?

[Khyber]

We have microfluidics for stacking dies and removing heat. We do it on p-n junctions on some of the latest LEDs (which are fucking MASSIVE at nearly 7mm x 7mm on just the die alone, not including any mount, circuitry, etc.) to keep them very cool.

I don't speak of ideas unless I already know we've got the technology to handle it.

Re:AMD's response?

[gman003]

49mm^2 is "massive"? A high-end processor is 500-600mm^2. And even if microfluidics works to remove heat (how do you have a layer with both enough fluid channels to cool, and enough TSVs for communication?), that will increase your cost substantially. I would expect $1K+ for a quad-core CPU under this kind of design.

Re:AMD's response?

[dbIII]

Low end desktops and high end cluster computing are keeping AMD going. It's not as if you can put four of these 3GHz 20 thread beasts on a board, and the Xeons that can do that are both slower and cost a fortune compared with four-way AMD CPUs.
Not very long ago I got a quote for an 80 thread Intel machine (4 Xeons) which turned out to be slightly less than ten times the price for a 64 core AMD machine with the same clock speed, memory capacity, disks etc. The Xeon machine would perform better than a single AMD one, but not better than nine of them! That's an example of why AMD are still selling a lot of gear at high performance computing end of town.

Re:AMD's response?

[Anonymous Coward]

I see they are rapidly losing out on the desktop space

amd lost the desktop wars long ago, with the first generation of intel's core architecture. amd hasn't been even close, since.

a few pc makers use a small number of amd chips in low cost systems.. but intel's confusingly-named pentium and celeron based atom chips have all but taken that segment over ..

even dell still uses amd chips off and on, but only to leverage lower prices from intel. once they get it, amd gets dumped to the curb.

amd is fucked, royally. unless they can come up with something SOON that is at least as significant as the athlon thunderbird was in the pre-core era, and gets intel playing catch-up for a change, they are stick-a-fork-in-it done.

consoles? nope dont see any manufacturer using amd parts in the next generation consoles... mobile? other arm producers and intel own that market.. not even graphics will save amd, nvidia has stomped all over amd for several generations of graphics chips now.... the only thing that keeps amd afloat the way it is, is the government's mandate for two suppliers for x86-type chips... and even then, nearly all of government purchases are intel anyway.

Re:What is a

[Anonymous Coward]

Perhaps the grammar department can contact the understanding department, learn from them that they already understand and don't need them for that. And that much of grammar department's work revolves around trying hard to see problems where they are not, just to find something to do for fear of being unemployed or useless.
But no problem, the understanding department is always hiring, no one will be out of work. Just a matter of choosing which job seems the most fulfilling.

Into the Wayback Machine Sherman!

[Chas]

Imagine a Beowulf Cluster of these!

Re:Into the Wayback Machine Sherman!

[BarbaraHudson]

Imagine a Beowulf Cluster of these!

No need ... give it a while and people will be saying "64 Cores ought to be enough for anyone." Then again, GPUs passed that count long ago.

Re:Into the Wayback Machine Sherman!

[Anonymous Coward]

Imagine a Beowulf Cluster of these!

Already have, in fact to the 2nd order.... as in imagining a beowulf cluster of beowulf clusters of these, in a fully connected mesh network...

*licks lips

Re:Into the Wayback Machine Sherman!

[Anonymous Coward]

No they didn't. In fact, AMD's GCN has 64 SIMD lanes per core. The highest-end Radeon you can buy, the Radeon Fury X, has 64 of those.

Re:Into the Wayback Machine Sherman!

[BarbaraHudson]

The nVidia Tesla CUDA GPU cards have thousands if core

Q: What is NVIDIA Tesla?

With the world’s first teraflop many-core processor, NVIDIA® Tesla computing solutions enable the necessary transition to energy efficient parallel computing power. With thousands of CUDA cores per processor , Tesla scales to solve the world’s most important computing challenges—quickly and accurately.

One example Tesla K40: 2880 CUDA cores. That's a LOT of cores.

Re: Sounds like fun

[Anonymous Coward]

Thank you for sharing. I was lost without your insightful comment!

Next step: Send consultants to MySQL.

[SuricouRaven]

"Hi. We're from Intel, and we'd like to take a look at your multithreading, such as it is."

Re:Next step: Send consultants to MySQL.

[TFlan91]

Waste of time...

Send them to pg, make it even better

Re:Next step: Send consultants to MySQL.

[Anonymous Coward]

"Sorry, folks from Intel. We can't accept your help even for free because we would then be more competitive with the products of our parent company."

Memory isn't neccesarily the bottleneck.

[fyngyrz]

It's not that straight-forward. Depends on how much time the threads spend in the cache, and how much time they spend waiting on the FPU.

Re:What is a

[Anonymous Coward]

20-thread is more normally seen as "20 TPI" or thread per inch. It is a standard of thread pitch for bolts.https://en.wikipedia.org/wiki/Screw_thread#Lead.2C_pitch.2C_and_starts

This is all well and good...

[Type44Q]

This is all well and good but I have to wonder: is this thing still optimized for single-threaded performance??

Nice, but...

[Brad1138]

How much does it really matter anymore? For 99% of the population, any top end computer built in the last 5+ years is so damn fast, it will be fine for the next 10 years. Unless we see the 100x (or whatever) increase with quantum computing, these small incremental improvements are fairly pointless.

Re:Nice, but...

[jeffb (2.718)]

If you don't have at least 10 cores, how can you expect to run the ads, tracking software and gratuitous animations required to fully participate in the online society of the late 20-teens?

Re:Nice, but...

[balbus000]

Wow, what kind of utopian future are you predicting where the companies who write tracking software properly support multithreading? ;)

Really

[wwalker]

Is it really 10 cores / 20 threads for real? Or will it reduce the core frequency even further by like 50% if you try to use all of them at once for more than a second, to say within TDP envelope and not to melt?

Re:Really

[Anonymous Coward]

True. Uses the lga1150 v3 socket and the x99 arch. Gamers rejoice. Intel profits. Move along.

Re:Really

[Anonymous Coward]

Wrong socket. LGA2011 v3, not 1150.

How fabulously average

[Anonymous Coward]

when memory bandwidth is still such a tight bottleneck. Not to mention the speed of storage, even a fast SSD will buckle when you have 20 threads hammering it.

Re:Seriously?

[Opportunist]

Don't worry. Windows will bloat to fill the additional cores.

Intel often communicates poorly.

[Futurepower(R)]

Why is Intel introducing a new Broadwell processor? Why not Skylake?

Broadwell was a "Tick". Skylake is the improvement called "Tock".

Re: Intel often communicates poorly.

[Fwipp]

"Intel has made a habit of launching enthusiast versions of previous generations processors after it releases it a new architecture."

Re:Intel often communicates poorly.

[Nemyst]

Yields. When intel releases a new processor line, yields are still pretty low, especially towards the high end. That's why you have binning and so many different processors - so they can recycle a top-end processor as a mid or high-end processor should parts of it end up subpar (though this is more popular in GPUs these days).

As the line ages, yields improve and they generally iterate over the design in smaller ways to obtain even better efficiency or iron out issues. It's at that point that it becomes very appealing to release an improved flagship series (the -E branding) using the better yields. They're branded the same as the current line (so Broadwell-E is 6000 like Skylake processors) because they're still considered superior.

Re:Seriously?

[Anonymous Coward]

Don't worry. Windows will bloat to fill the additional cores.

Windows 10 is faster than 7 on the same hardware. "Bloat." Stop spreading misinformation, weirdo.

Minecraft

[Anonymous Coward]

For 99% of the population, any top end computer built in the last 5+ years is so damn fast, it will be fine for the next 10 years.

Not if you need to run Minecraft on that computer.

How many hardware backdoors?

[Anonymous Coward]

Does it come with 20 backdoors or just the standard one?
(Vpro, VT, whatever you want to call it)

Awesome

[Early Six Digit UID]

Not only will this thing be great for those of us who love to run PovRay and virtual machines, but hopefully we're well on our way to software designers actually getting comfortable with parallelizing workloads.

It seems like most major software packages finally support 64-bit processing (shaking my head at ArcMap), and even video games are being dragged along by the new wave of consoles. Maybe they'll be more agile in the future.

Do modern, development-focused CS degree programs talk about multiprocessing?

169784

Re:Awesome

[dbIII]

Do modern, development-focused CS degree programs talk about multiprocessing?

They did in 1990. Oh wait, that subject was run by an electrical engineering department so it may take a while for others to catch up.

Re:Awesome

[gl4ss]

you would think that they do since it's essential to making anything in java or making anything in android or making anything in just about everything except javascript nowadays.

anyhow.. our multi thread parallel programming course was in ADA.. it was in ADA so that we could use the language built in mechanisms and skip learning anything. I guess there was some rationale but it was probably the same rationale that was used for learning microcontroller programming with assembly for some hitachi pos.

"a whopping 25MB of L3 cache"(!)

[Anonymous Coward]

"a whopping 25MB of L3 cache" souds like "a whopping 20Mb capacity" for a brand new hard disk in the early 1990's...

Re:"a whopping 25MB of L3 cache"(!)

[MrKaos]

"a whopping 25MB of L3 cache" souds like "a whopping 20Mb capacity" for a brand new hard disk in the early 1990's...

*Whooosh*

What does that say about Intel?

[Futurepower(R)]

Yes, but why?

Re:What does that say about Intel?

[Kjella]

Yes, but why?

The enthusiast desktop CPUs are a spin-off from the Xeon server CPUs. They spend much longer time validating those than mainstream laptop/desktop CPUs, so on any new architecture/process they're likely to arrive last. The upside and/or downside is that it might still introduce new features or standards like say DDR4 ahead of the consumer CPUs, but sometimes at a high cost.

VMWare whitebox heaven

[barc0001]

This will be nice to pop into a whitebox VMWare ESXi machine. Definitely cheaper than a 2 x 6 core build.

Re:VMWare whitebox heaven

[swb]

If only they would pair it with a desktop board that could take 256 GB RAM.

I find that I eat all my disk i/o and RAM way before my cpu.

Re:VMWare whitebox heaven

[barc0001]

Yeah that's part of the problem, but for some of our dev workloads we only use 2GB of RAM per VM but hammer the processor so this is a good niche fit. And Gigabyte's got some workstation boards that go to 64GB but also cost more so it's a trade off - and it's not a sure thing they'll support these chips. Obviously it's not for everyone.

Re:VMWare whitebox heaven

[Anonymous Coward]

Sorry if my ignorance is showing, but are you running Socket 2011v3?

If so, MSI and ASRock (yes, I know those are consumer and not pro names) will support 128GB.

Re:VMWare whitebox heaven

[Blaskowicz]

There are desktop boards that support a theoretical 512GB or 768GB memory, if you go with registered ddr4.
Look for the "pro" chipset, C612.
Needs a Xeon E5-1xxx - the leading 1 says it works only in single CPU mode - which is about the same as an i7 anyway.

6700K

[Anonymous Coward]

6700K has a 4.0 base clock and a 4.2 boost clock, for clarification.

Re:Seriously?

[Anonymous Coward]

All spyware from 7 to 10. Speedy malware is not a plus.

Interesting.

[Futurepower(R)]

Interesting. I think Intel should do that kind of explaining.

Typical Intel confusion

[Futurepower(R)]

Thanks for the explanation.

"(so Broadwell-E is 6000 like Skylake processors)"

That, to me, seems like Intel being typically Intel. That creates confusion, instead of communicating clearly.

A long time ago, I wanted to order some Intel motherboards. I needed the part numbers. It required 2 hours to get the numbers.

Several years ago, I mentioned an error in the Intel web site to an Intel customer service employee. He said, "Oh, we are re-doing our web site." A year later, I happened to get the same person on the phone. I mentioned the same error. He said the same thing, "Oh, we are re-doing our web site."

LEARN-WHEN-TO-USE-HYPHENS

[Anonymous Coward]

epic tardsauce all the time with hyphen abuse, comma abuse, and the like. please take a kindergarten english class sometime.

The bitchslapping of Khyber... apk

[Anonymous Coward]

"NOD32 detects a trojan in APK's HOSTS bullshit." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

VirusTotal & NOD32 SHOW CLEAN IN ITS EXES

https://www.virustotal.com/en/...

&

https://www.virustotal.com/en/...

There's only 2 exe's & 5 text files in it - The exe's are proven clean above in 2 links from VirusTotal & installer's a SFX rar (keeps it 2mb smaller) - that's NO virus per VIRSCAN http://f.virscan.org/APKHostsF...

(Unless YOU know way that .txt files are "viruses")

---

"he's tying to get your fucking information." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

My program doesn't transmit outward ONLY intake of data from 10 reputable security community sources!

---

"APK is apparently too fucking stupid to do this at the ROUTER level where it's most effective" - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

You believe in "eggshell security" which fails-> http://www.theregister.co.uk/2...

COMPETENT NETWORK ADMINS DO MORE THAN PERIMETER SECURITY @ ROUTER LEVEL - they get bushwhacked ALL THE TIME in DNS hijacks!

(Right down to endpoints level in PC workstations also using tools you already have in hosts + firewalls (vs. "piling on 'MOAR'" that's inefficient & not as effective in slower usermode browser addons)).

---

"Windows 10 has hardcoded IPs and bypasses HOSTs." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

Windows ONLY bypasses hosts files for Windows update (Win8 & below) & for tracking "telemetry" in Windows 10 (this is going to KILL Windows 10 -> http://yro.slashdot.org/commen... ) - test it yourself, that removes it.

---

"Browsers can bypass HOSTs as well." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

WTF? They'd be bypassing the IP stack if hostname is used ala http://slashdot.org/ (not http://216.34.181.45/ hosts are part of it - not possible!

APK

P.S.=> "EAT YOUR WORDS"... apk

The bitchslapping of Khyber... apk

[Anonymous Coward]

"NOD32 detects a trojan in APK's HOSTS bullshit." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

VirusTotal & NOD32 SHOW CLEAN IN ITS EXES

https://www.virustotal.com/en/...

&

https://www.virustotal.com/en/...

There's only 2 exe's & 5 text files in it - The exe's are proven clean above in 2 links from VirusTotal & installer's a SFX rar (keeps it 2mb smaller) - that's NO virus per VIRSCAN http://f.virscan.org/APKHostsF...

(Unless YOU know way that .txt files are "viruses")

---

"he's tying to get your fucking information." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

My program doesn't transmit outward ONLY intake of data from 10 reputable security community sources!

---

"APK is apparently too fucking stupid to do this at the ROUTER level where it's most effective" - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

You believe in "eggshell security" which fails-> http://www.theregister.co.uk/2...

COMPETENT NETWORK ADMINS DO MORE THAN PERIMETER SECURITY @ ROUTER LEVEL - they get bushwhacked ALL THE TIME in DNS hijacks!

(Right down to endpoints level in PC workstations also using tools you already have in hosts + firewalls (vs. "piling on 'MOAR'" that's inefficient & not as effective in slower usermode browser addons)).

---

"Windows 10 has hardcoded IPs and bypasses HOSTs." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

Windows ONLY bypasses hosts files for Windows update (Win8 & below) & for tracking "telemetry" in Windows 10 (this is going to KILL Windows 10 -> http://yro.slashdot.org/commen... ) - test it yourself, that removes it.

---

"Browsers can bypass HOSTs as well." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

WTF? They'd be bypassing the IP stack if hostname is used ala http://slashdot.org/ (not http://216.34.181.45/ hosts are part of it - not possible!

APK

P.S.=> "EAT YOUR WORDS"... apk

The bitchslapping of Khyber... apk

[Anonymous Coward]

"NOD32 detects a trojan in APK's HOSTS bullshit." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

VirusTotal & NOD32 SHOW CLEAN IN ITS EXES

https://www.virustotal.com/en/...

&

https://www.virustotal.com/en/...

There's only 2 exe's & 5 text files in it - The exe's are proven clean above in 2 links from VirusTotal & installer's a SFX rar (keeps it 2mb smaller) - that's NO virus per VIRSCAN http://f.virscan.org/APKHostsF...

(Unless YOU know way that .txt files are "viruses")

---

"he's tying to get your fucking information." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

My program doesn't transmit outward ONLY intake of data from 10 reputable security community sources!

---

"APK is apparently too fucking stupid to do this at the ROUTER level where it's most effective" - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

You believe in "eggshell security" which fails-> http://www.theregister.co.uk/2...

COMPETENT NETWORK ADMINS DO MORE THAN PERIMETER SECURITY @ ROUTER LEVEL - they get bushwhacked ALL THE TIME in DNS hijacks!

(Right down to endpoints level in PC workstations also using tools you already have in hosts + firewalls (vs. "piling on 'MOAR'" that's inefficient & not as effective in slower usermode browser addons)).

---

"Windows 10 has hardcoded IPs and bypasses HOSTs." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

Windows ONLY bypasses hosts files for Windows update (Win8 & below) & for tracking "telemetry" in Windows 10 (this is going to KILL Windows 10 -> http://yro.slashdot.org/commen... ) - test it yourself, that removes it.

---

"Browsers can bypass HOSTs as well." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

WTF? They'd be bypassing the IP stack if hostname is used ala http://slashdot.org/ (not http://216.34.181.45/ hosts are part of it - not possible!

APK

P.S.=> "EAT YOUR WORDS"... apk

And Intel wonders why nobody buys new pc's

[Anonymous Coward]

And older generation, slower clockspeed, probably more power hungry, and that all for an insane larger price? I still have a 2600K, don't see much speed difference, and don't come with the better intel graphics, any reasonable nvidia card is much faster and more stable. And it has been much longer than 3 years since I bough a new pc... It's probably going to take a few years more...

Something fishy about this

[fyngyrz]

I generally buy them from liveaquaria.com. For my aquariums, not for my dinner. :)

Re:Something fishy about this

[PopeRatzo]

I generally buy them from liveaquaria.com. For my aquariums, not for my dinner. :)

And they show up alive? I'm always a little amazed when people get live animals shipped to them. I have a friend who's an urban beekeeper who gets live bees fed-exed to them. What a country.

Re:Something fishy about this

[Muad'Dave]

You can get day-old chicks thru the post office. Your friend's bees are listed at the top of that same page.

Re:Something fishy about this

[fyngyrz]

Yes, they show up alive and doing quite well. They pack them in plastic bags, some of which have black light-shields for the species that are prone to shock from sudden changes in light intensity, all inside said thermal envelope (a Styrofoam cooler, essentially.) They put a heating or cooling chemical packet in there with them, depending on the season, and then ship them overnight by FedEx or UPS. I unpack them immediately upon receipt, gradually acclimate them to the water and temperature they'll be living in, then pop them in the tanks. They have always survived, except when something else in there decides they'd make a good meal, or the corals get into a chemical war, which can be pretty severe and requires re-homing one of the species so engaged.

Where I live (rural Montana), this is about the only practical way to build and maintain a saltwater aquarium. I don't mind. The selection online for live rock, plants, corals, fish and invertebrates -- and gear -- is better than one could ever hope for in a storefront operation. It's a little dear, cost-wise, but I'm old and have a few bucks I can apply to my interests. My oldest tank has been running for about a decade; my most recent, an unusual configuration with a custom sump system I designed located well above the tank, about six months.

Re:Something fishy about this

[PopeRatzo]

Very cool.

Speed fallacies.

[stoatwblr]

"it could potentially trail behind the Core i7-6700K, a quad-core Skylake processor clocked at 3.4GHz (base) to 4GHz (Turbo)."

Not by much.

If you want to see the true speed of any CPU, look at the memory speed. Internal multipliers make some steps run faster but the overall effect isn't high enough to justify the cost deltas on the higher-clockrate CPUs. In general the sweetspot is 2-4 steps below the top step.

If you have a proper multitasking operating system it will take as much advantage of extra processors even if individual programs don't. For that reason I always bias toward more CPUs than higher clockrate when specifying servers for the datacentre, whilst aiming for maximum possible memory speed (That used to mean trying to keep to one bank on DDR3, but it's a bit easier with LRDIMMS and DDR4)

We don't run much virtualisation, as the kind of loads being run invariably max out the raw systems so there's no point, however in a virtualised environment "More CPUs" always beats "faster ones" as long as hyperthreading is disabled (if a virtualised box gets assigned a HT "CPU" then it will crawl).

Higher CPU clocking is mainly good for willy-waving, other than in quite specific tasks where you can keep everything important in L1/L2.

Gillette

[DarthVain]

I hear it is used to power the new Gillette razor with 6 blades...

Re:The bitchslapping of APK

[Anonymous Coward]

I found a way to totally make APK's HOSTs file useless.

Now it's time to prove to the world this fraud of a security person is exactly that.

Hey Khyber, you there? I got information for you.