4 ms·

Maybe one could optimize for size (so you can make super tiny OS) ? Yes, and remember... optimizing for code size is optimizing for speed. =) Smaller code and

Maybe one could optimize for size (so you can make super tiny OS) ? Yes, and remember... optimizing for code size is optimizing for speed. =) Smaller code and data = more CPU cache hits, which are orders of magnitude faster than fetching from RAM. So even if "all" you do is make code smaller, you can get more speed...

fractalb 7y ago
> Yes, and remember... optimizing for code size is optimizing for speed. =) Not always. I think loop-unrolling is a common perf-optimisation technique. Even if the perf-gain is positive in this case, I highly suspect that it doesn't outweigh the cost of maintaining asm code(vs C/other higher level code). edit: formatting
- davedx 7y ago
  Yep. I remember loop unrolling the skeletal animation code in libgdx way back resulted in a significant performance increase. And that was in Java
- rurban 7y ago
  More so inlining. Much more than loop unrolling.
jfkebwjsbx 7y ago
Optimizing for size is a local maximum in performance.
pjmlp 7y ago
There are some LLVM optimization talks that show otherwise, where longer vectorized code actually runs faster than the smaller version, though.
- userbinator 7y ago
  ...in microbenchmarks. That's what created multi-kilobyte memcpy() implementations, which barely beat REP MOVSB but cause huge icache bloat.
papermachete 7y ago
Less code doesn't imply faster code. GCC coreutils have blasted through openbsd coreutils for years. Now we have CPUs with 256KB instruction cache and up. You can compile your whole OS at insane optimizations.