Rust is fairly competitive with C, but it's memory use was 50 percent higher. I bet if they focus on getting the memory usage down it will perform better too.
Energy Efficiency Across Programming Languages
71–80 of 143 posts
Re: Energy Efficiency Across Programming Languages
#72Earlier quoted context omitted.
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 allocator…
> Do you have any supporting evidence for this?
For starters, by virtue of the construction of the benchmark alone, which mostly is about stress-testing allocation.
There are also quite a few papers that benchmark allocators, such as [1], where you can see that such allocation rates aren't exactly ordinary.
> Real-world programs can be pretty allocation heavy,
I said "atypical", not "impossible". Obviously, I can construct real-world programs with pretty much arbitrary allocation rates, but especially performance-sensitive code will avoid that, if only because it hurts memory locality.
> and if anything high allocation rates would "unfairly" benefit GC languages since native programs are banned from using arena allocators.
My point is that this apples vs. oranges, no matter how you cut it. I don't want one side to "win", I want results that are good science.
> 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.
That sentence doesn't make sense, unless you live in a world where C++ is the only programming language (because templates are pretty much C++-specific).
> And since they are single-size there's no risk of fragmentation at all.
Simple example: A program alternates between allocating objects of size N (and then freeing most, but not all of them) and allocating objects of size M (and then freeing most, but not all of them). Worst case means that one object per block is enough to keep an entire block alive.
The concern here is long-running programs: if you have high allocation rates, you also have frequent deallocations (or the program eventually stops allocating).
> 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)
And instead you could tune the final application; allocation tuning is often a non-local concern. Apples and oranges again.
Importantly, you seem to be mistaking this for a tribal argument (the GC tribe vs. the manual memory management tribe), whereas my point is simply that the benchmark is bad and tries to compare incomparable things.
Re: Energy Efficiency Across Programming Languages
#73I'm kinda surprised to see Go score so low on some of these, given that it's AOT-compiled to native code, and that its memory model and safety guarantees are optimization-friendly.
I'm also kinda surprised that OCaml scored that high, considering how high-level it is.
Re: Energy Efficiency Across Programming Languages
#74Earlier quoted context omitted.
Not really. "Manual" memory allocation is usually malloc/free, which leaves a lot of gaps.
Go's garbage collector isn't compacting.
My point wasn't that garbage collection is more efficient than people think, but that "manual" memory allocation is less efficient than people think.
Re: Energy Efficiency Across Programming Languages
#75Considering most CPU cores (Arm/X86/etc) are optimized for C/GCC its an unsurprising result
Can someone elaborate. I always thought that the compiler was optimized for the architecture, not the other way around. Why would an architecture be optimized for a specific compiler?
Re: Energy Efficiency Across Programming Languages
#76I'd love to see some scatter plots of CPU-time and energu-time, I expected a fairly linear correlation but there looks to be quite a lot of outliers, some but not all are explained with parallelism. Memory seems all over the place too.
Re: Energy Efficiency Across Programming Languages
#77I have just started looking into Ada and it is cool to see up there with C. Does anyone know a good resource for writing fast Ada?
Re: Energy Efficiency Across Programming Languages
#78According 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...
But why should it's memory utilization be so much lower?
Pascal and C give the programmer basically the same control over memory layout, no?
Re: Energy Efficiency Across Programming Languages
#79Earlier 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?
Palatable how? Pascal's syntax is not especially different from that of most scripting languages
Re: Energy Efficiency Across Programming Languages
#80Earlier 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 ;-)
Maybe we could get away with a couple smaller claims: - It would be weird to expect programs specifically optimized for a performance benchmark, to also be optimal for energy usage or memory. Maybe less weird for energy, if runtime is the biggest factor in how much energy gets used. But I'd expect there to be huge tradeoffs between runtime and memory usage, once we start really optimizing for memory. - Running the Be…
Perhaps I'm over simplifying to the point of making mistakes, but intuitively I would expect that performance and Energy Efficiency are strongly correlated, because I assume that each instruction executed takes a certain amount of time and a certain amount of energy, and that this skills roughly linearly. That is, executing n instructions takes A * n time and B * n energy, so of course making it finish sooner means less instructions means less energy.