5 ms·

Pony Performance Cheatsheet

98 points by spooneybarger 9y ago

CJefferson 9y ago
I'm disappointed (in pony) that one suggest is to use tuple instead of a class, and in general avoid naking little clases. One often overlooked benefit of c++ (and I am sure other langyages) is that I can wrap one or two ints in a class, add some constructors and little member functions, and be fairly confident the whole lot will get inlined and compiled away.
- trishume 9y ago
  Indeed, this is a good document for Pony (and a lot applies to other languages like OCaml as well!) but it shows what programming in a language like Rust or C++ that has many zero-cost abstractions gets you. In Rust I can always use wrappers, aliases and union types, and idiomatic error handling. And since the abstractions are either zero-overhead or will reliably be optimized away by LLVM, I don't have to worry about sacrificing performance.
  - pjmlp 9y ago
    This is not 100% true, just see the efforts of Google in optimizing string allocation on Chrome. Just because a language offers zero-cost abstractions, doesn't mean performance comes for free, one needs to know how to use them properly. And be clever to chose libraries that are also designed with performance in mind.
    - srean 9y ago
      I would say std::string and std::io are special cases and somewhat atypical. Both have large performance overheads. I think the standardization committee blessed existing implementationsite that had become popular rather than design one with performance in mind. Strings really ought to have been immutable by default.
    - nine_k 9y ago
      In Rust or C++, you can make the abstractions zero-cost with some effort. I'm many other languages, you can't, no matter the effort.
      - pjmlp 9y ago
        Yes, but that "some effort" also has a development cost, which might be worthwhile or not, depending on the use case. Going a bit off-thread, Ada, Object Pascal, Active Oberon, D, Nim, Modula-3, Swift also offer such capabilities. C# also has on their roadmap plans to adopt more features from System C# and Midori, specially when coupled with .NET Native and CoreRT.
- vanderZwan 9y ago
  That's a bit of an apples to oranges comparison since class in pony isn't a class in C++. It's an actor, with all of the machinery that this entails.
  - mkishi 9y ago
    Classes and Actors are two different things in Pony.
    - vanderZwan 9y ago
      My apologies, I just checked and you're right. I remembered wrongly. Sadly it's too late to edit the comment above
bhauer 9y ago
This is a great summery of performance-oriented tips that in many cases are generally applicable, even beyond the specific context of Pony.
infradig 9y ago
I only got as far the string concatenation example. That languages like Pony, C++ and no doubt many others, make programmers go through these performance hoops for common-case scenarios is unfortunate.
- rhencke 9y ago
  This is being added as an optimization: Some of you probably looked at the String performance enhancement above and thought, “doesn’t the JVM do that for you?” You’d be right. That’s a standard optimization in many languages. It’s an optimization we are adding to Pony. However, the basic pattern applies. Be aware of triggering extra allocations that you don’t need to. Your compiler and runtime can add many optimizations to avoid allocations, but it’s not going to do everything for you. You still need to understand your allocations. They’re called “your allocations” because in the end, you end up owning them and they end up owning your performance.
  - infradig 9y ago
    Great. Sorry for not reading further.
- beagle3 9y ago
  The problem is inherent in the imperative style. The programmer SPECIFICALLY ASKED for all the partial results, and it turns out that doing what was asked is sub-optimal, to the tune of O(n) allocations of O(n) each and O(n^2) runtime as opposed to the optimal O(1) allocations of O(n), and O(n) runtime. It is extremely hard to make the compiler transform the sub-optimal version to the optimal one in the general case. Sure, one can special case strings (or std::string, or whatever) and do that without changing the semantics -- Python, for example, does that with string appends. However, none of Python, C++ or Rust will do that for a user-defined type. The right thing is to make sure that idiomatic way to concatenate strings is, in fact, efficient - Python does that by making the idiom "seperator.join(string_list)", which is as efficient as it can be. There's a lot of performance gains to be made by transforming unreasonable code to reasonable code, which is why compilers still do it; and unreasonable code just as often results from mountains of abstractions as it does from programmer unawareness. But IMHO our goal should be that the norm is that programmers are expected to write reasonable code, not that compilers are able to optimize unreasonable code.
panic 9y ago
They talk about profiling at the end -- it would be nice to see numbers for how much faster or slower each of the code snippets is. It's hard to tell how much you should care about "boxing machine words", for example, especially when the faster version makes your code less maintainable. Is this only something to worry about if you have millions of items in your array?
nerdponx 9y ago
This sounds like a good argument for having macros in the language. Also, how hard is it for the compiler to optimize these cases? Why are they zero-cost in C++ and not in Pony?
df388dfsa8f9 9y ago
It's really disappointing that something as simple as a string concatenation expression `a + ":" + b` has to be replaced with a pre-allocating monstrosity. This is the kind of thing that a modern language should be able to optimize at compile time. Surely doesn't make for a good impression of the language.

