3 ms·

Speed of code and speed of development are not mutually exclusive.

by xigoi 5y ago

coldtea 5y ago
They force different tradeoffs to be made in languages but also in development, so they kind of are. Obviously: if speed of development and speed of program were non-problematically compatible, everybody would always go for both (why lose speed, if you can have the same development experience)? But speed requires several things, like more careful algorithms and program design, custom solutions instead of one-size-fits-all libraries and frameworks, more care regarding memory usage, time spend for optimization, use of a statically typed language as opposed to a higher level scripting one, slower build/jit times (as opposed to interpreter), and so on...
- xigoi 5y ago
  Statically typed languages can be high level. That was my main point. You can get a 100× speedup just by using Nim, Crystal, Go, … instead of Python.
mypalmike 5y ago
Garbage collection is an example (probably the most critical current example) where there is a concrete trade-off between the two.
- kaba0 5y ago
  Garbage collectors are not bottle necks at all, hell, for highly dynamic allocation patterns they beat malloc implementations out of the water in performance. Of course one should not spam them needlessly, but that’s why value classes are important.
  - mypalmike 5y ago
    "Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management." https://www.cs.tufts.edu/comp/150FP/archive/emery-berger/gc-vs-malloc.pdf https://www.cs.tufts.edu/comp/150FP/archive/emery-berger/gc-...
    - xigoi 5y ago
      Still, a good GCed language will be much faster than Python, especially when not under such memory constraints.

Speed of code and speed of development are not mutually exclusive.

by xigoi 5y ago

Speed of code and speed of development are not mutually exclusive.

They force different tradeoffs to be made in languages but also in development, so they kind of are. Obviously: if speed of development and speed of program were non-problematically compatible, everybody would always go for both (why lose speed, if you can have the same development experience)? But speed requires several things, like more careful algorithms and program design, custom solutions instead of one-size-fits-all libraries and frameworks, more care regarding memory usage, time spend for optimization, use of a statically typed language as opposed to a higher level scripting one, slower build/jit times (as opposed to interpreter), and so on...

xigoi 5y ago
Statically typed languages can be high level. That was my main point. You can get a 100× speedup just by using Nim, Crystal, Go, … instead of Python.

mypalmike 5y ago

Garbage collection is an example (probably the most critical current example) where there is a concrete trade-off between the two.

kaba0 5y ago
Garbage collectors are not bottle necks at all, hell, for highly dynamic allocation patterns they beat malloc implementations out of the water in performance. Of course one should not spam them needlessly, but that’s why value classes are important.
- mypalmike 5y ago
  "Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management." https://www.cs.tufts.edu/comp/150FP/archive/emery-berger/gc-vs-malloc.pdf https://www.cs.tufts.edu/comp/150FP/archive/emery-berger/gc-...
  - xigoi 5y ago
    Still, a good GCed language will be much faster than Python, especially when not under such memory constraints.