7 ms·

Languages that only support immutable data types, like some functional languages, typically can't use object pools, or if you can underneath the hood there's lo

Languages that only support immutable data types, like some functional languages, typically can't use object pools, or if you can underneath the hood there's lots of copying going on that simulates object pools. Having said that good lockless implementations along with good use of the right data structures can eliminate some or all of the data bus overhead (depending on the data types and uses). RCU[0] is one such example of single object immutability that in effect allows for mutable data structures that can handle multi-threaded environments at scale. [0] https://en.wikipedia.org/wiki/Read-copy-update https://en.wikipedia.org/wiki/Read-copy-update

couchand 9y ago
OTOH, immutability affords many more opportunities for safe, precise liveness analysis, and the optimizations that can be performed based on this. Frequently functional compilers produce highly mutative output from immutable inputs. After all, isn't the purpose of a compiler to strip away a level of abstraction? Sure, you can't explicitly use an object pool, but a Sufficiently Advanced Compiler could do a better job anyway.
- zaarn 9y ago
  A "Sufficiently Advanced Compiler" is probably a magical pipedream though. No compiler has precognition or is directly cabled into the developers brain (Though I wish it was) to tell what they want to express. The compiler might not be able to tell a preallocation is worth the effort if it cannot determine how often a function is called. Preallocs waste some startup time on the first time compared to dynamically allocating on the stack or heap and throwing away afterwards and also leaks memory. The compiler would have to be able to tell wether or not a function will be called often and is timing sensitive or whether it is called rarely and latency doesn't matter or any of the millions of variation in the spectrum between those two extremes. A perfect compiler would have to (essentially) solve the halting problem by being able to tell how programs will behave all the time.
  - monsieurbanana 9y ago
    A perfect compiler would compile natural languages to computer instructions. AKA the real "sudo make me a better facebook".
    - MaxBarraclough 9y ago
      Not really. Natural language isn't anywhere near as precise as programming language code. Some programming languages permit different implementations to behave differently (argument evaluation order in C for example), but natural language is a whole different league. What you describe would be an extremely impressive AI system, but I wouldn't call it a compiler. There's an XKCD for everything: https://xkcd.com/568/ https://xkcd.com/568/
      - bdamm 9y ago
        Indeed. At that level you might as well just order "Go make me some money." and the problem is that everyone else has that tool, too.
  - tankenmate 9y ago
    Go in effect does pre-allocs in that it does variable liveness analysis and any variables that are allocated within a function but who's address isn't assigned to another variable that is from outside the function or returned from the function is allocated on the stack. This means it is automatically freed when the function returns (or stack frame is unwound). This also means that you can be certain that any state changes are from within the current function or any of its children if passed to a child.
    - weberc2 9y ago
      Yeah, I know this optimization as escape analysis, but it's pretty easily defeated IIRC. I don't think it even applies across compilation units. In some ways, it's nice that the escape analysis is naive--it makes it easy to reason about and it behaves somewhat intuitively; however, in other cases it means unnecessary allocations.
- weberc2 9y ago
  I'd like to know more about this. I would think that the constraints afforded by functional languages would allow lots of awesome compiler optimizations that make relatively naive functional programs quite a bit faster than relatively naive imperative programs, but I often see imperative languages like Go outperform languages like Haskell and I'm not sure why. Also, reasoning about performance in Go is quite a bit easier than reasoning about Haskell, probably because the optimizations are more straightforward. These differences are particularly interesting to me because I'm building a toy functional language that compiles to Go.
  - fasquoika 9y ago
    If you want reliable performance, you should look at functional languages besides Haskell. Off the top of my head I'd say that Chez Scheme, OCaml, and MLton are all probably faster than Go
    - weberc2 9y ago
      In my experience, OCaml seems to perform worse than Go in most interesting singlethreaded cases, and obviously it completely lacks a good parallelism story. I can't speak to Chez Scheme or MLton, but I may check them out in the future. Thanks for the recommendation!
      - ernst_klim 9y ago
        >OCaml seems to perform worse than Go in most interesting singlethreaded cases Could you provide an example?

couchand 9y ago

OTOH, immutability affords many more opportunities for safe, precise liveness analysis, and the optimizations that can be performed based on this. Frequently functional compilers produce highly mutative output from immutable inputs. After all, isn't the purpose of a compiler to strip away a level of abstraction? Sure, you can't explicitly use an object pool, but a Sufficiently Advanced Compiler could do a better job anyway.

zaarn 9y ago
A "Sufficiently Advanced Compiler" is probably a magical pipedream though. No compiler has precognition or is directly cabled into the developers brain (Though I wish it was) to tell what they want to express. The compiler might not be able to tell a preallocation is worth the effort if it cannot determine how often a function is called. Preallocs waste some startup time on the first time compared to dynamically allocating on the stack or heap and throwing away afterwards and also leaks memory. The compiler would have to be able to tell wether or not a function will be called often and is timing sensitive or whether it is called rarely and latency doesn't matter or any of the millions of variation in the spectrum between those two extremes. A perfect compiler would have to (essentially) solve the halting problem by being able to tell how programs will behave all the time.
- monsieurbanana 9y ago
  A perfect compiler would compile natural languages to computer instructions. AKA the real "sudo make me a better facebook".
  - MaxBarraclough 9y ago
    Not really. Natural language isn't anywhere near as precise as programming language code. Some programming languages permit different implementations to behave differently (argument evaluation order in C for example), but natural language is a whole different league. What you describe would be an extremely impressive AI system, but I wouldn't call it a compiler. There's an XKCD for everything: https://xkcd.com/568/ https://xkcd.com/568/
    - bdamm 9y ago
      Indeed. At that level you might as well just order "Go make me some money." and the problem is that everyone else has that tool, too.
- tankenmate 9y ago
  Go in effect does pre-allocs in that it does variable liveness analysis and any variables that are allocated within a function but who's address isn't assigned to another variable that is from outside the function or returned from the function is allocated on the stack. This means it is automatically freed when the function returns (or stack frame is unwound). This also means that you can be certain that any state changes are from within the current function or any of its children if passed to a child.
  - weberc2 9y ago
    Yeah, I know this optimization as escape analysis, but it's pretty easily defeated IIRC. I don't think it even applies across compilation units. In some ways, it's nice that the escape analysis is naive--it makes it easy to reason about and it behaves somewhat intuitively; however, in other cases it means unnecessary allocations.
weberc2 9y ago
I'd like to know more about this. I would think that the constraints afforded by functional languages would allow lots of awesome compiler optimizations that make relatively naive functional programs quite a bit faster than relatively naive imperative programs, but I often see imperative languages like Go outperform languages like Haskell and I'm not sure why. Also, reasoning about performance in Go is quite a bit easier than reasoning about Haskell, probably because the optimizations are more straightforward. These differences are particularly interesting to me because I'm building a toy functional language that compiles to Go.
- fasquoika 9y ago
  If you want reliable performance, you should look at functional languages besides Haskell. Off the top of my head I'd say that Chez Scheme, OCaml, and MLton are all probably faster than Go
  - weberc2 9y ago
    In my experience, OCaml seems to perform worse than Go in most interesting singlethreaded cases, and obviously it completely lacks a good parallelism story. I can't speak to Chez Scheme or MLton, but I may check them out in the future. Thanks for the recommendation!
    - ernst_klim 9y ago
      >OCaml seems to perform worse than Go in most interesting singlethreaded cases Could you provide an example?