3 ms·

Yes! Also, even when you do care about performance, general performance isn't ever the same as specific performance. You have to optimise to your use case, not

by angusgr 15y ago

Yes! Also, even when you do care about performance, general performance isn't ever the same as specific performance. You have to optimise to your use case, not some arbitrary general use case like "render a Mandelbrot set" or "calculate pi". If I have a slow On^2 Erlang algorithm, then I'm a lot better off looking at ways to rewrite it as Olog(n) instead of scrapping Erlang and moving to Java because it had a better score on the programming language shootout.

igouy 15y ago
> general performance isn't ever the same as specific performance http://shootout.alioth.debian.org/dont-jump-to-conclusions.php http://shootout.alioth.debian.org/dont-jump-to-conclusions.p... > scrapping Erlang and moving to Java "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic." http://www.erlang.org/faq/introduction.html#id49850 http://www.erlang.org/faq/introduction.html#id49850
- angusgr 15y ago
  Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic. I know, when programming in Erlang I have unsurprisingly done exactly this. If I had an On^2 solution in Erlang that I knew I couldn't rewrite in Erlang to be faster, then that's my last resort - I'd write a C port to perform my particular inner loop performance-limited code, and leave the rest in Erlang. However, I wouldn't either (a) go directly to C without trying to optimise the solution in Erlang first, or (b) look at a list of other languages and wonder which one I could move my entire program to.

by angusgr 15y ago

igouy 15y ago

> general performance isn't ever the same as specific performance http://shootout.alioth.debian.org/dont-jump-to-conclusions.php http://shootout.alioth.debian.org/dont-jump-to-conclusions.p... > scrapping Erlang and moving to Java "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic." http://www.erlang.org/faq/introduction.html#id49850 http://www.erlang.org/faq/introduction.html#id49850

angusgr 15y ago
Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic. I know, when programming in Erlang I have unsurprisingly done exactly this. If I had an On^2 solution in Erlang that I knew I couldn't rewrite in Erlang to be faster, then that's my last resort - I'd write a C port to perform my particular inner loop performance-limited code, and leave the rest in Erlang. However, I wouldn't either (a) go directly to C without trying to optimise the solution in Erlang first, or (b) look at a list of other languages and wonder which one I could move my entire program to.