I can't believe they used the Computer Language Benchmarks Game. Those benchmarks don't reflect real-world workloads at all, and the contest has fairly arbitrary rules about implementations and widely differing implementation quality between languages. This should have been rejected by peer review.
Energy Efficiency Across Programming Languages
11–20 of 143 posts
Re: Energy Efficiency Across Programming Languages
#12Why is TypeScript so much less efficient than JavaScript?
Re: Energy Efficiency Across Programming Languages
#13According to their normalized "global" results, something interesting i see: 1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used. 2. Rust a good alternative to C which leads in "energy efficiency" and speed. 3. Common Lisp most energy-efficient and fastest and smallest memory footprint of all the dynamic programming languages in the list -- like Python, Ruby…
> 1. Pascal
Pascal is a "hidden" gem in the area of languages. Sadly not enough pus for it, but imagine if it have the push that other languages have...
Re: Energy Efficiency Across Programming Languages
#14I am curious to know, if there is any explanation for why java performs better than Go.
20 years of optimizing tends to do this
Re: Energy Efficiency Across Programming Languages
#15So go (a garbage collected language) is about as memory efficient as pascal, the most memory efficient language. That comes surprising.
Re: Energy Efficiency Across Programming Languages
#16According to their normalized "global" results, something interesting i see: 1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used. 2. Rust a good alternative to C which leads in "energy efficiency" and speed. 3. Common Lisp most energy-efficient and fastest and smallest memory footprint of all the dynamic programming languages in the list -- like Python, Ruby…
> 1. Pascal Pascal is a "hidden" gem in the area of languages. Sadly not enough pus for it, but imagine if it have the push that other languages have...
Now I need to finish my lisp.pas
Re: Energy Efficiency Across Programming Languages
#17According to their normalized "global" results, something interesting i see: 1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used. 2. Rust a good alternative to C which leads in "energy efficiency" and speed. 3. Common Lisp most energy-efficient and fastest and smallest memory footprint of all the dynamic programming languages in the list -- like Python, Ruby…
Imaging if the world ran on SBCL instead :)
Re: Energy Efficiency Across Programming Languages
#18According to their normalized "global" results, something interesting i see: 1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used. 2. Rust a good alternative to C which leads in "energy efficiency" and speed. 3. Common Lisp most energy-efficient and fastest and smallest memory footprint of all the dynamic programming languages in the list -- like Python, Ruby…
> 1. Pascal Pascal is a "hidden" gem in the area of languages. Sadly not enough pus for it, but imagine if it have the push that other languages have...
"Pascal is a "hidden" gem in the area of languages"
I agree. Programmers won't look at it because they perceive it to be old and out-of-date. But the language hasn't stood still. It's a fast, low-memory language. FreePascal with the Lazarus IDE is one of the best cross-platform development toolkits for building native desktop apps.
Sadly a lot of programmers can never see beyond the verbose (but readable) syntax.
Re: Energy Efficiency Across Programming Languages
#19So go (a garbage collected language) is about as memory efficient as pascal, the most memory efficient language. That comes surprising.
Not really. "Manual" memory allocation is usually malloc/free, which leaves a lot of gaps.
Re: Energy Efficiency Across Programming Languages
#20I can't believe they used the Computer Language Benchmarks Game. Those benchmarks don't reflect real-world workloads at all, and the contest has fairly arbitrary rules about implementations and widely differing implementation quality between languages. This should have been rejected by peer review.
> Those benchmarks don't reflect real-world workloads at all…
That's a very definite claim, for which you provide no supporting evidence ;-)