4 ms·

- Generics do not make runtime performance slow, but it sure does make compile times slower (although it really depends on the type system and its implememtatio

- Generics do not make runtime performance slow, but it sure does make compile times slower (although it really depends on the type system and its implememtation) For example, C++ templates, although very powerful, makes build times order of magnitudes slow when used poorly. One of the most important features of Go is its fast compile times, but generics/contracts can potentially slow it down a lot. - Yes, being a dynamic language slows it down a lot. For example, when evaluating a+b, the interpreter has to check the types of the variables a and b at runtime beform performing the right form of addition (it might be an int, or a string, you dont know). Even with JIT (just in time compilation) the compiler has to initially “guess” that the variables are numbers, and fall back if that is not the case. Statically typed languages do not have this problem, because you know the types of variables beforehand at compile time. By the way, Nim is not a dynamic language. And LuaJIT is one of the the fastest dynamic language implementations because the language is very simplistic (compared to Javascript/Python/Ruby) and Mike Pall is a robot from the future...

shakna 8y ago
> the interpreter has to check the types of the variables a and b at runtime beform performing the right form of addition (it might be an int, or a string, you dont know) That's not necessarily true. In Scheme, a very dynamic language, the compiler will generally make choices about memory layout of the various values before launching into the evaluation phase. Where safe or possible to do so, it will probably reduce the number of choices that will have to be made at runtime, at compile time. The interpreter may not have to lookup what the data type is, because it may just have two bits of memory and an instruction to call. You can know what the data will be, and optimise for it. [0] There's no reason that: b = 1; c = 2; a = a + b needs to be slower than a = 1 + 2 if b and c are never referenced before or after. But in Python, it is, because the design makes it harder to know whether or not an object should get optimised away. > And LuaJIT is one of the the fastest dynamic language implementations because the language is very simplistic Right, Lua is dynamic, and one of the design choices was making it simple, and so it's easier to make it faster. [0] http://home.pipeline.com/~hbaker1/CheneyMTA.html http://home.pipeline.com/~hbaker1/CheneyMTA.html
- lasagnaphil 8y ago
  Didn't know about Scheme. Thanks for the link!
  - shakna 8y ago
    If you've never met Scheme, then SICP [0, 1, 2] may be something that can change the way you program. It certainly made me better, or at least a deeper understanding. [0] https://www.youtube.com/watch?v=2Op3QLzMgSY&list=PLE18841CABEA24090 https://www.youtube.com/watch?v=2Op3QLzMgSY&list=PLE18841CAB... [1] https://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262510871 https://www.amazon.com/Structure-Interpretation-Computer-Pro... [2] https://web.mit.edu/alexmv/6.037/sicp.pdf https://web.mit.edu/alexmv/6.037/sicp.pdf

shakna 8y ago

> the interpreter has to check the types of the variables a and b at runtime beform performing the right form of addition (it might be an int, or a string, you dont know) That's not necessarily true. In Scheme, a very dynamic language, the compiler will generally make choices about memory layout of the various values before launching into the evaluation phase. Where safe or possible to do so, it will probably reduce the number of choices that will have to be made at runtime, at compile time. The interpreter may not have to lookup what the data type is, because it may just have two bits of memory and an instruction to call. You can know what the data will be, and optimise for it. [0] There's no reason that: b = 1; c = 2; a = a + b needs to be slower than a = 1 + 2 if b and c are never referenced before or after. But in Python, it is, because the design makes it harder to know whether or not an object should get optimised away. > And LuaJIT is one of the the fastest dynamic language implementations because the language is very simplistic Right, Lua is dynamic, and one of the design choices was making it simple, and so it's easier to make it faster. [0] http://home.pipeline.com/~hbaker1/CheneyMTA.html http://home.pipeline.com/~hbaker1/CheneyMTA.html

lasagnaphil 8y ago
Didn't know about Scheme. Thanks for the link!
- shakna 8y ago
  If you've never met Scheme, then SICP [0, 1, 2] may be something that can change the way you program. It certainly made me better, or at least a deeper understanding. [0] https://www.youtube.com/watch?v=2Op3QLzMgSY&list=PLE18841CABEA24090 https://www.youtube.com/watch?v=2Op3QLzMgSY&list=PLE18841CAB... [1] https://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262510871 https://www.amazon.com/Structure-Interpretation-Computer-Pro... [2] https://web.mit.edu/alexmv/6.037/sicp.pdf https://web.mit.edu/alexmv/6.037/sicp.pdf