98 points by spooneybarger 9y ago

I'm disappointed (in pony) that one suggest is to use tuple instead of a class, and in general avoid naking little clases. One often overlooked benefit of c++ (and I am sure other langyages) is that I can wrap one or two ints in a class, add some constructors and little member functions, and be fairly confident the whole lot will get inlined and compiled away.

trishume 9y ago
Indeed, this is a good document for Pony (and a lot applies to other languages like OCaml as well!) but it shows what programming in a language like Rust or C++ that has many zero-cost abstractions gets you. In Rust I can always use wrappers, aliases and union types, and idiomatic error handling. And since the abstractions are either zero-overhead or will reliably be optimized away by LLVM, I don't have to worry about sacrificing performance.
- pjmlp 9y ago
  This is not 100% true, just see the efforts of Google in optimizing string allocation on Chrome. Just because a language offers zero-cost abstractions, doesn't mean performance comes for free, one needs to know how to use them properly. And be clever to chose libraries that are also designed with performance in mind.
  - srean 9y ago
    I would say std::string and std::io are special cases and somewhat atypical. Both have large performance overheads. I think the standardization committee blessed existing implementationsite that had become popular rather than design one with performance in mind. Strings really ought to have been immutable by default.
  - nine_k 9y ago
    In Rust or C++, you can make the abstractions zero-cost with some effort. I'm many other languages, you can't, no matter the effort.
    - pjmlp 9y ago
      Yes, but that "some effort" also has a development cost, which might be worthwhile or not, depending on the use case. Going a bit off-thread, Ada, Object Pascal, Active Oberon, D, Nim, Modula-3, Swift also offer such capabilities. C# also has on their roadmap plans to adopt more features from System C# and Midori, specially when coupled with .NET Native and CoreRT.
vanderZwan 9y ago
That's a bit of an apples to oranges comparison since class in pony isn't a class in C++. It's an actor, with all of the machinery that this entails.
- mkishi 9y ago
  Classes and Actors are two different things in Pony.
  - vanderZwan 9y ago
    My apologies, I just checked and you're right. I remembered wrongly. Sadly it's too late to edit the comment above

bhauer 9y ago

This is a great summery of performance-oriented tips that in many cases are generally applicable, even beyond the specific context of Pony.

infradig 9y ago

I only got as far the string concatenation example. That languages like Pony, C++ and no doubt many others, make programmers go through these performance hoops for common-case scenarios is unfortunate.

rhencke 9y ago
This is being added as an optimization: Some of you probably looked at the String performance enhancement above and thought, “doesn’t the JVM do that for you?” You’d be right. That’s a standard optimization in many languages. It’s an optimization we are adding to Pony. However, the basic pattern applies. Be aware of triggering extra allocations that you don’t need to. Your compiler and runtime can add many optimizations to avoid allocations, but it’s not going to do everything for you. You still need to understand your allocations. They’re called “your allocations” because in the end, you end up owning them and they end up owning your performance.
- infradig 9y ago
  Great. Sorry for not reading further.
beagle3 9y ago
The problem is inherent in the imperative style. The programmer SPECIFICALLY ASKED for all the partial results, and it turns out that doing what was asked is sub-optimal, to the tune of O(n) allocations of O(n) each and O(n^2) runtime as opposed to the optimal O(1) allocations of O(n), and O(n) runtime. It is extremely hard to make the compiler transform the sub-optimal version to the optimal one in the general case. Sure, one can special case strings (or std::string, or whatever) and do that without changing the semantics -- Python, for example, does that with string appends. However, none of Python, C++ or Rust will do that for a user-defined type. The right thing is to make sure that idiomatic way to concatenate strings is, in fact, efficient - Python does that by making the idiom "seperator.join(string_list)", which is as efficient as it can be. There's a lot of performance gains to be made by transforming unreasonable code to reasonable code, which is why compilers still do it; and unreasonable code just as often results from mountains of abstractions as it does from programmer unawareness. But IMHO our goal should be that the norm is that programmers are expected to write reasonable code, not that compilers are able to optimize unreasonable code.

panic 9y ago

They talk about profiling at the end -- it would be nice to see numbers for how much faster or slower each of the code snippets is. It's hard to tell how much you should care about "boxing machine words", for example, especially when the faster version makes your code less maintainable. Is this only something to worry about if you have millions of items in your array?

nerdponx 9y ago

This sounds like a good argument for having macros in the language. Also, how hard is it for the compiler to optimize these cases? Why are they zero-cost in C++ and not in Pony?

df388dfsa8f9 9y ago

It's really disappointing that something as simple as a string concatenation expression `a + ":" + b` has to be replaced with a pre-allocating monstrosity. This is the kind of thing that a modern language should be able to optimize at compile time. Surely doesn't make for a good impression of the language.