Higher-level scripting languages. Fast for programmer's time, slow for run times.
Energy Efficiency Across Programming Languages
61–70 of 143 posts
Re: Energy Efficiency Across Programming Languages
#62Earlier quoted context omitted.
> Those benchmarks don't reflect real-world workloads at all… That's a very definite claim, for which you provide no supporting evidence ;-)
One of the worst offenders is probably the binary-trees benchmark. 1. It features an atypically high allocation rate compared to real-world programs. 2. As a synthetic micro benchmark that only ever allocates objects of one size, it makes pool allocators look disproportionately good. But in real-world applications with varying object sizes, overuse of pool allocators creates a serious risk for fragmentation. 3. The r…
> The rules allow programs that use manual memory management to…
And still there's outrage that programs with allocators custom-written for binary-trees are rejected :-)
Re: Energy Efficiency Across Programming Languages
#63Earlier quoted context omitted.
> Those benchmarks don't reflect real-world workloads at all… That's a very definite claim, for which you provide no supporting evidence ;-)
One of the worst offenders is probably the binary-trees benchmark. 1. It features an atypically high allocation rate compared to real-world programs. 2. As a synthetic micro benchmark that only ever allocates objects of one size, it makes pool allocators look disproportionately good. But in real-world applications with varying object sizes, overuse of pool allocators creates a serious risk for fragmentation. 3. The r…
> It features an atypically high allocation rate compared to real-world programs.
Do you have any supporting evidence for this? Real-world programs can be pretty allocation heavy, and if anything high allocation rates would "unfairly" benefit GC languages since native programs are banned from using arena allocators.
> As a synthetic micro benchmark that only ever allocates objects of one size, it makes pool allocators look disproportionately good. But in real-world applications with varying object size, overuse of pool allocators is a serious risk for fragmentation.
Huh? It's so incredibly common in the real-world for a structure to be of a single type that pretty much every language makes that first-class supported via templates.
And since they are single-size there's no risk of fragmentation at all. Indeed object pools are typically how you avoid fragmentation, they are not things that cause it. So I'm not sure what you're trying to get at with that comment.
> The rules allow programs that use manual memory management to use pretty much any pool allocator library that they can get their hand on, but forbid garbage-collected languages from adjusting their GC parameters (last I checked, you could easily improve the performance of OCaml and Dart for that benchmark by a factor of 2-3 simply by adjusting GC settings, especially the size of the nursery).
Last I checked if I write a Dart library I can't adjust the GC settings in my library to make my library run better, either, but if I ship a C++ library I can absolutely use a pool allocator to make my library run better (and indeed this is exactly what real libraries do)
So I'd call this a good rule, and allowing tweaking of GC parameters would be more about trying to over-tune the runtime to the benchmark rather than the benchmark illustrating what is feasible to achieve in the language as a library or as part of a larger system.
Re: Energy Efficiency Across Programming Languages
#64One wonders how Kotlin (or other popular JVM languages) would compare. And also Objective-C or Smalltalk.
Re: Energy Efficiency Across Programming Languages
#65Earlier quoted context omitted.
The tests come from the benchmark game. If you want to see Forth, implement the tests in Forth: http://benchmarksgame.alioth.debian.org/
> The tests come from the benchmark game. If you want to see Forth, implement the tests in Forth: But perhaps archive your code elsewhere. Github? Lots of language communities participated in past versions of the game. Like gforth and bigforth on shootout.alioth.debian.org circa 2008. Now it seems little remains but a few archive.org snapshots without source. Though perhaps all of that code was archived somewhere els…
[deleted]
Re: Energy Efficiency Across Programming Languages
#66Earlier quoted context omitted.
> 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.
Maybe somebody needs to create a more palatable language, that'll transpile (I know, I know, compile) into pascal?
Re: Energy Efficiency Across Programming Languages
#67So the moral of this story is that if you need to fix a bottleneck in the real world, you mainly use erlang then drop into C (port/nif) where necessary?
Re: Energy Efficiency Across Programming Languages
#68Re: Energy Efficiency Across Programming Languages
#69Earlier quoted context omitted.
> 5. I wonder which implementation of Lua they used. There is a table with the versions they used¹, but they don't mention the implementation – in can be inferred for some: e.g. for Pascal they used the Free Pascal Compiler. ① - https://sites.google.com/view/energy-efficiency-languages/se...
Ouch, they used Lua 5.3 LuaJIT is at least an order of magnitude(10x) faster.
To the point where a lot of popular libraries (like Love2D) use LuaJIT by default. IIRC, Lapis (Lua-based web framework) can be easily configured for it as well.
I'd be interested in seeing how it fared; Lua really is a nice language.
Re: Energy Efficiency Across Programming Languages
#70Earlier quoted context omitted.
"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.
Maybe somebody needs to create a more palatable language, that'll transpile (I know, I know, compile) into pascal?
This guys made a pascal-like language:
http://www.elementscompiler.com/elements/oxygene/
Exist various dialects of pascal (Modula, Oberon, etc) so is not something so far in the wind.
But if you lose too much of the syntax you remove part of the charm.