Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Energy Efficiency Across Programming Languages

sites.google.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Energy Efficiency Across Programming Languages

#111

Post by addHocker »

subwayclub wrote: post #92
mac01021 wrote: post #78

Earlier quoted context omitted.

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?

Basically, C's semantics assume too little - everything is a primitive type or a pointer dressed up to look like something else. Pascal has a stronger notion of types and this allows for additional automatic optimization where they're relevant - memory layout just happens to be one such area.

I miss the ability to pair structures as "antagonistic" - aka if one exists the other is not, thus allowing for unions of various datatypes who guarantee that if they exist- the shared memory they reside in is theirs and theirs alone.

Re: Energy Efficiency Across Programming Languages

#112

Post by pjmlp »

brlewis wrote: post #74
bbatha wrote: post #24

Earlier quoted context omitted.

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.

To the point that people used GC enabled systems programming languages to write full OSes[0], but as Joe Duffy puts on his last keynote, winning prejudice is an uphill battle.

[0]- Done at Xerox PARC, DEC/Olivetti, ETHZ, Erlangen, MSR

Re: Energy Efficiency Across Programming Languages

#113

Post by pjmlp »

winter_blue wrote: post #42

Note: The PDF of the paper has the a lot more detailed listing of the results (with graphs, explanation, etc) than the results web page: http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pape...

Only while printing it, I noticed my university name there! :)

Re: Energy Efficiency Across Programming Languages

#114

Post by Veedrac »

devveppev wrote: post #89
Veedrac wrote: post #88

Earlier quoted context omitted.

> The code guidelines in their benchmarks represent real programming practices in those languages. They promote "idiomatic" code because it is meant to represent the typical quality of code in the real world. This could not be further from my observations when I tried contributing. These results are neither controlled nor the result of idiomatic programs.

I'm talking about stuff like putting your code in classes, initializing with constructors, or using your language's standard library instead of writing your own stuff. Perhaps idiomatic was the wrong word. I mean that the code isn't supposed to be fighting the language. What were your observations when you were contributing? Which problems were you working on? Any chance you still have the code?

> I mean that the code isn't supposed to be fighting the language.

That's the issue: those programs that did best were those that fought the language the most, and those that pushed the closest to the edge of the rules. You can't, in general, look at two programs and assume they approach the problem the same way.

Re: Energy Efficiency Across Programming Languages

#115

Post by fasquoika »

andrewflnr wrote: post #83
fasquoika wrote: post #79

Earlier quoted context omitted.

Palatable how? Pascal's syntax is not especially different from that of most scripting languages

Every time I look at the syntax, it feels really verbose. IIRC some dialects require all caps or initial caps on keywords; at any rate that's how most examples are shown, and it's rather off-putting. Superficial, I know, but I'm probably not the only one.

I don't know about other implementations but FreePascal is completely case insensitive. Identifiers are actually treated the same if the only difference is case. I don't particularly like this, but I've never seen it actually be an issue

Re: Energy Efficiency Across Programming Languages

#116

Post by mncharity »

dom96 wrote: post #102
mncharity wrote: post #87

Earlier quoted context omitted.

@igouy points out that while the old shootout site is gone, its language files are still available[1]. There are about 70 benchmarks, in about 70 languages. I remember them as interesting multilingual browsing. Unlike the old shootout, adding languages directly to benchmarksgame.alioth.debian.org is not an option. "Because I know it will take more time than I choose. Been there; done that."[2] :) Instead, the code is…

It's a pity that the OP didn't include Nim despite benchmark files for it being available.

If a summary of the test data is/were machine readable in the individual language repos, perhaps one could create an automated aggregation? A distributed/federated version of the old shootout. One with lower maintenance requirements. bendmarksgame-results.json?

The data would be crufty, of limited comparability. But combining easily browsable links to colorized source code, with "just for a rough feel" speed relative to C, might be sufficient for the use case of raising language awareness - "What is this C-speed-like language I've never heard of? Oh, that looks pretty! I think I'll explore this language's web page..."

Or alternately, use the language files on github to create a new, broader benchmarksgame. That is, distribute the work of benchmark revisions and makefile compiler options, but keep the testing centralized. I've no idea of the relative costs of those tasks, or of others. But a continuous integration shootout sounds intriguing.

Re: Energy Efficiency Across Programming Languages

#117

Post by tyoverby »

int_19h wrote: post #73

I'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.

OCaml has an incredible optimizer, and many of the abstractions that one would use in OCaml are transparent to the optimizer.

You could say the opposite about Go.

Re: Energy Efficiency Across Programming Languages

#118

Post by jaawn »

topspin wrote: post #91
ram_rar wrote: post #9

I am curious to know, if there is any explanation for why java performs better than Go.

Two decades of optimization probably account for that. From the paper: Moreover, the top 5 languages that need less energy and time to execute the solutions are: C (57J, 2019ms), Rust (59J, 2103ms), C++ (77J, 3155ms), Ada (98J, 3740ms), and Java (114J, 3821ms); of these, only Java is not compiled. That is an admirable accomplishment. JRE 1.8 has the most efficient "managed" language runtime tested. The PHP result is…

The Java performance was the most interesting part of the results for me. I'm glad it got some attention. I have been developing the opinion for awhile that, as an industry, we've become far too avoidant of "pre-mature" optimization. It is astonishing to me how much slower a lot of this stuff is than Java.

Granted, I also think considering Java to be "not compiled" is a slight misrepresentation since it does get compiled to Java bytecode.

Re: Energy Efficiency Across Programming Languages

#119

Post by eeZah7Ux »

mncharity wrote: post #116
dom96 wrote: post #102

Earlier quoted context omitted.

It's a pity that the OP didn't include Nim despite benchmark files for it being available.

If a summary of the test data is/were machine readable in the individual language repos, perhaps one could create an automated aggregation? A distributed/federated version of the old shootout. One with lower maintenance requirements. bendmarksgame-results.json? The data would be crufty, of limited comparability. But combining easily browsable links to colorized source code, with "just for a rough feel" speed relative…

> A distributed/federated version of the old shootout

It would be wonderful but how do you ensure any form of hardware consistency?

Re: Energy Efficiency Across Programming Languages

#120

Post by igouy »

kcarnold wrote: post #7

I see they monitor a complete process lifetime, not just the active workload. A quick grep of the paper didn't turn up anything discussing this. And it would seem to hurt dynamic languages and runtime-JIT languages a lot. Perhaps the active workload takes long enough that the transient is washed out. Anyone have insights?

> Perhaps the active workload takes long enough that the transient is washed out.

That does seem to be the case with some-of the benchmarks game programs --

http://benchmarksgame.alioth.debian.org/sometimes-people-jus...

Post reply on HN