Which Programming Languages Use the Least Electricity? (2018) • Hacker News Board

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

#231

Post by dahart » Sat, Mar 30, 2019, 9:51 PM UTC

kbenson wrote: post #223

dahart wrote: post #201

Earlier quoted context omitted.

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…

> 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 perfectly valid to bring up a question that you don't know the answer to.

I agree. It's a bummer that's not really what happened here.

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

The parent comment explicitly stated an assumption of both incompetence and prejudice and I responded directly to that.

From the HN guidelines: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

If you'd like me not to call out speculation, then please assume good faith and don't speculate next time.

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

Yes! Now we are getting somewhere. It appears that would change the outcome of the paper. Perhaps it was a mistake. That might mean it was nothing more than an oversight that already got fixed. It doesn't mean there is any other coloring of the study at all, nor that there was any intention or agenda to make TypeScript look bad, right?

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

#232

Post by ramensea » Sat, Mar 30, 2019, 9:53 PM UTC

abalone wrote: post #226

ramensea wrote: post #224

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…

My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle.

ARC would be just one my issues using Swift outside of iOS.

I think you are overstating the pause duration of a modern GC. I have used both Go and the JVM server side, not at a huge scale but enough to see GC effecting response times. They add some fluctuate, but nothing compared to network latency or the multitude of other factors that fluctuate heavily. It was never significantly relevant for response times. I'm looking at my server logs right now and theres not even a real correlation between GC and response time. Unless you are considering a 0-10ms fluctuation.

If you are interested in using an ARC server side I know Kotlin Native is using ARC however their implementation eliminates the cyclical reference issue.

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

#233

Post by igouy » Sat, Mar 30, 2019, 9:58 PM UTC

kbenson wrote: post #228

igouy wrote: 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:/…

That's interesting. 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 implementation" comment?

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

#234

Post by [deleted] » Sat, Mar 30, 2019, 10:00 PM UTC

kbenson wrote: post #223

dahart wrote: post #201

Earlier quoted context omitted.

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…

[deleted]

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

#235

Post by igouy » Sat, Mar 30, 2019, 10:12 PM UTC

kbenson wrote: post #223

dahart wrote: post #201

Earlier quoted context omitted.

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…

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 implementation" comment?

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

#236

Post by abalone » Sat, Mar 30, 2019, 10:47 PM UTC

ramensea wrote: post #232

abalone wrote: post #226

Earlier quoted context omitted.

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…

My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle. ARC would be just one my…

Nah, I’d say Swift’s good support for value type semantics helps cut down on leak problems. Depends on the patterns you use of course but I can see that being a good approach for server apps.

Funny you say that because just this week there has been an investigation into what seemed to be “leaks” but turns out it’s memory fragmentation. It’s a fascinating read into how to debug a server problem if you’re into that sort of thing.[1]

Agree that modern tracing GC can be very good in a wide range of cases but there are some where it’s not. Very dependent on the case. Ultimately you are deferring work and hoping to find some time in the future to squeeze it in unnoticed. ARC is a cool paradigm to explore on the server as it doesn’t have this problem to begin with.

[1] https://forums.swift.org/t/memory-leaking-in-vapor-app/22209...

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

#237

Post by ramensea » Sat, Mar 30, 2019, 11:21 PM UTC

abalone wrote: post #236

ramensea wrote: post #232

Earlier quoted context omitted.

My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle. ARC would be just one my…

Nah, I’d say Swift’s good support for value type semantics helps cut down on leak problems. Depends on the patterns you use of course but I can see that being a good approach for server apps. Funny you say that because just this week there has been an investigation into what seemed to be “leaks” but turns out it’s memory fragmentation. It’s a fascinating read into how to debug a server problem if you’re into that sor…

Value types are great, but they don't help cut down on cyclical references as the type of coding that will cause memory leaks is done in objects. Typically objects with complex dependencies and inheritance hierarchies.

Memory fragmentation is another legit concern I guess, as far as I can remember iOS has no memory compaction. Again not a necessarily an issue for a short live user space application, it is a larger one than memory leaks at least at my company. In some hot spots of our app we specifically slow down reading of some queries to reduce memory fragmentation.

Frankly Chris Lattner's claim that a GC leads to 2x-3x memory consumption over ARC is unfounded and sorta shocking coming from someone held is such high esteem. It's something thats continually shown to be untrue.

It always seems Swift's biggest selling point is it uses ARC instead of a GC, which is either not a large issue or a GC is actually more beneficial. Other than that you still haven't dealt with the toxic "Swifty" community, the terrible tooling situation, the immature libraries and frameworks, etc, etc.

There seems to be so many better solutions to writing server side code. This is all coming from someone who uses the language on a daily basis.

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

#238

Post by ramensea » Sat, Mar 30, 2019, 11:34 PM UTC

abalone wrote: post #236

ramensea wrote: post #232

Earlier quoted context omitted.

My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle. ARC would be just one my…

Nah, I’d say Swift’s good support for value type semantics helps cut down on leak problems. Depends on the patterns you use of course but I can see that being a good approach for server apps. Funny you say that because just this week there has been an investigation into what seemed to be “leaks” but turns out it’s memory fragmentation. It’s a fascinating read into how to debug a server problem if you’re into that sor…

Glad to see Vapor/Perfect has toned down their "we are going to change the world by releasing a new web framework" rhetoric on their sites. When they both first did announced them it was pretty cringe

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

#239

Post by pvg » Sun, Mar 31, 2019, 12:17 AM UTC

igouy wrote: post #219

pvg wrote: post #65

Earlier quoted context omitted.

It took me about a minute looking at their published detailed data to notice the problem. They should have noticed a factor-of-15ish outlier and checked why on earth it was there.

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 curious but it's not really their job.

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

#240

Post by kbenson » Sun, Mar 31, 2019, 12:36 AM UTC

dahart wrote: post #231

kbenson wrote: post #223

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…

> 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: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

I actually looked this up before the GP comment, and almost included it myself. I can see now that you were implicating the comment you replied to. I didn't think that was the case, because I apparently didn't interpret that comment remotely in the same way you did.

> Perhaps it was a mistake. That might mean it was nothing more than an oversight that already got fixed. It doesn't mean there is any other coloring of the study at all, nor that there was any intention or agenda to make TypeScript look bad, right?

I never implied it was. For that matter, I didn't really interpret the comment in question as stating that either. 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. That doesn't require purposefully tanking one benchmark, it just requires them to be much better versed in optimizing one language than another and a lack of awareness about this. As they say, never attribute to malice what can be explained by incompetence. In fact, if you read the comment carefully, they even call out to this with the "not necessarily malice" remark.