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

51–60 of 72 posts

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

#51

Post by gsg »

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…

This is an interesting design question - which layer should be backwards compatible and under which significant freedom of design is allowed.

I'm not at all sure that the best answer is "source code". For x86 CPUs the compatible layer has been the ISA and that has turned out pretty damn well, suggesting that source compatibility is not the only and may not be the most effective choice.

Particularly if the source is C, which is rather ambiguous compared to most machine languages.

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

#53

Post by stochastician »

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…

Those numbers are amazing, do you perhaps have a citation ? I'm a machine learning researcher and would love to include them in talks about data-aware algorithms.

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

#54

Post by eternalban »

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…

> The best thing though would be having programmers really think about locality when writing their programs though.

You should talk to the Rust compiler folks :)

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

#55

Post by eternalban »

trsohmers wrote: post #38
pjc50 wrote: post #36

Earlier quoted context omitted.

fully software managed memory This is going to be interesting from a security point of view. It also sounds like users will need a new OS to take advantage of this?

Our initial target markets are those where programs would either be running on the bare metal (the basic program instructions running right on the cores, like an embedded system) or at most a pretty basic RTOS. From the bare metal standpoint, we can still have memory segmentation just like any other system... I would say it is even easier for the compiler to do that on our system due to the fact that all of the physi…

imo FP is a pretty ideal match for 'just-in-time-date' (JITD) systems.

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

#56

Post by scott_s »

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.

Highly technical posts on HN have a tendency to accrue a lot of upvotes before a discussion develops. I attribute this to (perhaps optimistically) people actually taking the time to read the post. When something is so technically dense, it can also be difficult for people to add anything to it; hence it takes a while before a real discussion starts.

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

#57

Post by fsaintjacques »

stochastician wrote: post #53
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…

Those numbers are amazing, do you perhaps have a citation ? I'm a machine learning researcher and would love to include them in talks about data-aware algorithms.

https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

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

#58

Post by scott_s »

dang wrote: post #25
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.

All: I had a negative reaction to this comment too at first, but on reflection it reads less like a jab and more like a rueful lament about mainstream programming culture. The fact that mgrennan loved the article and was so perfectly wrong about it not being appreciated here suggests that he or she just hasn't realized yet how much passion this community shares for the craft. It's depressing to feel like you're the o…

I'm coining a new term! dang charitable: being charitable in interpretation even in the face of aggressive uncharitableness.

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

#59

Post by zurn »

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.

Yes, registers and the belt are just ISA features. Register renaming is a behind the scenes implementation tech to mitigate the problems of register semantics. It has unwanted costs that a belt machine doesn't have to pay, and it's incorrect to say that Mill does register renaming in the traditional sense of the word.

Indeed that's what the #1 paragraph at https://millcomputing.com/docs/belt/ says: "A large fraction of the power budget of modern superscalar CPUs is devoted to renaming registers: the CPU must track the dataflow of the executing program, assign physical registers and map them to the logical registers of the program, schedule operations when arguments are available, restore visible state in the event of an exception—all while avoiding register update hazards."

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

#60

Post by optimiz3 »

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…

This is also true for GPUs - in cryptocurrency mining every memory access equals more money spent on power. If you can make equivalent (in terms of throughput) compute/memory trade-offs, you always go compute.
Post reply on HN