45 ms·

> generic code is replaced by its concrete instances, which are faster If you're using a shitty compiler, yes.

jstimpfle 8y ago
By that standard I seem to know only shitty compilers. Sorry to be blunt but you don't have a clue. As a rule of thumb, compilers can make a 10x difference (for example in machine code performance). Programmers can easily make a 1000x difference. Not even looking at algorithmic improvements.
coldtea 8y ago
http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler
- wild_preference 8y ago
  They're referring to monomorphization. Rust, for example: > You might be wondering whether there is a runtime cost when you’re using generic type parameters. The good news is that Rust implements generics in such a way that your code doesn’t run any slower using generic types than it would with concrete types. > Rust accomplishes this by performing monomorphization of the code that is using generics at compile time. Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when compiled.
  - jstimpfle 8y ago
    Where do you get that monomorphization reference from? Let's assume for example you have a generic hash map where you just plug the type in, which must be hashable. Now if you plug in an integer type, monomorphization or whatever fancy compilation techniques will make that faster. But the best way to map an integer range is still a plain array. To put it in simple terms, compilers can make shit run faster, but they can't make it not shit.
    - tathougies 8y ago
      Hm... this seems like an incredibly poorly thought out example on your part. We've had C++ template specialization for decades. It is trivial to implement a map that uses hashes for non-integer types and an array for integer ones. This is 2018 after all.
      - deleted 8y ago
        [deleted]
      - jstimpfle 8y ago
        Specialized code is... not generic code, right? Furthermore template specialization is usually a bad idea. Think how we just LOVE std::vector<bool> (/s). Also std::unordered_map<int> is not specialized to an array implementation. Because you can't tell from the type whether it will map a contiguous range. I've done my homework. Your turn.
        spenczar5 8y ago
        Yikes, I have no dog in this fight, but the level of sarcasm and meanness in your post ("Your turn.") just seems over the top for this argument. You'd be more convincing if you were more level, at least for me.
        jstimpfle 8y ago
        > incredibly poorly thought out example on your part But maybe you're right and I should have ignored it...
        tathougies 8y ago
        It's absolutely generic. The code that uses the map would be indifferent to the type of key. The code that implements it is obviously different, because they are two separate implementations. It seems unlikely that you could have automatic specialized implementations without substantial improvements in AI.
    - alexhutcheson 8y ago
- vmchale 8y ago
  No, this is a completely standard compiler optimization. GHC already has it. Using (=<<) is not slower than concatMap on code you write today.
  - coldtea 8y ago
    GHC is a compiler specially used for PL research, dedicated to a language used for PL research. That's neither here, nor there. Plus, I'm not sure what optimizing =<< and concatMap has to do regarding optimizing generics vs concrete behavior.
rntz 8y ago
Yes, compilers have gotten much better at optimising some forms of generic code over the past few decades. This is great! But it's not like the war is won. Staged, reactive, and incremental programming, for example, are still areas of very active research. Good implementations of these let us write code at a higher-level and yet avoid the interpretative overhead of evaluating them naively. Without such implementations people just perform the optimisations by hand (although they usually don't think of it this way) - a lot of imperative UI code is like this, for example. Who knows what the next frontier will be?

By that standard I seem to know only shitty compilers. Sorry to be blunt but you don't have a clue. As a rule of thumb, compilers can make a 10x difference (for example in machine code performance). Programmers can easily make a 1000x difference. Not even looking at algorithmic improvements.

coldtea 8y ago

http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler

wild_preference 8y ago
They're referring to monomorphization. Rust, for example: > You might be wondering whether there is a runtime cost when you’re using generic type parameters. The good news is that Rust implements generics in such a way that your code doesn’t run any slower using generic types than it would with concrete types. > Rust accomplishes this by performing monomorphization of the code that is using generics at compile time. Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when compiled.
- jstimpfle 8y ago
  Where do you get that monomorphization reference from? Let's assume for example you have a generic hash map where you just plug the type in, which must be hashable. Now if you plug in an integer type, monomorphization or whatever fancy compilation techniques will make that faster. But the best way to map an integer range is still a plain array. To put it in simple terms, compilers can make shit run faster, but they can't make it not shit.
  - tathougies 8y ago
    Hm... this seems like an incredibly poorly thought out example on your part. We've had C++ template specialization for decades. It is trivial to implement a map that uses hashes for non-integer types and an array for integer ones. This is 2018 after all.
    - deleted 8y ago
      [deleted]
    - jstimpfle 8y ago
      Specialized code is... not generic code, right? Furthermore template specialization is usually a bad idea. Think how we just LOVE std::vector<bool> (/s). Also std::unordered_map<int> is not specialized to an array implementation. Because you can't tell from the type whether it will map a contiguous range. I've done my homework. Your turn.
      - spenczar5 8y ago
        Yikes, I have no dog in this fight, but the level of sarcasm and meanness in your post ("Your turn.") just seems over the top for this argument. You'd be more convincing if you were more level, at least for me.
        jstimpfle 8y ago
        > incredibly poorly thought out example on your part But maybe you're right and I should have ignored it...
      - tathougies 8y ago
        It's absolutely generic. The code that uses the map would be indifferent to the type of key. The code that implements it is obviously different, because they are two separate implementations. It seems unlikely that you could have automatic specialized implementations without substantial improvements in AI.
  - alexhutcheson 8y ago
vmchale 8y ago
No, this is a completely standard compiler optimization. GHC already has it. Using (=<<) is not slower than concatMap on code you write today.
- coldtea 8y ago
  GHC is a compiler specially used for PL research, dedicated to a language used for PL research. That's neither here, nor there. Plus, I'm not sure what optimizing =<< and concatMap has to do regarding optimizing generics vs concrete behavior.

rntz 8y ago

Yes, compilers have gotten much better at optimising some forms of generic code over the past few decades. This is great! But it's not like the war is won. Staged, reactive, and incremental programming, for example, are still areas of very active research. Good implementations of these let us write code at a higher-level and yet avoid the interpretative overhead of evaluating them naively. Without such implementations people just perform the optimisations by hand (although they usually don't think of it this way) - a lot of imperative UI code is like this, for example. Who knows what the next frontier will be?