Live data from Hacker News

Which Programming Languages Use the Least Electricity? (2018)

thenewstack.io

241–250 of 267 posts

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

#241
post #167

Earlier quoted context omitted.

Comparing Go's GC to one of the many specialized fine-tunned Java GCs is pointless, I find. I'm sure you're also aware that recent Go's GC pauses are sub millisecond for most use cases: "We now have an objective of 500 microseconds stop the world pause per GC cycle." - 2018 Go team https://blog.golang.org/ismmkeynote My personal experience with microservices is to expect STW pauses in the 350 microsecond range. The b…

I was talking about technology state of the art, not out-of-the-box experience. OpenJDK's default collector - parallel or G1GC, depending on version - is not the best available among JVMs and if your goal is pause times then yes, it will be worse than Go's. But if you switch to say C4 or ZGC you'll get comparable pause times and compacting on top and being able to scale to terabyte heaps. 10 years ago we had Metronom…

Of course gains are to be expected when switching from Java's default GC to something specialized.

> 25% GC overhead in older versions of Go, that's utterly terrible.

25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense.

The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png

2014 Go: 25% of CPU used by GC

2018 Go: 25% of CPU used during 2x STW GC of So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.

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

#242
post #241

Earlier quoted context omitted.

I was talking about technology state of the art, not out-of-the-box experience. OpenJDK's default collector - parallel or G1GC, depending on version - is not the best available among JVMs and if your goal is pause times then yes, it will be worse than Go's. But if you switch to say C4 or ZGC you'll get comparable pause times and compacting on top and being able to scale to terabyte heaps. 10 years ago we had Metronom…

Of course gains are to be expected when switching from Java's default GC to something specialized. > 25% GC overhead in older versions of Go, that's utterly terrible. 25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense. The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png 2014 Go: 25% of CPU used by GC 201…

The 2014 numbers read to me that 25% of all CPU cycles are spent on GC. If you re-read my previous post I was talking about that old version. The point was that Go started improvements from a fairly bad place, were gains are still relatively easy to obtain.

> Of course gains are to be expected when switching from Java's default GC to something specialized.

So? That's irrelevant for what's state of the art.

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

#243
post #241

Earlier quoted context omitted.

Of course gains are to be expected when switching from Java's default GC to something specialized. > 25% GC overhead in older versions of Go, that's utterly terrible. 25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense. The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png 2014 Go: 25% of CPU used by GC 201…

The 2014 numbers read to me that 25% of all CPU cycles are spent on GC. If you re-read my previous post I was talking about that old version. The point was that Go started improvements from a fairly bad place, were gains are still relatively easy to obtain. > Of course gains are to be expected when switching from Java's default GC to something specialized. So? That's irrelevant for what's state of the art.

I re-read our conversation thread to understand our communication mismatch and indeed you were taking about Go's GC not being novel, which it isn't. I apologize for the unproductive conversation, it's all on me.

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

#244
post #235

Earlier quoted context omitted.

> 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…

Do you agree that those very different times were measurements of the same TypeScript fannkuch-redux program? 5 July, Node 8.1.3, TypeScript 2.4.1 https://web.archive.org/web/20170715120038/http://benchmarks... 1 Sep, Node 8.4.0, TypeScript 2.5.2 https://web.archive.org/web/20170922144419/http://benchmarks... ---- How should we now assess your "suspiciously like entirely different algorithms were used in each impleme…

> Do you agree that those very different times were measurements of the same TypeScript fannkuch-redux program?

Yes.

> How should we now assess your "suspiciously like entirely different algorithms were used in each implementation" comment?

The suspicion was incorrect. That's why it was presented as a suspicion, not as fact. I have no reason to defend it if it's incorrect, but I still defend that it was valid to raise questions, given the facts on the ground. We've now shown there was something that changed very drastically at that time, and while it's less likely it's the benchmarks themselves (unless one or both of those are fairly out of date Node versions)[1], it still points towards something to be aware of in the results presented. Namely, they rely on a lot of underlying assumptions which should be looked at if you care about the numbers.

1: Also, I imagine the V8 devs probably considered the performance of TypeScript in that case to be a bug, given how horrible the performance regression from JavaScript is and that it's still javaScript running. It's possible that TypeScript was doing something really odd, but given the exposure and Microsoft's backing and developer time, I think that's a less likely scenario than some optimization that should have been triggered was missing, which happens quite often.

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

#246
post #231

Earlier quoted context omitted.

> What are you talking about? Where did that happen? I was responding directly to @hermitdev. Did you get your threads crossed? What I'm talking about happened immediately above in the parent comment, beginning with "Often times, these sorts of benchmarks are done with prejudice" https://news.ycombinator.com/item?id=19527057 "You'll see this time and time again in internet benchmarks comparing performance." > It is p…

> The parent comment explicitly stated an assumption of both incompetence and prejudice and I responded directly to that. Perhaps I misinterpreted what you said. You started the paragraph referring to the top level comment, which is me. I took the "you're" in "You’re assuming incompetence when you could just go look it up." to be a general "you", and commentary on my original comment. > From the HN guidelines: "Pleas…

> The more charitable interpretation is not that they are trying to make another language look bad, but that they are trying to make their favorite language look good.

