Lines of Code and Optimisation

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?

>>40
But Cudder is Russian. She's a Russian Jew.

premature ejaculation is the root of all evil - Donald Knuth

>>42
premature ejaculation is the root of all evil - Donald Knuth
I always thought there was something sinister about me.

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.

>>44
Isn't that what a jew would say?

>>44
But are you a she?

>>44
implying intel would emloy a non-halakha jew
le master ruseman face

>>44
Big design up front, that is. Which is partly justified because hardware interfaces are much less flexible than software ones.

However, you say it like people throw away their source code. Even so, compiling x86 to whatever may be difficult, but it isn't impossible. Also, backcompat is very desirable, but at some point you have to start from scratch to be able to evolve. Someone must climb the hills.

Another spine-chilling behaviour is how often people say how much important is to know how computers work to make better and efficient programs. It's funny because this excerpt suggests the other way around: that the second scenario is better and programmers shouldn't care how computers work because the implementation details can be worked out in the long run. So don't blame me for a decision I didn't made.