Live data from Hacker News

Which Programming Languages Use the Least Electricity? (2018)

thenewstack.io

221–230 of 267 posts

Re: Which Programming Languages Use the Least Electricity? (2018)

#221
post #195

Earlier quoted context omitted.

Using continuations. The function call itself and the local scope wrapped up into it can be varying degrees of expensive. When little state, because it’s inline or nearby for example, it might be optimized down to near what a for loop does. But if there’s a function call at all once it’s executed, that alone is slower than the for loop. Remember it’s a function call per element. If the function is further away with m…

If I modify that code to pre-initialise an array with the values 0 to N - 1, and then copy the value from that array to a new array (rather than using the loop index), then both map and forEach are faster than the for loop for me.

That sounds fairly surprising, considering map has to allocate, and allocate is very expensive, but please share your code & I’ll try it.

Like so?

    const N = 1000000
    let a = new Array(N), b = new Array(N)
    for (let i = 0; i  { for (var i = 0; i  { b = a.map((x,i) => a[i]) })
    test('copy forEach', _=> { a.forEach((v,i,a) => b[i] = a[i]) })
I get: copy loop 973, copy map 38, copy forEach 49. Same as before, but this time I tried Chrome in Windows.

Are you using a different browser? I know that sometimes other browsers have very different results.

In any case, it's somewhat irrelevant if there are cases that optimize and cases that don't. When idiomatic functional code is sometimes up to 30x slower than a for loop, it can't be used in perf critical sections. Even if it's only Chrome and only certain cases. The forEach perf needs to be always reliably performant before I can use it without worry.

Re: Which Programming Languages Use the Least Electricity? (2018)

#222

Earlier quoted context omitted.

Not sure why you picked on Java though. As per this study, Java is doing better than both of them. So at least if the goal is to improve on those, you need to look at Rust/C++/C/Ada.

I'm not trying to pick on it. But those languages are significantly harder to develop for. Go/Swift are trying to be general improvements that maintain and improve upon developer productivity while achieving great performance and efficient memory utilization (which if you look at the paper is one area Java is not necessarily great at).

Ada is not particularly difficult. It does suffer from a lack of tooling compared to some languages. It's a large language with many ways to do things and some dark corners. The same never stopped C++, Ruby, Perl, nor in its day PL/1. If you can learn C++ or Java then Ada is largely syntax changes, not wildly different semantics. If you know Pascal it's basically a huge extension with support for features like concurrency and pointers never standardized into Modula 2 or Pascal.

Re: Which Programming Languages Use the Least Electricity? (2018)

#223
post #201

Earlier quoted context omitted.

My best guess: probably written by someone that doeant know how to write performance TS. I say this with no skin in the game. I write neither JS nor TS. What I have observed in language benchmarks over the years, is that the benchmarks are rarely written by an expert, but usually by someone with cursory knowledge of the language. E.g. just enough to be dangerous. Often times, these sorts of benchmarks are done with p…

This is unfortunately pure speculation on top of pure speculation, which is the problem I have with the top comment. You’re assuming incompetence when you could just go look it up. Why assume it’s someone who doesn’t know? Why use that to wander off into rant land about prejudices and make broad claims that internet benchmarks are bad, when you admit to having zero idea what the actual specific problem here is? The t…

> Why use that to wander off into rant land about prejudices and make broad claims that internet benchmarks are bad

What are you talking about? Where did that happen?

> when you admit to having zero idea what the actual specific problem here is?

This is the comment section for a submission about an article referencing the paper. I brought it up for discussion. It is perfectly valid to bring up a question that you don't know the answer to.

> What is not obvious is any prejudice, malice, or incompetence.

Please stop.

Edit: From another comment, and some deeper digging of my own from that, you might find the archived results of the fannkuch-redux interesting. From 2017-08-01[1] to 2017-09-18[2], the benchmark changed from a running time of 1,204.93 second to a running time of 131.39 seconds. The paper was released in October 2017.

1: https://web.archive.org/web/20170901020804/http://benchmarks...

2: https://web.archive.org/web/20170918163900/http://benchmarks...

Re: Which Programming Languages Use the Least Electricity? (2018)

#224
post #91

Couple points (I've worked on app servers): 1- This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically reduce carbon footprint within 11 years. Efficiencies at the language level are one of biggest bangs for buck here. Just by redeploying, you can reduce energy consumption by perhaps double digits. Imagine how hard that is to do at the hardware or energy farm le…

I work in Swift on iOS. I think the "Swift on a server" idea is way over hyped. There are so many issues with the whole Swift stack adopting that servers side would be a mistake IMO. One of issues with Swift on a server is ARC vs a Go-like GC. If a company is legitimately concerned about runtime efficiency, they already have such great solutions. Go being one of those.

Re: Which Programming Languages Use the Least Electricity? (2018)

#225

Earlier quoted context omitted.

Not sure why you picked on Java though. As per this study, Java is doing better than both of them. So at least if the goal is to improve on those, you need to look at Rust/C++/C/Ada.

I'm not trying to pick on it. But those languages are significantly harder to develop for. Go/Swift are trying to be general improvements that maintain and improve upon developer productivity while achieving great performance and efficient memory utilization (which if you look at the paper is one area Java is not necessarily great at).

I have written server's in Kotlin, that run on the JVM and thus are practically the same. IMO I am far more productive then using Swift, plus you have access to a huge legacy of stable, well thought out, and documented libraries.

Re: Which Programming Languages Use the Least Electricity? (2018)

#226
post #91

Couple points (I've worked on app servers): 1- This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically reduce carbon footprint within 11 years. Efficiencies at the language level are one of biggest bangs for buck here. Just by redeploying, you can reduce energy consumption by perhaps double digits. Imagine how hard that is to do at the hardware or energy farm le…

I work in Swift on iOS. I think the "Swift on a server" idea is way over hyped. There are so many issues with the whole Swift stack adopting that servers side would be a mistake IMO. One of issues with Swift on a server is ARC vs a Go-like GC. If a company is legitimately concerned about runtime efficiency, they already have such great solutions. Go being one of those.

I would love to hear your perspective but this is not a well supported argument. ARC is one of the most interesting things about Swift on the server. Historically one of the greatest challenges with servers is the impact of GC on the long tail of performance and latency. So, so much work has gone and continues to go into addressing the problem of low-overhead GC. You can appear to get great performance but then when you look at your stats you see that some significant percentage of your users are exceeding your maximum latency goals due to GC kicking in. Go and Java have made great strides but sometimes at the cost of memory inefficiency and/or optimizing for specific cases.

Reference counting, by contrast, is entirely predictable. It doesn't defer any work. I would argue that CTOs are a lot more interested in consistently low latency than in requests per second. So it's very interesting to see an approachable, performant language take the ARC route on the server. It is early days though.

Re: Which Programming Languages Use the Least Electricity? (2018)

#227
post #91

Couple points (I've worked on app servers): 1- This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically reduce carbon footprint within 11 years. Efficiencies at the language level are one of biggest bangs for buck here. Just by redeploying, you can reduce energy consumption by perhaps double digits. Imagine how hard that is to do at the hardware or energy farm le…

Go's GC is not really pushing the envelope. They have merely improved from a STW, non-compacting, non-generational collector with a 25% CPU overhead to a concurrent, non-compacting collector with reasonable overhead. JVMs and CLR had those a decade ago. The state of the art are concurrent, compacting, region-based pauseless or millisecond-pause collectors.

Also using a Swift like ARC implementation server side that doesn't seem like a good idea. Memory leaks are so common in iOS development. Its just they are usually small enough and an iOS application lifetime is so short it doesn't matter. An ARC implementation that handles cyclical references seems like a more stable solution for a server.

-Note- I'm not saying one is better than the other. ARC works great on iOS for creating applications.

Re: Which Programming Languages Use the Least Electricity? (2018)

#228
post #213
post #13

Earlier quoted context omitted.

I don't use Typescript, and use Javascript only for what I have to. I don't care about the ranking of either of them, I'm just pointing out a possible flaw in the methodology that should be taken into account when looking at the numbers presented, and what I suspect is a concrete example of that. This also isn't a criticism of the benchmark game, it's well known that not every implementation is equivalent in the time…

> Unfortunately, using it as the base of further calculations can lead to some of the known quirks of the benchmarks being exaggerated You seem not to have considered the possibility that the authors may have simply made a mistake, unrelated to the origin of the programs. The authors presented at an Oct 2017 conference. Archived benchmarks game web-pages from 2017 do not show the 10x fannkuch-redux differences that t…

> Archived benchmarks game web-pages from 2017 do not show the 10x fannkuch-redux differences that the authors report

I think the Sep 1st 2017 benchmark does, though.[1] At that point it's 1,204.93 seconds, compared to the 131.39 seconds on September 18th you referenced. That makes sense, since the paper could have been finished quite a bit prior to the conference.

1: https://web.archive.org/web/20170901020804/http://benchmarks...

Re: Which Programming Languages Use the Least Electricity? (2018)

#229
post #29

Earlier quoted context omitted.

So why is the TypeScript bench slower?

My best guess: probably written by someone that doeant know how to write performance TS. I say this with no skin in the game. I write neither JS nor TS. What I have observed in language benchmarks over the years, is that the benchmarks are rarely written by an expert, but usually by someone with cursory knowledge of the language. E.g. just enough to be dangerous. Often times, these sorts of benchmarks are done with p…

[deleted]

Re: Which Programming Languages Use the Least Electricity? (2018)

#230
post #213

Earlier quoted context omitted.

> Unfortunately, using it as the base of further calculations can lead to some of the known quirks of the benchmarks being exaggerated You seem not to have considered the possibility that the authors may have simply made a mistake, unrelated to the origin of the programs. The authors presented at an Oct 2017 conference. Archived benchmarks game web-pages from 2017 do not show the 10x fannkuch-redux differences that t…

> Archived benchmarks game web-pages from 2017 do not show the 10x fannkuch-redux differences that the authors report I think the Sep 1st 2017 benchmark does, though.[1] At that point it's 1,204.93 seconds, compared to the 131.39 seconds on September 18th you referenced. That makes sense, since the paper could have been finished quite a bit prior to the conference. 1: https://web.archive.org/web/20170901020804/http:/…

[deleted]
Post reply on HN