Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's wrong with Intel, and how to fix it: Former principal engineer unloads

pcworld.com

Post reply on HN
Print view View original

61–70 of 117 posts

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#61

Post by KMag »

glangdale wrote: post #28
supernova87a wrote: post #12

This is purely a total outsider's opinion, so I caveat that and please don't get all offended if I'm totally wrong. Sometimes it's really difficult to tell the difference between a crackpot theorist and a good equities analyst. Watching this guy's video, it's hard to tell which he comes off as more. He's just coherent and convincing enough that as an outsider I could believe his collection of observations. But the pr…

Francois is a smart guy, but there's a range of opinions on the matters he raises. We argue a good deal on Twitter ("constructive confrontation" between former Intel Principal Engineers :-) ). He put together the video pretty quickly so don't dismiss it just for lack of polish. Personally, I argue with him a lot on AVX-512. I think AVX-512 is a Good Thing (or will be shortly - the first instantiation in Skylake Serve…

I've worked on a project to compile a domain-specific description language down to both SIMD (by using Intel SPMD Program Compiler) and GPGPU (by using CUDA and OpenCL) Monte Carlo simulation code. We also have a Scala/Java interpreter for debugging.

Are there workloads that benefit from very wide SIMD vectors that aren't good fits for GPGPUs, as long as the GPUs support 64-bit floats close enough to IEEE-754 for your needs? I understand the overhead in shuffling data between main memory and GPU memory, and synchronization overhead, but most code I'm familiar with that does heavy number crunching suitable for very wide SIMD tends to do that number crunching off on threads that don't have much synchronization with threads doing more general-purpose computation.

On a side note, ISPC's input language is deceptively close to C, but little traps lie in wait. I remember helping an intern debug his port of some of the Java code I wrote over to ISPC, but it turns out that mulitplying a long long by a double in ISPC results in a long long. Our attempt to scale down a random 64-bit integer to the range [0.0, 1.0) was always resulting in 0.0. I get that integer calculations are faster, and I could understand disallowing implicit casts, but making a language so close to C, but with different implicit casting rules is just asking for trouble.

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#62

Post by me_me_me »

Jonnax wrote: post #5

So Linus, and this guy is saying AVX512 was a bad idea. "“The state of software out there is really not favoring going larger vectors,” Piednoel said in the video. “In fact, you can see clearly in Cinebench for example—that is not one of my favorite benchmarks, especially for a laptop where it doesn’t make any sense—but you can see that AMD is winning the battle of throughput. It’s because they have more cores and th…

> and this guy is saying AVX512 was a bad idea.

He said that its a bad idea to put it in every xeon chip. AVX is great tool for specific high throughput oncore calculations, when offloading to gpu would be too costly.

Saying AVX512 is universally bad is like saying that welding machines are bad tools since carpenters never make use of it.

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#63

Post by me_me_me »

dman wrote: post #25
atq2119 wrote: post #17

Earlier quoted context omitted.

AVX-512 really has two parts. It widens vectors to 512 bits, but it also makes the instruction set much more orthogonal and clean. It also adds masking of lanes. These latter parts are what's really useful about AVX-512. The widening of the vectors is just an area tradeoff that depends a lot on the particular workload.

Unfortunately there is a clock penalty to using AVX-512 and it is only available on a small part of the chips that Intel ships (For the longest time it was only available on Xeons). AMD does not support AVX-512 yet. As a result no one really had the incentive to add support for it outside HPC where people have control of both the workload and the hardware it runs on. To further complicate matters there are multiple v…

Its not magic, everything has trade-offs.

The bigger and more powerful AVX instruction the more power it needs - more power results in more heat, heat that modern cpus cannot handle (reason why we dont see higher cloked cpus).

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#64

Post by flyinghamster »

dathinab wrote: post #54

I'm not knowing how much of this things are true, but isn't it ironic that AMD has more benefits from SMT because they have less pipeline optimizations (and similar), but exactly this pipeline optimizations (and similar) seem to be at least partially at fault for some of the Specter style attacks and make it harder to put more cores into the system (as this additional optimizations are likely need more silicon space.…

Most (all?) recent Qualcomm Snapdragons have exactly such small, low-power cores to handle background work. Extending that further is interesting, though it presents some tricky scheduling problems for the operating system.

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#65

Post by me_me_me »

gok wrote: post #49

Whining about "MBAs" is almost always technical person speak for general discontent about company direction, often from the non-business parts. You don't see complaints about CEOs of Apple, Google, or Microsoft much, though they all have MBAs.

MBAs improve numbers, engineers create new products. The mentality of MBA crowd is to get the numbers right eat the cake and when things go sideways move on to a new job.

Intel is a hardware tech business, its a complicated space that needs deep knowledge to understand it before you shape the future of it.

Technical people might not be the only ones that should run business but they should be the core of it.

I have same view as the video, engineers need more power and decision making not less to win. Intel will not fight back by cutting down cost of production by 5%. But by creating next gen chip.

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#66

Post by glangdale »

KMag wrote: post #61
glangdale wrote: post #28

Earlier quoted context omitted.

Francois is a smart guy, but there's a range of opinions on the matters he raises. We argue a good deal on Twitter ("constructive confrontation" between former Intel Principal Engineers :-) ). He put together the video pretty quickly so don't dismiss it just for lack of polish. Personally, I argue with him a lot on AVX-512. I think AVX-512 is a Good Thing (or will be shortly - the first instantiation in Skylake Serve…

I've worked on a project to compile a domain-specific description language down to both SIMD (by using Intel SPMD Program Compiler) and GPGPU (by using CUDA and OpenCL) Monte Carlo simulation code. We also have a Scala/Java interpreter for debugging. Are there workloads that benefit from very wide SIMD vectors that aren't good fits for GPGPUs, as long as the GPUs support 64-bit floats close enough to IEEE-754 for you…

You're in a bit of a different domain - I've never really done all that much stuff with heavy number crunching (I've done a bit of work on random forest traversal, but that's more about logic than about FP). And I have never worked with ISPC.

I think number crunching workloads are typically quite suitable for GPGPU - I'm certainly not trying to "debunk GPGPU", just saying that there are a lot of integer/logic intensive workloads that involve rapid switching back and forth between control/GPR-based-logic sides and "SIMD tasks" (e.g. Hyperscan switching between NFA/DFA simulation and "acceleration", which was SIMD-based character skipping).

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#67

Post by glangdale »

pantalaimon wrote: post #59
glangdale wrote: post #32

Earlier quoted context omitted.

Oh, I should note that an interest in large SIMD is not confined to Intel - the ARM world is (slowly) heading towards SVE (or so my friends from that quarter assure me). So it's not just a partisan pro-Intel or pro-x86 thing on my part.

RISC-V is also adding Vector extensions. The cool thing about those is that they are variable length, so code can take advantage of newer hardware / degrade gracefully on less capable one. https://gms.tf/riscv-vector.html

I think going for variable length is a Bold Move, and am not sure I like it for an ISA that otherwise is trying to be conservative. I'll be more optimistic about it when I see SVE (a) on more than one HPC machine and (b) implemented in a variety of widths. I'll be impressed if it works, but I'm not going to be impressed ahead of time with it while it's an aspirational design because it has aspirations.

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#69

Post by PaulHoule »

KMag wrote: post #61
glangdale wrote: post #28

Earlier quoted context omitted.

Francois is a smart guy, but there's a range of opinions on the matters he raises. We argue a good deal on Twitter ("constructive confrontation" between former Intel Principal Engineers :-) ). He put together the video pretty quickly so don't dismiss it just for lack of polish. Personally, I argue with him a lot on AVX-512. I think AVX-512 is a Good Thing (or will be shortly - the first instantiation in Skylake Serve…

I've worked on a project to compile a domain-specific description language down to both SIMD (by using Intel SPMD Program Compiler) and GPGPU (by using CUDA and OpenCL) Monte Carlo simulation code. We also have a Scala/Java interpreter for debugging. Are there workloads that benefit from very wide SIMD vectors that aren't good fits for GPGPUs, as long as the GPUs support 64-bit floats close enough to IEEE-754 for you…

Dan Luu does brilliant things parsing strings with SIMD instructions but the programming model is busted if you have to recompile (and maybe hand code assembly) for each chip.

I was involved with wrapping up a deep neural net application just as GPGPU was about to take off. We used hand coded SIMD, performance was fine, but we were not going to recode for the next generation from chips, change our error function, or change anything SIMD related.I

Before there was MMX computers came with vector units that did not have a programmer visible size, such as the Cray 1 and the vector unit for the 3090 mainframe. As it is, people hardly use vector instructions or if they use them it is something a few generations old so people pay for vector units that they don't use.

Re: What's wrong with Intel, and how to fix it: Former principal engineer unloads

#70

Post by PaulHoule »

pantalaimon wrote: post #59
glangdale wrote: post #32

Earlier quoted context omitted.

Oh, I should note that an interest in large SIMD is not confined to Intel - the ARM world is (slowly) heading towards SVE (or so my friends from that quarter assure me). So it's not just a partisan pro-Intel or pro-x86 thing on my part.

RISC-V is also adding Vector extensions. The cool thing about those is that they are variable length, so code can take advantage of newer hardware / degrade gracefully on less capable one. https://gms.tf/riscv-vector.html

The small, medium and large sizes built into arms neon accomplishes some scalability without going back to what vector units were like in the big hair 1980s.
Post reply on HN