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?

I just found this new code optimizing algorithm:

(define (optimize S) (strip "\n" S))

>>1
Does few LoC == faster?
No. Faster = more specialized = more SLOC.

I.e. FPGA code is fastest, but requires the more SLOC than assembly code, which requires more SLOC than C/C++, which requires more SLOC than languages with garbage collection.

Well, in C, you can compare a dumb strlen implementation with one using a Duff's device. The latter will need more LOCs, but should be faster (depending in the compiler).

>>4
Is dd really optimizing?

no ^^

>>5
It's an unrolled loop.

It doesn't really matter really because computers run so fast nowadays. Just use whatever algorithm work best for you. Let's say you were to write a FizzBuzz program.

Which is faster? Using array-look up or an if-else clause-terfuck? You can't tell right?

Is there an instance where more LoC is faster than the shorter one?
Yes, compare an adder written in C, and an adder using interfaces, abstract methods and tight coupling cloud enabled business logic performance boosting stock market potential customer leverager in Java.

>>9
SUCK MY ADDER

>>10
SUCK MY DUBS

>>11
Reported

http://www.youtube.com/watch?v=46m3QMf5jpQ

>>9
yes, but java adder has added value.

>>13
KEINE THE COW

>>15
DON'T MOCK KEINE ASFASDFASDFASDFASDFASDF I FUCKING HATE YOU CRETIN ASDFASDFASDFASDFASDFAKHDSFQILWEUHFIAUHSDFKLJADSHFKLAHDSFASK MEET THE NASTY END OF MY SHOTGUN AND DIE IN A FIRE CRETIN

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /＼＿＿_／ヽ
　　　 (.｀ヽ(｀＞ 、ENTERPRISE QUALITY　　　　　／''''''　　　'''''':::::＼
　　 　 `'＜｀ゝr'ﾌ＼　　　　　　　　　　　　　　　　　＋　　|（●）,　　　､（●）､.:|　＋
　 ⊂ｺ二Lﾌ^´　 ノ, ／⌒)　　　　　　　　　　　　　　　　　|　　,,,ﾉ(､_, )ヽ､,,　.::::|
　　⊂l二L7_ノ /　-ゝ-')´　　　　　　　　　　　　　　　.+　|　　 ｀-=ﾆ=- '　.::::::|　+　.
　　　　　　 ＼_　　､__,.ｲ＼　　　　　　　　　　　＋　　　　 ＼　　 ｀ﾆﾆ´　 .:::／　　　　+
　　　　　　　　 (T＿_ノ　　 Tヽ　　　　　　　 , -r'⌒!￣ `":::7ヽ.｀- ､　　　./|　　.
　　　　　　　　　ヽ￢.　　　/　ﾉ`ｰ-､ﾍ<ｰ1´|　 ヽ　| :::::::::::::ﾄ、 ＼　(　　./ヽ
　　　　　　　　　　＼l__,.／　　 　 　 i　l.ヽ!　|　　　.| ::::::::::::::l ヽ 　 ｀７ｰ.､‐'´ |＼-､
　　　　　　　　　　　 ﾚ|　　　　　　　 ヽ |　{　l　　　l ::::::::::::::::l　ヽ　 ,ﾍ,',',',ヽ　 l:::::::::
　　　　　　　　　　　 ヽl　　　　／　　　＼ ヽ､　　/ ::::::::::::::::::ヽ　∨　.〉‐〈 ヽﾉ|::::::::
　　　　　　　　　　　　　ヽニ二..＿＿　　 `ｰ=ゝｿ :::::::::::::::::::::::ヽ.　　 l,',',','l 　 l::::::::
　　　　　　　　　　　　　　　　　　　　　￣￣｢￣,,;::::::::::::::::::::::::::::ヽ.　 |,',',',' !　,'::::::::
　　　　　　　　　　　　　　　　　　 　 　 　 　 l　;;;::::::::::::::::::::::::::::::::::ヽ |,',',',','| /::::::::

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /＼＿＿_／ヽ
　　　 (.｀ヽ(｀＞ 、ENTERPRISE QUALITY　　　　　／''''''　　　'''''':::::＼
　　 　 `'＜｀ゝr'ﾌ＼　　　　　　　　　　　　　　　　　＋　　|（●）,　　　､（●）､.:|　＋
　 ⊂ｺ二Lﾌ^´　 ノ, ／⌒)　　　　　　　　　　　　　　　　　|　　,,,ﾉ(､_, )ヽ､,,　.::::|
　　⊂l二L7_ノ /　-ゝ-')´　　　　　　　　　　　　　　　.+　|　　 ｀-=ﾆ=- '　.::::::|　+　.
　　　　　　 ＼_　　､__,.ｲ＼　　　　　　　　　　　＋　　　　 ＼　　 ｀ﾆﾆ´　 .:::／　　　　+
　　　　　　　　 (T＿_ノ　　 Tヽ　　　　　　　 , -r'⌒!￣ `":::7ヽ.｀- ､　　　./|　　.
　　　　　　　　　ヽ￢.　　　/　ﾉ`ｰ-､ﾍ<ｰ1´|　 ヽ　| :::::::::::::ﾄ、 ＼　(　　./ヽ
　　　　　　　　　　＼l__,.／　　 　 　 i　l.ヽ!　|　　　.| ::::::::::::::l ヽ 　 ｀７ｰ.､‐'´ |＼-､
　　　　　　　　　　　 ﾚ|　　　　　　　 ヽ |　{　l　　　l ::::::::::::::::l　ヽ　 ,ﾍ,',',',ヽ　 l:::::::::
　　　　　　　　　　　 ヽl　　　　／　　　＼ ヽ､　　/ ::::::::::::::::::ヽ　∨　.〉‐〈 ヽﾉ|::::::::
　　　　　　　　　　　　　ヽニ二..＿＿　　 `ｰ=ゝｿ :::::::::::::::::::::::ヽ.　　 l,',',','l 　 l::::::::
　　　　　　　　　　　　　　　　　　　　　￣￣｢￣,,;::::::::::::::::::::::::::::ヽ.　 |,',',',' !　,'::::::::
　　　　　　　　　　　　　　　　　　 　 　 　 　 l　;;;::::::::::::::::::::::::::::::::::ヽ |,',',',','| /::::::::

>>17

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /＼＿＿_／ヽ
　　　 (.｀ヽ(｀＞ 、ENTERPRISE QUALITY　　　　　／''''''　　　'''''':::::＼
　　 　 `'＜｀ゝr'ﾌ＼　　　　　　　　　　　　　　　　　＋　　|（●）,　　　､（●）､.:|　＋
　 ⊂ｺ二Lﾌ^´　 ノ, ／⌒)　　　　　　　　　　　　　　　　　|　　,,,ﾉ(､_, )ヽ､,,　.::::|
　　⊂l二L7_ノ /　-ゝ-')´　　　　　　　　　　　　　　　.+　|　　 ｀-=ﾆ=- '　.::::::|　+　.
　　　　　　 ＼_　　､__,.ｲ＼　　　　　　　　　　　＋　　　　 ＼　　 ｀ﾆﾆ´　 .:::／　　　　+
　　　　　　　　 (T＿_ノ　　 Tヽ　　　　　　　 , -r'⌒!￣ `":::7ヽ.｀- ､　　　./|　　.
　　　　　　　　　ヽ￢.　　　/　ﾉ`ｰ-､ﾍ<ｰ1´|　 ヽ　| :::::::::::::ﾄ、 ＼　(　　./ヽ
　　　　　　　　　　＼l__,.／　　 　 　 i　l.ヽ!　|　　　.| ::::::::::::::l ヽ 　 ｀７ｰ.､‐'´ |＼-､
　　　　　　　　　　　 ﾚ|　　　　　　　 ヽ |　{　l　　　l ::::::::::::::::l　ヽ　 ,ﾍ,',',',ヽ　 l:::::::::
　　　　　　　　　　　 ヽl　　　　／　　　＼ ヽ､　　/ ::::::::::::::::::ヽ　∨　.〉‐〈 ヽﾉ|::::::::
　　　　　　　　　　　　　ヽニ二..＿＿　　 `ｰ=ゝｿ :::::::::::::::::::::::ヽ.　　 l,',',','l 　 l::::::::
　　　　　　　　　　　　　　　　　　　　　￣￣｢￣,,;::::::::::::::::::::::::::::ヽ.　 |,',',',' !　,'::::::::
　　　　　　　　　　　　　　　　　　 　 　 　 　 l　;;;::::::::::::::::::::::::::::::::::ヽ |,',',',','| /::::::::

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /＼＿＿_／ヽ
　　　 (.｀ヽ(｀＞ 、ENTERPRISE QUALITY　　　　　／''''''　　　'''''':::::＼
　　 　 `'＜｀ゝr'ﾌ＼　　　　　　　　　　　　　　　　　＋　　|（●）,　　　､（●）､.:|　＋
　 ⊂ｺ二Lﾌ^´　 ノ, ／⌒)　　　　　　　　　　　　　　　　　|　　,,,ﾉ(､_, )ヽ､,,　.::::|
　　⊂l二L7_ノ /　-ゝ-')´　　　　　　　　　　　　　　　.+　|　　 ｀-=ﾆ=- '　.::::::|　+　.
　　　　　　 ＼_　　､__,.ｲ＼　　　　　　　　　　　＋　　　　 ＼　　 ｀ﾆﾆ´　 .:::／　　　　+
　　　　　　　　 (T＿_ノ　　 Tヽ　　　　　　　 , -r'⌒!￣ `":::7ヽ.｀- ､　　　./|　　.
　　　　　　　　　ヽ￢.　　　/　ﾉ`ｰ-､ﾍ<ｰ1´|　 ヽ　| :::::::::::::ﾄ、 ＼　(　　./ヽ
　　　　　　　　　　＼l__,.／　　 　 　 i　l.ヽ!　|　　　.| ::::::::::::::l ヽ 　 ｀７ｰ.､‐'´ |＼-､
　　　　　　　　　　　 ﾚ|　　　　　　　 ヽ |　{　l　　　l ::::::::::::::::l　ヽ　 ,ﾍ,',',',ヽ　 l:::::::::
　　　　　　　　　　　 ヽl　　　　／　　　＼ ヽ､　　/ ::::::::::::::::::ヽ　∨　.〉‐〈 ヽﾉ|::::::::
　　　　　　　　　　　　　ヽニ二..＿＿　　 `ｰ=ゝｿ :::::::::::::::::::::::ヽ.　　 l,',',','l 　 l::::::::
　　　　　　　　　　　　　　　　　　　　　￣￣｢￣,,;::::::::::::::::::::::::::::ヽ.　 |,',',',' !　,'::::::::
　　　　　　　　　　　　　　　　　　 　 　 　 　 l　;;;::::::::::::::::::::::::::::::::::ヽ |,',',',','| /::::::::

What are you people doing?

>>21
I was trying to fix >>17-kun's SJIS art, but apparently he fucked up multiple times.

Extensive loop unrolling is counterproductive on any good architecture, where the hardware will unroll the loop automatically inside the CPU instead of having to waste cycles fetching each instruction over and over again from the massive amount of wasted cache space.

It might look a little faster in microbenchmarks on that piece of code because you've reduced the barely existent branch delay, but in doing so, you've also evicted a bunch of useful code from the cache --- if it's not a microbenchmark --- and  branch overhead is TINY compared to a cache miss. Those idiots who write 4KB memcpy()s have this problem; yes, your code probably is the fastest way to copy a chunk of data around. No, it's not going to make all programs that use it faster, because now the code in the 1/8th of the L1 cache that it evicted is going to need to be read back in.

>>23
Post ignored.

Does few LoC == faster?

No.

Compare a hash table associative array with a simple key-value pair array.
The hash table will almost always be significantly faster.

Optimisation won't matter once we make computers that can work out all algorithms instantaneously

>>26
Well when that day arrives, it will be great.
Until then we'll have to optimise though ^^

>>23
Cudder, silly fucktard, go write PHP code, because you shouldn't use broken memcpy: http://lwn.net/Articles/414467/

moreover, compilers have "optimize for size" option, so GCC should provide correct version of malloc for correct CPU, you chosen.

>>28
glibc memcpy is stupidly bloated. rep movs is The One True memcpy(). It's what Linus himself uses. (Read his comments here:
https://bugzilla.redhat.com/show_bug.cgi?id=638477 )

>>23
Btw, how do you learn so much about CPUs ? Did you read the entire Intel manual or do you have some books to recommend ?

Does few LoC == faster?
No.

Or is it in the algorithm itself?
Kind of.

Is there an instance where more LoC is faster than the shorter one?
I/O buffering for instance.

>>30
http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html

>>32

20.3 - The Keyboard DOS Interface
21.3.1 - Printing via DOS
21.3.2 - Printing via BIOS

That is a lot of computer archeology. Can't wait that part with Dinosaur feces.

>>33
Still beats programming an 8255 directly.

>>30
Yes.

Also http://www.agner.org/optimize/

>>35
cudder, are you married?

pls respond

>>36
I doubt Israel allows gay marriages. It is a fucking fundamentalist zionazi shithole.

>>31
I/O buffering for instance.
What?

>>37
What? No, Jews are the ones who promote feminism, homofaggotry and all that shit.

>>39
They promote it for every country that isn't yishrahell, just like with multiculturalism, immigration, and drugs.