3 ms·

In general, you're not smarter than your compiler[1]. Even if you're smarter than your compiler it's usually not worth the readability trade-off. These sorts

by Smerity 14y ago

In general, you're not smarter than your compiler[1]. Even if you're smarter than your compiler it's usually not worth the readability trade-off. These sorts of optimisations only ever make sense if you're doing something incredibly intensive and you've tested it on real world data. This is rarely the case and the code suffers. [1]: "Source Code Optimization" => http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf http://www.linux-kongress.org/2009/slides/compiler_survey_fe...

hrktb 14y ago
Perhaps thinking about it as an optimisation and not a standard operation is not the best way to look at it. For example 99% of the time I want a binary shift and not a /2.In a dynamically typed language 201/2 will give you 100.5 when you'd prefer to keep it integer.
- pwaring 14y ago
  "In a dynamically typed language 201/2 will give you 100.5" Not necessarily. Python gives 100, PHP gives 100.5, Perl gives 100.5, Ruby gives 100. Edit: Versions are Python 2.7.3, PHP 5.3.10, Perl 5.14.2 and Ruby 1.8.7, all as shipped with Ubuntu Precise.
  - archangel_one 14y ago
    Python 3 gives 100.5. Python 2 gives 100 (or 100.5 if you use "from __future__ import division").
    - fjh 14y ago
      But using >> for division is still a bad idea. If you want integer division, use //.
- wglb 14y ago
  Um, no. Lisp will give you 201/2.
csl 14y ago
Thanks for this. It's not the 90s anymore, that's for sure. I just tried my age-old adage of doing bit shifts and adds instead of multiplications. Turns out that's slower on an i7! The cool thing is that llvm-g++ actually recognizes my bad hand-optimization on -O3 and fixes it. Code at https://gist.github.com/2896137 https://gist.github.com/2896137
alexchamberlain 14y ago
I agree, except you must be intelligent enough to use the correct algorithm for the job.
dllthomas 14y ago
>These sorts of optimisations only ever make sense if you're doing something incredibly intensive and you've tested it on real world data. This is rarely the case and the code suffers. Or are working on something incredibly small with an incredibly stupid compiler.

by Smerity 14y ago

hrktb 14y ago

Perhaps thinking about it as an optimisation and not a standard operation is not the best way to look at it. For example 99% of the time I want a binary shift and not a /2.In a dynamically typed language 201/2 will give you 100.5 when you'd prefer to keep it integer.

pwaring 14y ago
"In a dynamically typed language 201/2 will give you 100.5" Not necessarily. Python gives 100, PHP gives 100.5, Perl gives 100.5, Ruby gives 100. Edit: Versions are Python 2.7.3, PHP 5.3.10, Perl 5.14.2 and Ruby 1.8.7, all as shipped with Ubuntu Precise.
- archangel_one 14y ago
  Python 3 gives 100.5. Python 2 gives 100 (or 100.5 if you use "from __future__ import division").
  - fjh 14y ago
    But using >> for division is still a bad idea. If you want integer division, use //.
wglb 14y ago
Um, no. Lisp will give you 201/2.

csl 14y ago

Thanks for this. It's not the 90s anymore, that's for sure. I just tried my age-old adage of doing bit shifts and adds instead of multiplications. Turns out that's slower on an i7! The cool thing is that llvm-g++ actually recognizes my bad hand-optimization on -O3 and fixes it. Code at https://gist.github.com/2896137 https://gist.github.com/2896137

alexchamberlain 14y ago

I agree, except you must be intelligent enough to use the correct algorithm for the job.

dllthomas 14y ago

>These sorts of optimisations only ever make sense if you're doing something incredibly intensive and you've tested it on real world data. This is rarely the case and the code suffers. Or are working on something incredibly small with an incredibly stupid compiler.