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

What's new in CPUs since the 80s and how does it affect programmers?

danluu.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: What's new in CPUs since the 80s and how does it affect programmers?

#61

Post by fiatmoney »

sklogic wrote: post #43
fiatmoney wrote: post #5

It's strange the extent to which programming interview questions reflect an 80s view of the cost of operations, particularly the overabundance of linked list and binary tree questions. Cache misses ain't free and memory scans are relatively cheap after you do the initial lookup.

Would you really prefer to be asked to write a cache-friendly hash map on a whiteboard?

It's not really that hard. Open addressing + linear probing + magic value for deletions is something you can implement in 15 minutes if you know how hashmaps work.

Of course "cache friendly" is relative; any hashmap has pseudorandom memory accesses as a core part of its design so again, array scans will beat it below a certain number of elements.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#62

Post by CyberDildonics »

trsohmers wrote: post #27
fiatmoney wrote: post #5

It's strange the extent to which programming interview questions reflect an 80s view of the cost of operations, particularly the overabundance of linked list and binary tree questions. Cache misses ain't free and memory scans are relatively cheap after you do the initial lookup.

Yep! The big thing people don't realize that it is memory operations that are the biggest cost in terms of both time and energy. While it takes ~100 picojoules to do a double precision floating point operation on a Ivy Bridge Intel processor, it takes 4200 picojoules to move the 64 bits from DRAM to your registers. Most people assume that the huge power usage is because you need to move data from off the chip, but th…

I hope you realize that managing memory latency has been the most fundamental motivation throughout Intel for 25 years. It isn't a problem that is a matter of a revelation about the problem itself.

I speed up programs all the time by reorganizing how memory is layed out and accessed. Many time by factors of 12x or more.

I would think that making SIMD, parallelism, and multiple simple loops instead of one bigger loop much easier to program around would be much more realistic. Something like a fusion of ISPC, Rust, C++11, and Julia.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#63

Post by Symmetry »

gizmo686 wrote: post #28
ansible wrote: post #21

What interested me in the design of the Mill CPU is how it throws out the usual design of machine language. I'm not talking about assembly language, and I know the difference, BTW. In the name of software compatibility, we're still trying to program CPUs using machine language that wouldn't be so strange to a programmer from the 1980's. Sure, there's more registers, and some fun new stuff, but it isn't all that diffe…

It is worth noting that many of the Mill features are also a "lie" (for example, the belt is still just registers and register renaming). Its just that the Mill uses lies designed for modern processor technology.

The belt isn't an abstraction of the structures in a modern OoO CPU corresponding to registers and renaming but rather the bypass network further down the pipeline. The belt like the bypass network only has to store data for limited periods and the translation is much simpler than what an OoO CPU has to do when renaming registers.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#64

Post by Symmetry »

Aoyagi wrote: post #45

This is a question from someone rather ignorant, so please don't hit me: Why didn't the Bulldozer affect the programmers? It (or Piledriver) seems to be doing quite well in applications with good threading.

In general all x86 chips are carefully designed to fulfill the abstraction that is the x86 ISA so to the programmer it shouldn't matter whether their code runs on an Atom or a Bulldozer or an i7.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#65

Post by rthomas6 »

CyberDildonics wrote: post #62
trsohmers wrote: post #27

Earlier quoted context omitted.

Yep! The big thing people don't realize that it is memory operations that are the biggest cost in terms of both time and energy. While it takes ~100 picojoules to do a double precision floating point operation on a Ivy Bridge Intel processor, it takes 4200 picojoules to move the 64 bits from DRAM to your registers. Most people assume that the huge power usage is because you need to move data from off the chip, but th…

I hope you realize that managing memory latency has been the most fundamental motivation throughout Intel for 25 years. It isn't a problem that is a matter of a revelation about the problem itself. I speed up programs all the time by reorganizing how memory is layed out and accessed. Many time by factors of 12x or more. I would think that making SIMD, parallelism, and multiple simple loops instead of one bigger loop…

>I would think that making SIMD, parallelism, and multiple simple loops instead of one bigger loop much easier to program around would be much more realistic. Something like a fusion of ISPC, Rust, C++11, and Julia.

What about functional programming? IMO the biggest benefit from programming without state is that order of execution does not matter. Thus programs can be parallelized trivially. Under the hood you end up with "multiple simple loops" without really even trying. I think when more people catch onto this, we're going to see a rise in functional language usage because of how easy it makes parallelism.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#66

Post by trsohmers »

CyberDildonics wrote: post #62
trsohmers wrote: post #27

Earlier quoted context omitted.

Yep! The big thing people don't realize that it is memory operations that are the biggest cost in terms of both time and energy. While it takes ~100 picojoules to do a double precision floating point operation on a Ivy Bridge Intel processor, it takes 4200 picojoules to move the 64 bits from DRAM to your registers. Most people assume that the huge power usage is because you need to move data from off the chip, but th…

