4 ms·

While "GHC is faster than CPython" is a fairly accurate generalization, I still think python performance is easier to reason about. Haskell can give you fast co

While "GHC is faster than CPython" is a fairly accurate generalization, I still think python performance is easier to reason about. Haskell can give you fast code, but sometimes it will be super slow for no obvious reason.

motet_a 9y ago
Moreover, CPython is a interpreter without JIT while GHC compiles to machine code. This is totally different. IMHO, it is much more correct to compare a JIT-enabled interpreter to GHC.
chongli 9y ago
super slow for no obvious reason Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know. GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-nonstrict data structures) so that the profiling tools become a last resort.
- whatshisface 9y ago
  A sufficiently smart [compiler | developer] can [make it so that | think] anything is easy. Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs that can make a single line worse than O(1).) "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.
  - cesarb 9y ago
    > "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell. Unless you use GCC's cleanup extension (which runs an arbitrary function when leaving a scope, similar to Rust's Drop trait). Or evil macros which turn innocent-looking code into something else (a well-known project, in some compilation modes, redefines the "if" keyword to track how many times each branch is taken). Or both at the same time (like hiding GCC's cleanup extension with a macro).
  - xwvvvvwx 9y ago
    Since performance is exactly a measure of the number of imperative steps that need to happen in a program This is an oversimplification. Writing fast code for modern processors is all about how much time you spend waiting for memory.
    - saosebastiao 9y ago
      Cache locality will never beat algorithmic complexity as a performance factor. Don't exaggerate its importance.
      - falcolas 9y ago
        It can, when the constant portion of the algorithm chosen is high and the number of items being pushed through the algorithm is low. e.g. bubblesort will beat quicksort for tiny lists or large lists which are already sorted. Or, put another way, 1000 operations against 1ns latency memory (L1) has the same performance as 10 operations against 100ns latency memory (RAM).
    - FullyFunctional 9y ago
      This is an oversimplification. Some compute intensive parts can get significant speed ups through careful use of data parallelism (such as SIMD). Others needs parallelism at the thread level. Etc. Optimizing for memory patterns is important as is trying to keep the working set within a near-level cache.

motet_a 9y ago

Moreover, CPython is a interpreter without JIT while GHC compiles to machine code. This is totally different. IMHO, it is much more correct to compare a JIT-enabled interpreter to GHC.

chongli 9y ago

super slow for no obvious reason Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know. GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-nonstrict data structures) so that the profiling tools become a last resort.

whatshisface 9y ago
A sufficiently smart [compiler | developer] can [make it so that | think] anything is easy. Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs that can make a single line worse than O(1).) "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.
- cesarb 9y ago
  > "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell. Unless you use GCC's cleanup extension (which runs an arbitrary function when leaving a scope, similar to Rust's Drop trait). Or evil macros which turn innocent-looking code into something else (a well-known project, in some compilation modes, redefines the "if" keyword to track how many times each branch is taken). Or both at the same time (like hiding GCC's cleanup extension with a macro).
- xwvvvvwx 9y ago
  Since performance is exactly a measure of the number of imperative steps that need to happen in a program This is an oversimplification. Writing fast code for modern processors is all about how much time you spend waiting for memory.
  - saosebastiao 9y ago
    Cache locality will never beat algorithmic complexity as a performance factor. Don't exaggerate its importance.
    - falcolas 9y ago
      It can, when the constant portion of the algorithm chosen is high and the number of items being pushed through the algorithm is low. e.g. bubblesort will beat quicksort for tiny lists or large lists which are already sorted. Or, put another way, 1000 operations against 1ns latency memory (L1) has the same performance as 10 operations against 100ns latency memory (RAM).
  - FullyFunctional 9y ago
    This is an oversimplification. Some compute intensive parts can get significant speed ups through careful use of data parallelism (such as SIMD). Others needs parallelism at the thread level. Etc. Optimizing for memory patterns is important as is trying to keep the working set within a near-level cache.