Live data from Hacker News

Which Programming Languages Use the Least Electricity? (2018)

thenewstack.io

251–260 of 267 posts

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

#251
post #249

Earlier quoted context omitted.

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

> Please add a correction to your original comment, to prevent readers from being misled.

Corrections are for facts. I put forth a theory. People being misled by a theory are not something I have limited power to affect. People representing theories read on the internet as fact have larger problems that that will solve.

This discussion is the correction, and a better one than someone would be willing to read. Were it within the 2 hour edit window, I would through in an edit, I've done so numerous times in the past. I will ask Hn to amend it's rules so I can correct a statement I made about something I suspected.

> 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

This is incorrect. I had evidence, I had numbers that did not line up with my understanding of how things should have been given my knowledge of the subject. I presented that as a theory, by using the word "suspect". All I implied is that if that theory was correct, which I made sure to not assert as fact, then it might affect some other languages. I did not assume a cause, I assumed a possible cause, and presented it as such.

I am very particular with my language. I try not to state things as fact when they are not. I try my absolute hardest (and I believe I succeed) to always speak in good faith, where I'm trying to raise a point I think is worthwhile or ask a question where I think there is benefit. I'm actually rather bothered by how some people interpreted my words and intentions, and that includes you. I'm bothered by how you've interpreted my words. Since you're not the only one (although I do believe you're in the minority), I'll assume there's something I could have done better to represent my point. I don't think all the blame lays with me though. There should be some way for me to posit a question and advance a theory without people assuming bad faith, so my question to you is, what way is that? How could I have expressed concern over the results without triggering that interpretation from you? Because I don't think doing personal research on a problem is an acceptable prerequisite for raising a question. In this case, I could have spent hours looking into something I was unfamiliar with and come away with more answers, but many people may not have the knowledge to do so but have enough to think something is wrong. Should they just keep their mouths shut? Are we in a time where raising a concern that turns out to be unfounded (or in this case, just more complicated and slightly misdirected) is unacceptable under any circumstance? I refuse to accept that.

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

#252

Earlier quoted context omitted.

They already do, in the sense that you'll need beefier/more machines to do the same job. Of course, using Python means you have a lot of low-hanging fruit to pick. We have a Python service where we moved ONE ~60 line recursive function to Go and overall CPU consumption dropped to 15-20% of what it used to be.

That sounds pretty damn nice - would you happen to have a good link in mind for reading more on the subject?

This was a financial function which calculated an internal return of return for a long series of uneven cash flows, essentially a python implementation of the XIRR function that spreadsheets have.

To get to the required two decimal places of precision, each call would recurse 50-60 or more times so this was more or less all that the server was doing.

A VERY low hanging fruit.

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

#253

Earlier quoted context omitted.

That sounds pretty damn nice - would you happen to have a good link in mind for reading more on the subject?

What's interesting is also how go and python interaction is since you seem to be able to call go from python and the reverse very efficiently.

Sorry but we actually cheated on that part. Redid the page so that the function that is now in Go is a separate little service that is called via ajax directly by the users' browsers.

So there's no actual Python-Go interaction in our code.

This was quicker, cleaner and has made the page more responsive for users.

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

#254
post #247
post #239

Earlier quoted context omitted.

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.

What do the archived pages have to do with this study? The study starts with a snapshot of benchmark game sources. That's a perfectly sensible way to get a bunch of implementations to bootstrap the study. But some of those implementations might be unsuitable for the study, just as (at least) one was, in their case. They don't seem to have noticed that. What's a good, benign explanation that they didn't?

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

#255

Earlier quoted context omitted.

Two completely serious questions here, 1 - Why would you want to replace java on the server? (Seems obvious that it provides the best balance of productivity and performance per watt.) 2 - Assuming a company would want to replace jave, why, on earth, would we not use C++? (Or, perhaps, rust if we want to use a newcomer?) Why are we better off going all the way down this list to go and swift?

> 1 - Why would you want to replace java on the server? Well one reason, if you look at the paper, is memory consumption. One of the ways Java gets good performance despite being a GC'd language is less efficient memory usage. (Although there are many advancements in this area akin to what Go has accomplished but as the paper's metrics show, often Java uses a lot of mem.) Also probably lots of people will agree that…

> and predates lots of modern trends and things like concurrency and functional programming and whatnot require more complicated code patterns..

And golang does what exactly for this? As a matter of fact, Java is superior here to golang on these fronts, and is only going to get better. There is a lot of unsubstantiated golang hype and people should know better.

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

#256

Earlier quoted context omitted.

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…

Refcounting has long tail latency too arising from cascading deallocations.

(And then you have ref cycles which is another kind of headache. And poor cache behavior from all those refcount updates.)

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

#258
post #249

Earlier quoted context omitted.

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

> Please add a correction to your original comment, to prevent readers from being misled. Corrections are for facts. I put forth a theory. People being misled by a theory are not something I have limited power to affect. People representing theories read on the internet as fact have larger problems that that will solve. This discussion is the correction, and a better one than someone would be willing to read. Were it…

The honest concern is that the reported time measurements for those JavaScript and TypeScript fannkuch-redux programs seem too different.

The honest question is -- Can someone please confirm that those programs implement the same algorithm?

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

#259
post #254
post #247

Earlier quoted context omitted.

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.

What do the archived pages have to do with this study? The study starts with a snapshot of benchmark game sources. That's a perfectly sensible way to get a bunch of implementations to bootstrap the study. But some of those implementations might be unsuitable for the study, just as (at least) one was, in their case. They don't seem to have noticed that. What's a good, benign explanation that they didn't?

> But some of those implementations might be unsuitable for the study, just as (at least) one was, in their case.

Unsuitable because?

Post reply on HN