3 ms·

Well, the obvious place to start is via using separate memory channels. If you have separate load/store queues for the stack and heap you can have substantiall

Well, the obvious place to start is via using separate memory channels. If you have separate load/store queues for the stack and heap you can have substantially higher max performance for the same area/power since the cost of that structure scales super-linearly. But that means you can't have arrays with a mix of pointers to heap and stack allocated objects. That's one of the things the Reduceron (mentioned elsewhere) does.

_yosefk 11y ago
I plan to write about it; the thing is, the Reduceron is not a more performant machine when all is said and done. Memory costs you a lot in area and power and throwing channels at the problem needlessly and saying youve solved the von neumann bottleneck is a worse idea than trying to avoid banging at the memory needlessly; using C is a part of a working strategy to acheive the latter.
- Symmetry 11y ago
  Breaking up the load/store queue would basically just be a way of increasing parallelism at the core level for free. You wouldn't be changing the amount of memory in caches, just increasing the rate at which you can issue loads or stores and the number of outstanding accesses the core could support. Well, you might consider a split L1D but there are lots of tradeoffs with that and you'd have to simulate to figure out if that'd be a good idea.
JoeAltmaier 11y ago
Further, separate the call stack from the 'display' or local variable stack. Conflating them causes bugs, is appropriate only for some code models, and makes it harder on tools. Computers didn't used to work this way; some paper got published about combining them and everybody after went the one-stack direction by default. It doesn't make a lot of sense today.
Symmetry 11y ago
I should also say that if you're designing a core for a specific workload there are always ways you can optimize it but that doesn't have anything to do with high or low level languages. See the presentation on the M6 at Hot Chips for the way they tuned their cache hierarchy to work with their database. The talk is on the Day 2 track here: http://www.hotchips.org/archives/2010s/hc26/ http://www.hotchips.org/archives/2010s/hc26/

_yosefk 11y ago

I plan to write about it; the thing is, the Reduceron is not a more performant machine when all is said and done. Memory costs you a lot in area and power and throwing channels at the problem needlessly and saying youve solved the von neumann bottleneck is a worse idea than trying to avoid banging at the memory needlessly; using C is a part of a working strategy to acheive the latter.

Symmetry 11y ago
Breaking up the load/store queue would basically just be a way of increasing parallelism at the core level for free. You wouldn't be changing the amount of memory in caches, just increasing the rate at which you can issue loads or stores and the number of outstanding accesses the core could support. Well, you might consider a split L1D but there are lots of tradeoffs with that and you'd have to simulate to figure out if that'd be a good idea.

JoeAltmaier 11y ago

Further, separate the call stack from the 'display' or local variable stack. Conflating them causes bugs, is appropriate only for some code models, and makes it harder on tools. Computers didn't used to work this way; some paper got published about combining them and everybody after went the one-stack direction by default. It doesn't make a lot of sense today.

Symmetry 11y ago

I should also say that if you're designing a core for a specific workload there are always ways you can optimize it but that doesn't have anything to do with high or low level languages. See the presentation on the M6 at Hot Chips for the way they tuned their cache hierarchy to work with their database. The talk is on the Day 2 track here: http://www.hotchips.org/archives/2010s/hc26/ http://www.hotchips.org/archives/2010s/hc26/