I hope you realize that managing memory latency has been the most fundamental motivation throughout Intel for 25 years. It isn't a problem that is a matter of a revelation about the problem itself. I speed up programs all the time by reorganizing how memory is layed out and accessed. Many time by factors of 12x or more. I would think that making SIMD, parallelism, and multiple simple loops instead of one bigger loop…

First off, I was referring primarily to memory latency between L1 cache, which has improved over the past 2.5 decades only through the combination of Moore's law getting the wires shorter (which is going to end soon, at least for silicon) and increasing clockspeed (which really ended with the breakdown of Dennard scaling a little over 10 years ago). Intel's L1 cache latency has not improved in almost 10 years, with it still at 4 cycle latency (at best). The improvement has only been that there is more data you can access at L1, but the time to data hitting your registers has not improved at all.

Our scratchpad (the analogous term for software managed memory, in comparison to a traditional hardware managed L1/L2/L3 cache system) for instance has single cycle latency along with zero bus turnaround. Along with our ability to guarantee memory latencies between any locations in memory, our whole goal is to try to never have a wasted cycle.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#67

Post by cfallin »

ansible wrote: post #50
gsg wrote: post #33

Earlier quoted context omitted.

> In the name of software compatibility You say this as if it is a bad thing (or am I misinterpreting here?), but compatibility is enormously valuable. That's why the strategy of choosing compatibility over cleanliness of architecture is so widespread in successful complex systems - ISAs, OSs, the Web, programming languages, etc etc. It's hard to love the resulting complexities, but remaining compatible really is alm…

Software compatibility is both good and bad. If we were in the habit of recompiling from source with each CPU generation (this presumes source is available), that would allow much more innovation in machine language. And then the design of that machine language would more closely resemble the actual design of the CPU. But there are such significant advantage to remaining binary compatible, that I'm not surprised with…

I think most of the opportunity for "invisible" performance improvement today is below the ISA -- new branch predictors, new prefetchers, smarter cache hierarchy eviction/replacement heuristics. These are problems that are fundamental to the code: predicting dynamic behavior and having the right data nearby. (At least, this is what I saw again and again while staring at pipeline traces while working on a commercial microarchitecture.) A new ISA won't fix that.

Or maybe said in a different way, even if we recompile from C to a new ISA, we still have to execute the code that (by virtue of its algorithm) has unpredictable branches and lots of cache misses.

I do think there's room for innovation at a higher semantic level, e.g. maybe a really fast thread message-passing/synchronization mechanism with a lot of hardware thread contexts. Or lots of other ideas, e.g. "helper threads" (user-provided speculative prefetch code) or "informing memory operations" (load-and-branch-on-cache-miss). (All of these come out of comparch research in the 90's and 00's.) But all of those would require programmer cooperation, since they introduce new semantics.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#68

Post by Qwertious »

trsohmers wrote: post #27
fiatmoney wrote: post #5

It's strange the extent to which programming interview questions reflect an 80s view of the cost of operations, particularly the overabundance of linked list and binary tree questions. Cache misses ain't free and memory scans are relatively cheap after you do the initial lookup.

Yep! The big thing people don't realize that it is memory operations that are the biggest cost in terms of both time and energy. While it takes ~100 picojoules to do a double precision floating point operation on a Ivy Bridge Intel processor, it takes 4200 picojoules to move the 64 bits from DRAM to your registers. Most people assume that the huge power usage is because you need to move data from off the chip, but th…

http://rexcomputing.com/ for the lazy.

PS: Tell me more!

Re: What's new in CPUs since the 80s and how does it affect programmers?

#69

Post by mgrennan »

detaro wrote: post #3
mgrennan wrote: post #2

This is a wonderful post that no-one will care about. This may be the only post. Today, programmers are more interested in the rate they can turn out "Just Works" code. These kinds of details are fare fare to down in the weeds for a continuous development artists.

> This is a wonderful post that no-one will care about. This may be the only post. I think you are underestimating the crowd here. Last time it was posted it got quite a few responses: https://news.ycombinator.com/item?id=8873250 (already a while back, but might be interesting for reference/to bring topics up again)

Yes. I should have considered the crowd I was writing. I'm here. 35+ years of systems work starting with a 4004. I was inditing the new culture of "released and poor is better than not release and good" and "if it runs slow just scale it over more processors". In 1988 I did more in 48k of memory with 500k of disk then can be done in 4G mem and 500M of disk today.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#70

Post by mgrennan »

mgrennan wrote: post #2

This is a wonderful post that no-one will care about. This may be the only post. Today, programmers are more interested in the rate they can turn out "Just Works" code. These kinds of details are fare fare to down in the weeds for a continuous development artists.

Good to see I was wrong.
Post reply on HN