The project doesn’t talk about favorites or seem to want to make certain languages look good. Jumping to the conclusion that bias is involved isn’t the good faith interpretation, even if you state with a positive sounding framing. The good faith interpretation is to take the stated project goals at face value, and assume that the participants have done a good job.

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

#247
post #239
post #219

Earlier quoted context omitted.

If we assume they understood the relationship between JavaScript and TypeScript then maybe it should have been noticed. However, the original research has been posted multiple times to proggit and HN since 2017; and I don't recall whether or not anyone noticed this problem until now -- https://news.ycombinator.com/item?id=15249289 https://www.google.com/search?q=energy+efficiency+programmin...

maybe it should have been noticed It's a study presented at some conference so while not exactly the Higgs boson, they're showing other people data and the conclusions they derived from it. It's 100% their job to understand what their data measures and to notice that one of the measurements is completely bogus for their purposes. The fact other people hadn't necessarily noticed on messageboards before is mildly curio…

afaict the evidence is - not - that "one of the measurements is completely bogus".

On the contrary; we can see from archived web pages that other measurements showed the same relatively-poor performance, with those old versions of TypeScript.

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

#248
post #18

Earlier quoted context omitted.

How does less dev time save energy “somewhere else in the world”? Google & AWS pay money to develop & acquire technologies that save energy because of their scale. The energy used in dev is scratch compared to the energy used to run programs at scale. Google, for example, has a PHP compiler that makes all PHP web pages execute in a fraction of the energy usage of running the PHP interpreter.

...Google has a PHP compiler? Don't you mean Hack/HHVM by FB?

Nope, I don’t mean HHVM. I was thinking of Talaria. I don’t know if they still use it. http://enswmu.blogspot.com/2013/03/why-google-acquired-talar...

But HipHop is certainly another good example that demonstrates that this matters in practice.

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

#249
post #235

Earlier quoted context omitted.

Do you agree that those very different times were measurements of the same TypeScript fannkuch-redux program? 5 July, Node 8.1.3, TypeScript 2.4.1 https://web.archive.org/web/20170715120038/http://benchmarks... 1 Sep, Node 8.4.0, TypeScript 2.5.2 https://web.archive.org/web/20170922144419/http://benchmarks... ---- How should we now assess your "suspiciously like entirely different algorithms were used in each impleme…

> Do you agree that those very different times were measurements of the same TypeScript fannkuch-redux program? Yes. > How should we now assess your "suspiciously like entirely different algorithms were used in each implementation" comment? The suspicion was incorrect. That's why it was presented as a suspicion, not as fact. I have no reason to defend it if it's incorrect, but I still defend that it was valid to rais…

Please add a correction to your original comment, to prevent readers from being misled. (If it's closed to edits, I'm sure HN staff will open it when you ask).

> I still defend that it was valid to raise questions

Of course, it's valid to question a measurement that looks strange but your comment went further than that -- your comment, without evidence, assumed a cause; and, without evidence, implied that assumed cause led to widespread problems with the analysis.

In other words -- innuendo.

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

#250
post #246

Earlier quoted context omitted.

> The parent comment explicitly stated an assumption of both incompetence and prejudice and I responded directly to that. Perhaps I misinterpreted what you said. You started the paragraph referring to the top level comment, which is me. I took the "you're" in "You’re assuming incompetence when you could just go look it up." to be a general "you", and commentary on my original comment. > From the HN guidelines: "Pleas…

> The more charitable interpretation is not that they are trying to make another language look bad, but that they are trying to make their favorite language look good. The project doesn’t talk about favorites or seem to want to make certain languages look good. Jumping to the conclusion that bias is involved isn’t the good faith interpretation, even if you state with a positive sounding framing. The good faith interp…

> The project doesn’t talk about favorites or seem to want to make certain languages look good. Jumping to the conclusion that bias is involved isn’t the good faith interpretation

I didn't see anywhere that the comment in question called any project bias into question, but instead noted that in a situation where work is crowd sourced, people with their own intentions and motivations will put out bad benchmarks, either in the case of the benchmarks game, or a specific benchmark or comparison put forth in an article or blog. I've personally been witness to the latter multiple times just from HN submissions.

I just want to end with, as someone that's brought up viewing comments in an uncharitable light, you seem to have done a lot of that in this discussion. You've repeatedly taken your interpretation of a comment, rephrased it in a harsher way, and the stated it as what the other person was saying as fact, and then responded to that. I would think actually trying to find a charitable interpretation should at least include a question at the beginning to confirm whether what you think is being said is entirely correct. Note that I started with that when I thought you were attributing statements to me that I did not say. My first words were a solicitation "What are you talking about? Where did that happen?" to confirm what was going on. You've been doing this from your first response to my top level commend, when you stated "But you’re using that assumption to cast slippery-slope doubt on the whole project without knowing anything specific." That's a very uncharitable rephrasing of what you think I was doing, and it certainly wasn't my intention. I've already outlines in specific exactly what I was trying to do and why, and in doing so I also stated that I felt you were misinterpreting me. There's a clear trend here as I see it, and you repeatedly bringing up good faith assumptions just puts it into clear highlight.

I think we've covered about all there is to say on this (these) topics. I'll let you have to the last word if you wish. I'll read and promise to consider any points you raise, but I don't think me responding would be very fruitful, and this discussion has digressed far enough.

Post reply on HN