3 ms·

And a good compiler doesn't only optimize for speed. It also optimizes for code size, memory usage. I do however agree with underlying premise of this post: Co

by dkopi 11y ago

And a good compiler doesn't only optimize for speed. It also optimizes for code size, memory usage. I do however agree with underlying premise of this post: Code that works 100% of the time is better than higher performant code that explodes in your face every once in a while.

golergka 11y ago
> Code that works 100% of the time is better than higher performant code that explodes in your face every once in a while. That depends. In game programming, if I had a choice between a render that will crash once every 10 hours and produce 60 fps (in some model envrionment) vs a render that never crashes but produces 45 fps, I would choose the first one.
- iofj 11y ago
  Ditto for math libraries, machine learning libraries + tools, statistics calculations and matrix multiplier kernels. Hell, I'd take a 1% chance of blowup for a 10% speedup any day.
  - pif 11y ago
    > I'd take a 1% chance of blowup for a 10% speedup any day. Are you serious? Would you base your research career on software that you don't trust? I wouldn't. Please, notice that 1% chance of full blowup means a not-null probability of nice-looking-but-actually-false results from time to time, and that's a risk no researcher is allowed to accept.
    - iofj 11y ago
      > Are you serious? Would you base your research career on software that you don't trust? I wouldn't. I guess you haven't seen the quality of academic code recently. The choices are basing your credibility on slow badly written code or fast badly written code.
  - 0x07c0 11y ago
    That is what we have fast math for :)
0x07c0 11y ago
>And a good compiler doesn't only optimize for speed. It also optimizes for code size, memory usage. No they don't. Code size is rarely a problem (embedded probably cares..). Optimizations will in most cases lead to larger code, loop unrolling, inline expansion etc. In c the compiler cant't, in most cases do anything about memory usage. (Probably could pack structs.. , but that is not something the compiler would do I think, you would break ABI with non optimized code). In managed languages, memory usages is probably more depended on the runtime system GC, then compilers. GCC has a flag for code size optimization -Os https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
- dkopi 11y ago
  From that exact link: "Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program." "With -O, the compiler tries to reduce code size and execution time" So actually yes, The compiler optimizes for both size AND speed. Sometimes you can optimize for maximum speed (-O3), and sometimes optimize for minimum code size (-Os). You can even optimize for best debugging or best compilation times, and forget about size/speed. As for memory usage - 1. First of all - code uses up memory. smaller programs = less memory used for holding the exectuable code. 2. Consider the various ways you could compile a switch(-case) statement. You could build it as a set of conditional branches one after the other, you could compile it into a binary tree search (or a hash dictionary lookup), and you could jump to an address found in a lookup array table. This former method is also called a "branch table". https://en.wikipedia.org/wiki/Branch_table https://en.wikipedia.org/wiki/Branch_table A branch table would be the fastest method for implementing a switch with a few sequential values (0,1,2,3,4,5) But would be a really bad idea for sparse values (0,200,5000,10000,200000). Choosing not to use a branch table for sparse values is an optimization for Memory usage. And compilers make this decision all the time.

by dkopi 11y ago

golergka 11y ago

> Code that works 100% of the time is better than higher performant code that explodes in your face every once in a while. That depends. In game programming, if I had a choice between a render that will crash once every 10 hours and produce 60 fps (in some model envrionment) vs a render that never crashes but produces 45 fps, I would choose the first one.

iofj 11y ago
Ditto for math libraries, machine learning libraries + tools, statistics calculations and matrix multiplier kernels. Hell, I'd take a 1% chance of blowup for a 10% speedup any day.
- pif 11y ago
  > I'd take a 1% chance of blowup for a 10% speedup any day. Are you serious? Would you base your research career on software that you don't trust? I wouldn't. Please, notice that 1% chance of full blowup means a not-null probability of nice-looking-but-actually-false results from time to time, and that's a risk no researcher is allowed to accept.
  - iofj 11y ago
    > Are you serious? Would you base your research career on software that you don't trust? I wouldn't. I guess you haven't seen the quality of academic code recently. The choices are basing your credibility on slow badly written code or fast badly written code.
- 0x07c0 11y ago
  That is what we have fast math for :)

0x07c0 11y ago

>And a good compiler doesn't only optimize for speed. It also optimizes for code size, memory usage. No they don't. Code size is rarely a problem (embedded probably cares..). Optimizations will in most cases lead to larger code, loop unrolling, inline expansion etc. In c the compiler cant't, in most cases do anything about memory usage. (Probably could pack structs.. , but that is not something the compiler would do I think, you would break ABI with non optimized code). In managed languages, memory usages is probably more depended on the runtime system GC, then compilers. GCC has a flag for code size optimization -Os https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

dkopi 11y ago
From that exact link: "Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program." "With -O, the compiler tries to reduce code size and execution time" So actually yes, The compiler optimizes for both size AND speed. Sometimes you can optimize for maximum speed (-O3), and sometimes optimize for minimum code size (-Os). You can even optimize for best debugging or best compilation times, and forget about size/speed. As for memory usage - 1. First of all - code uses up memory. smaller programs = less memory used for holding the exectuable code. 2. Consider the various ways you could compile a switch(-case) statement. You could build it as a set of conditional branches one after the other, you could compile it into a binary tree search (or a hash dictionary lookup), and you could jump to an address found in a lookup array table. This former method is also called a "branch table". https://en.wikipedia.org/wiki/Branch_table https://en.wikipedia.org/wiki/Branch_table A branch table would be the fastest method for implementing a switch with a few sequential values (0,1,2,3,4,5) But would be a really bad idea for sparse values (0,200,5000,10000,200000). Choosing not to use a branch table for sparse values is an optimization for Memory usage. And compilers make this decision all the time.