Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Lines of Code and Optimisation

Name: Anonymous 2013-05-25 8:06

Hi, I'm relatively new to programming and I have a question.

Does few LoC == faster? Or is it in the algorithm itself? Is there an instance where more LoC is faster than the shorter one?

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-05-29 7:50

Today's "stupid RISC-inspired design decision" is...

Stack frame alignment on Mac OS.
http://blogs.embarcadero.com/abauer/2010/01/14/38904

Data alignment requirements: another one of those profoundly stupid RISC design decisions. Maybe aligned access really was faster back when hardware was still relatively dumb but it doesn't matter a gnat's ass in these days of super-wide datapaths and Intelligent multilevel caching, instead all it does is uselessly consume memory bandwidth.

Scenario 1: processor never supported unaligned accesses but now it does. As a result all existing code would use only aligned accesses, and allowing unaligned accesses gains no benefit from that. Memory bandwidth becoming more important? Too bad, that old code is wasting it!

Scenario 2: processor always supported unaligned accesses, but a little slower, now unaligned accesses get faster. Existing code can never get slower, only faster. Those who used unaligned accesses will see performance improvements, those who didn't won't. Not a problem for memory bandwidth becoming the bottleneck.

http://lemire.me/blog/archives/2012/05/31/data-alignment-for-speed-myth-or-reality/

"It looks like even the data alignment requirements of SSE instructions will be lifted in the future AMD and Intel processors." See where things are headed? Not allowing unaligned accesses in some of the SSE moves was a huge mistake, and they're trying to fix that now, although I don't really think it'll be easily fixable - existing code won't benefit for the reason stated above.

tl;dr: RISC ISAs are held back by restrictive design decisions, CISCs have a lot more flexibility they can optimise on. "Implement a rich ISA and focus on making it faster over time" is clearly the best strategy here, not "make things simple and horrible now and hope we can increase the clock frequency over time"!

>>41
Japanese/Russian mix. NOT Jewish.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List