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

41–50 of 72 posts

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

#41

Post by sklogic »

gsg wrote: post #33
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…

> 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…

> but remaining compatible really is almost always the right thing to do.

Luckily, not that much any more. In GPUs, for example, nobody cares, since nobody is carrying binaries around.

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

#42

Post by stefantalpalaru »

annnnd wrote: post #37

> A few years back, I used a Pentium 4 system... I hate it when blog posts don't include the date. Judging by the linked question this blog post must be at most a few months old, but there was nothing on the page that would tell me that. One of the most important questions is whether the information in the article is still applicable... In this case it is, but it would be nice if readers knew it. Not to mention 10 ye…

It's from January 11 2015, according to this page: http://danluu.com/blog/archives/

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

#43

Post by sklogic »

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?

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

#44

Post by sklogic »

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…

There are no caches nor DRAMs on most of the microcontrollers anyway, just plain, stupid, small SRAM blocks.

> having it managed at compile time

Uhm, been there, managing scratch memory statically can only work for very high level (and very domain specific) languages. Hardly possible for C.

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

#46

Post by trsohmers »

pjc50 wrote: post #39
trsohmers wrote: post #38

Earlier quoted context omitted.

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…

So the target market is .. high mips/watt microcontroller or DSP? If you have fully software managed memory it sounds like any binary running on the system has full access to any other memory? This is kind of the opposite of ARM "TrustZone". Edit: I'm just asking these questions because novel architectures tend to sink without trace and the small-system world is currently dominated by ARM. You need a real "wow" facto…

Our focus has been on floating point performance. Originally we were targeting high performance computing, but have since expanded to high end DSP applications (Think mobile base station processing for LTE-Advanced and "5G").

For memory protection, the most traditional way would be leaving it up to a RTOS or microkernel. Something very small and verifiably secure like seL4 is something we want to port.

We have not made it a huge priority to start of with as our customers have a small number of applications that are being ported and are isolated on the system. As each application needs to be recompiled for our architecture, we think that memory segmentation done at compile time is good enough to start with (in these limited cases).

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

#47

Post by trsohmers »

sklogic wrote: post #44
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…

There are no caches nor DRAMs on most of the microcontrollers anyway, just plain, stupid, small SRAM blocks. > having it managed at compile time Uhm, been there, managing scratch memory statically can only work for very high level (and very domain specific) languages. Hardly possible for C.

I'm not talking about microcontrollers in that case... Our chip has scratchpad for each core (128KB times 256 cores) with single cycle latency, along with attached DRAM. We have a whole lot more on chip memory that is 4x faster while using 1/5th of the power (on memory operations alone). Overall, we are aiming for a 10 to 25x energy efficiency improvement over CPU and GPUs for floating point heavy applications.

>managing scratch memory statically can only work for very high level (and very domain specific) languages. Hardly possible for C.

Well, we've solved that. Looking forward to sharing that in the near future.

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

#48

Post by sklogic »

trsohmers wrote: post #47
sklogic wrote: post #44

Earlier quoted context omitted.

There are no caches nor DRAMs on most of the microcontrollers anyway, just plain, stupid, small SRAM blocks. > having it managed at compile time Uhm, been there, managing scratch memory statically can only work for very high level (and very domain specific) languages. Hardly possible for C.

I'm not talking about microcontrollers in that case... Our chip has scratchpad for each core (128KB times 256 cores) with single cycle latency, along with attached DRAM. We have a whole lot more on chip memory that is 4x faster while using 1/5th of the power (on memory operations alone). Overall, we are aiming for a 10 to 25x energy efficiency improvement over CPU and GPUs for floating point heavy applications. >mana…

> Well, we've solved that.

If you really did, you've got much, much more than merely optimising a memory access. Consequences for the static analysis can be enormous. Looking forward to seeing your publication.

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

#49

Post by [deleted] »

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…

[deleted]

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

#50

Post by ansible »

gsg wrote: post #33
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…

> 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 how things actually turned out.

Post reply on HN