[HN Gopher] Energy Efficiency across Programming Languages [pdf]
___________________________________________________________________
Energy Efficiency across Programming Languages [pdf]
Author : Malfunction92
Score : 99 points
Date : 2020-09-30 18:43 UTC (4 hours ago)
(HTM) web link (greenlab.di.uminho.pt)
(TXT) w3m dump (greenlab.di.uminho.pt)
| lliamander wrote:
| That Erlang is relatively power inefficient doesn't surprise me.
| I wonder how much of that is due to the "busy wait" it uses to
| reduce the latency in message processing.
| devmunchies wrote:
| not really a fair comparison since erlang is a fully fledged
| operating system (joke).
|
| in general functional languages do worse due to the
| abstraction, and then VM languages do worse still, and then
| dynamically typed languages are less efficient than statically
| typed. Erlang is all the above.
|
| F# fits the first 2 (functional lang on a VM) and has a pretty
| bad energy rating despite being a fast language.
| lliamander wrote:
| > not really a fair comparison since erlang is a fully
| fledged operating system (joke).
|
| Oh, Robert Virding told me once the plan was to make it
| essentially an OS. So, it's only a joke in the "Ha ha but
| seriously" sense.
|
| Lisp also fits all those criteria and is quite efficient, but
| it developed under different design constraints.
| tastyminerals2 wrote:
| I wonder how these rankings would have changed for C++ and Rust
| if they included compile times :)
| Jetroid wrote:
| I wouldn't consider compile time to be a useful metric here, as
| you will generally compile once (for the final release
| candidate(s)) and execute many times.
| tastyminerals2 wrote:
| True. But maybe during development it could.
| tines wrote:
| I did some research on this topic in university, and our
| consistent result for CPU-based programs was: if it finishes
| faster, it uses less energy, and vice versa.
|
| So it's no surprise to see that VM-based programs use more
| energy; they're slower.
| cozzyd wrote:
| Memory usage matters too! Languages lacking shared memory
| multiprocessing will use more energy even if they're equally
| fast.
| tines wrote:
| That's a good point. DRAM only sucks power when you flip the
| bits right?
| cozzyd wrote:
| Well it has to be constantly refreshed (I think?) if
| there's something important in it. But more I was thinking
| that you need more memory to support less-efficient memory
| usage in the first place, or, if the amount of memory is
| fixed, less of it would be used for things like the disk
| cache.
| gameswithgo wrote:
| People like to argue this point because there are rare
| exceptions when it isn't true, but yes, generally the faster
| the things finishes, the less energy you use. It is a fine rule
| of thumb to use in absence of direct power draw.
| corysama wrote:
| In SDK docs for the GameBoy Advance there was a note along
| the lines of
|
| "Even if your game is so simple that it does not require the
| full speed of the (16.78 MHz) machine, please put effort into
| optimizing it anyway so that it can spend more time sleeping
| in the low-power PAUSE instruction. Your players will notice
| the difference in battery drain and they will tell their
| friends."
| dnautics wrote:
| These are computationally-heavy workloads. Do most HN programmers
| really do work in those domains? Is most computational work done
| today even in those domains (possibly, due to the amount of
| streaming videos, but also most of us are not coding video
| streamers)? Maybe a more interesting to test workload would be
| parsing medium-large random JSONs issued by concurrently-
| connecting entities. And also comparing the same setup under a
| low-workload scenario with a high workload scenario, possibly
| also comparing orchestration engines (e.g. kubernetes
| autoscaling).
|
| I'd also be curious to probe "worst case" scenarios. Can you
| cause kubernetes to thrash spinning up and killing containers
| really badly, and how much of an effect does that have on energy
| consumption?
| gojomo wrote:
| Oh heavens, busybodies are gonna ban Python and Ruby under the
| guise of fighting climate change.
| gameswithgo wrote:
| I've been fighting to ban use of interpreted code in production
| because I hate slow stuff, and like money. So you can use those
| motivations instead if you like. If you love Python and Ruby,
| make compilation a first class method of running them.
| Gibbon1 wrote:
| When I looked at the results seems Swift and C# are pretty
| good general purpose languages. Interesting to see how bad
| Typescript compares to JavaScript.
| saagarjha wrote:
| Sadly those two are fairly tied to a specific platform
| (note: yes, I know they are technically cross-platform).
| m0zg wrote:
| I'm surprised that Rust is ahead of C++ in their ranking, and by
| quite a bit. I tend to use C++ as "C with STL and smart pointers"
| basically (a-la Google), I don't see why it'd be any slower or
| less energy efficient than C.
| atroxone wrote:
| Why do you consider typescript and javascript different
| languages?
| krapp wrote:
| Can you put a program written in typescript between <script>
| tags and have it run natively in the browser?
| [deleted]
| 7thaccount wrote:
| Not OP and don't use JS, but generally speaking, a lot of these
| languages that transpile one language into another (or compile
| one language to another for those that insist transpile is the
| wrong word), it comes up with a less efficient result than if I
| had just used the original language. Or at least a different
| program. So if I use Type Script that gets converted to
| JavaScript, the end result will be different than if I had done
| it like that to begin with (not necessarily slower either).
|
| Also...I guess there are situations where using something (Ex:
| C) could lead to faster code than me using Assembly by myself
| if the compiler is smarter than me (GCC knows a lot more about
| hardware than I do).
| k__ wrote:
| I once read that coding in TypeScript leads to more
| monomorphic code, which can be better optimized by the JS VM.
| tastyminerals2 wrote:
| Lua memory consumption is surprisingly very high.
| drmeister wrote:
| Huh - I somehow submitted the same message twice. Hacker News
| doesn't let me delete it. So I'll edit it down - see the version
| above about Common Lisp and our implementation of it called
| Clasp.
| nynx wrote:
| You're developing clasp for use in your matter compiler
| project, correct?
| drmeister wrote:
| I did - and we compiled our first batch of molecules using an
| application implemented in Cando (Clasp + computational
| chemistry code) yesterday. I'm absolutely serious about this.
| nynx wrote:
| Amazing. Have the goals of the project changed over time,
| or is it still to generate molecules that fit a certain
| shape/function based on a number of known building blocks?
| drmeister wrote:
| The goals have not changed. The pace of development (in
| the chemistry) has accelerated by orders of magnitude in
| the last year. The software is advancing as well. We are
| still looking for good developers who want to work with
| us.
| nynx wrote:
| Are you looking for students to work on development over
| a summer or semester-long break?
| pcstl wrote:
| Do you have a public website or anywhere I can read more
| about your project? And if I'm interested, how can I
| contact you?
| drmeister wrote:
| We do have a public website - you could contact me. We
| are still running under the radar so there isn't much
| detail but there is a lot in the scientific literature.
| http://www.thirdlaw.tech and
| https://www.schafmeistergroup.com/. I also have some
| talks up on the youtube.
| fishmaster wrote:
| How far along are you with Clasp?
| drmeister wrote:
| It's working fine. We are developing applications within it
| for the past year. We have been kind of low key because we
| are using it as part of a much larger project.
| cphajduk wrote:
| Interesting to see Rust beat out C++ very slightly.
| moonchild wrote:
| If you look at some of the individual benchmarks, they show
| that c, c++, rust, ada, and fortran are all over each other.
|
| I expect the difference in this case is either due to
| differences between llvm and gcc; differences in the standard
| library implementation; or because rust requires strict
| aliasing by default.
| kevincox wrote:
| Yup. In theory Rust and Fortran perform better than the
| others mostly due to the strict aliasing rules. However many
| benchmarks won't benefit from this difference and in practice
| it depends mostly on the standard library implementation and
| the "idiomatic" solution in each language. Of course
| compilers matter as well and even if they can all use LLVM
| the maturity of the frontends does matter.
| iTokio wrote:
| It's probable that they are mostly measuring implementations
| efficiency or GCC vs LLVM for these languages.
| petermcneeley wrote:
| Given that C++ is (mostly) as superset of C its not simply
| interesting its odd. Did they not simply give the C program to
| C++? Are they claiming that the C++ compiler compiles C
| programs to slower lower perf binary.
| rsanders wrote:
| That's a good point. But then you're not benchmarking C++ as
| a distinct language. So what would sufficiently distinguish a
| C++ program from a C program? Let's assume it's not just
| minor incompatibilities introduced to prevent compilation by
| a C compiler.
|
| There must have used some definition that is not explicit in
| the paper, but you can see in this code sample that the
| author used various C++ standard data types (std::string,
| std::array), iterators, classes, concurrency (std::thread).
| I'm no judge of C++ style, but perhaps it's "C++ as a C++
| developer circa 1997 would have written it".
|
| https://github.com/greensoftwarelab/Energy-
| Languages/blob/ma...
| dochtman wrote:
| Given that it's from 2017, I'm guessing today's results might
| be quite different.
| lliamander wrote:
| This is cool.
|
| Now, can we get a comparison of these results vs. LOC?
|
| I feel like almost any assessment of programming languages should
| have a table weighting the results based on how many lines of
| code it took to get that result.
| egsmi wrote:
| I was really interested in how they measured power because there
| is a ton of nuance there.
|
| They used the metric reported by a tool that limits average power
| via a programmable power limiter in hardware which an interesting
| way to do it. Totally valid but I really wish they provided more
| detail here. For example, did all workloads run at limit all the
| time? Presumably they did. Limit based throttling is a form of
| hysteretic control so the penalty part will be critical. How
| often and when the limit is hit will be critical too.
| zachruss92 wrote:
| Something I've been thinking a lot about lately is environmental
| friendliness in software, given that data centers contribute 3%
| of global greenhouse emissions (same amount as the entire airline
| indistry).
|
| I'm thinking along the lines of using interpreted languages less
| server side because of efficiency, but also relying on JS less
| client side and using WASM where it makes sense.
|
| This has stemmed from me leaning Go last year and being moved by
| actually how much faster it is than Node for my use cases (API
| development and data processing).
|
| Where I am curious to see the total impact is how we can take
| advantage of economies of scale to save money and increase
| efficiency. I'm thinking along the lines of scale to zero, event
| driven architectures.
|
| Google Cloud, for example, claims they operate their data centers
| with industry leading efficiency while also being powered by
| renewable energy. At scale, do services like Cloud Run or Cloud
| Functions actually make a difference?
| open-source-ux wrote:
| When I look at other industries I see efforts to reduce energy
| consumption. A lot of programmers, in contrast, couldn't care
| less. The most popular languages are the least energy efficient
| and most resource intensive. But they make life easier for
| developers, or as programmers love to say 'more productive'.
|
| When performance is an issue in running programs, a common
| response is: hardware is cheap, just add another energy-
| guzzling server or use a more powerful computer.
|
| This attitude is embarrassing when you consider that in every
| other industry there is a push for reduced resource usage and
| lower energy consumption. The programming field is the
| exception.
|
| On the other hand, when it's programmers who are on the
| receiving end of slow, resource intensive apps, they'll
| complain loudly. This industry is rife with hypocrisy.
| Jtsummers wrote:
| IT-centric orgs definitely care. In my second (post-college,
| full-time) job I got to see the effect of this directly as
| truck loads of old server equipment were replaced with about
| 1/10th the hardware. In their case, predominantly by making
| good use of virtualization so that applications could share
| hardware. They cut their power consumption by more than 90%
| by upgrading to newer machines as well (which were more
| efficient, while still being faster than the old ones).
|
| This broad brush view that the IT industry doesn't care is
| absurd, they have to pay bills too and efficiency reduces
| those. They may not be motivated by environmental concerns,
| but the costs are very much obvious to them and they do
| address it with improved efficiencies where possible.
| user5994461 wrote:
| There is absolutely an objective to reduce the use of compute
| resources. Especially in the current era of AWS/google cloud
| where you pay $50 per core per month.
|
| Companies care very much about resource usage past some
| amount of machines. They don't think in terms of power
| consumption or environmental footprint though, but in real
| dollars (the costs of hardware/cloud) that is highly
| correlated.
|
| Kubernetes is the latest trend in spite of being an
| overcomplicated mess, precisely because it's an
| overcomplicated mess that can deploy and pack services more
| efficiently onto (less) resources.
| wmf wrote:
| Application code appears to be a small fraction compared to
| storage, databases, and various operational overhead:
| https://m.signalvnoise.com/only-15-of-the-basecamp-
| operation...
| jpxw wrote:
| I'd be interested to know at what point the energy required
| for me to write in C (with a significantly longer development
| cycle, and thus more commutes, more time powering the office,
| more time running test harnesses, etc) would be outweighed by
| the gain in its energy efficiency over <insert other
| language>.
| saagarjha wrote:
| A lot of "I'm not productive in $LANGUAGE" is often "I
| don't know $LANGUAGE" very well, not "$LANGUAGE is
| inherently worse". However, if you subscript to the idea of
| blub programming and such take a look at C++ or Rust.
| Jtsummers wrote:
| "It takes me longer in $LANGUAGE" != "I'm not productive
| in $LANGUAGE"
|
| Some things are just faster to develop in some languages
| because they have different base-line capabilities. Try
| parsing and processing a lot of text input in C versus
| the same task in Perl. Assuming similar competency in
| both languages (hell, you don't even have to be fully
| competent in Perl for this, just not a total novice) and
| the Perl solution will come out faster unless you've
| already spent a lot of time doing _specifically_ text
| parsing and processing in C (which is not its primary
| use-case for many, if not most, day-to-day C
| programmers).
| jcelerier wrote:
| > with a significantly longer development cycle,
|
| is that the case though. I used to work in a company where
| we developped some apps in C++/Qt/QML and some others in
| Electron and for similar apps the development efforts were
| pretty much the same
| florimondmanca wrote:
| Your introductory point about share of lobal emissions is
| something I think we as an industry don't really realize yet.
| So, to give some more precise numbers about that...
|
| > data centers contribute 3% of global greenhouse emissions
|
| Not true according to my research [0] -- more like _Tech in
| general_ contributes ~4% of global GHG emissions. Within that,
| datacenters only represent ~20%. (The rest is 15% for networks,
| 20% for consumer devices consumption, and the remaining 45% for
| manufacturing of equipment.)
|
| And also:
|
| > (same amount as the entire airline indistry).
|
| Air traffic accounts for ~2% of global GHG emissions [1], so
| Tech is actually _twice_ as bad as air traffic there. Other
| ways to put it is: as much as all trucks on the planet, and 4x
| emissions of a country like France.
|
| [0]: https://theshiftproject.org/wp-
| content/uploads/2018/11/Rappo... (FR) (p18, p20)
|
| [1]: https://www.atag.org/facts-figures.html
| beached_whale wrote:
| I would love to see the one where they do CRUD'y things or do
| data transformations which seem to occupy a large part of compute
| power.
| wmf wrote:
| I'd predict that it would look very similar to the TechEmpower
| benchmarks.
| StillBored wrote:
| So, the Steve Jobs rumor about only allowing compiled programs on
| the original iphone was right? There is about a 4x energy
| increase going to a VM'ed language and about a 19x going to a
| fully interpreted one over using a natively compiled language.
|
| So, the energy efficiency is actually worse than the perf loss in
| general.
| gameswithgo wrote:
| Doesn't just save battery but leads to more responsive
| interface, which people noticed.
| transfire wrote:
| No Forth :(
| dleslie wrote:
| I wonder what the carbon impact the use of those inefficient
| dynamic languages has had, in both desktop and backend
| environments?
|
| I imagine it's substantial and worth considering.
| sk2020 wrote:
| Think of how much electricity is spent on cryptocurrency
| grifting, training state of the art AI so that it can help
| trick the elderly into clicking on ads, distributing porn, and
| streaming videos of kids eating tide pods. I think that
| eclipses the cost of developers using Rails or Django for their
| server backend.
|
| I don't think we have a problem with the "how" as much as the
| "what" or "why".
| jeffbee wrote:
| I bet it is completely insignificant in the great scheme. The
| average American, for example, uses the equivalent of 4 kW of
| motor fuels continuously, not even counting electricity
| consumption. It doesn't amount to a hill of beans if the
| Dropbox sync client uses an extra joule here and there because
| it's written in Python instead of C++.
| [deleted]
| jcelerier wrote:
| > The average American, for example, uses the equivalent of 4
| kW of motor fuels continuously
|
| how is that possible ? I have a normal house with a few
| appliances turned on, plus three fairly powerful computers
| and some musical gear and I'm at 530VA right now according to
| my home's electricity meter
| callalex wrote:
| Have you ever purchased anything from a store? How did that
| good get to the store?
|
| Have you ever purchased anything online for home delivery?
| How did that good get to the delivery center, then your
| home?
|
| Just because you didn't pump a gallon of gas into your
| personally owned tank doesn't mean it wasn't burned on your
| behalf.
| jeffbee wrote:
| But how do you move yourself from place to place?
|
| Note that it's not necessary for you to personally burn the
| three gallons of fuel per day. It's an average.
| jcelerier wrote:
| I drive on average 8k kilometers per year. I doubt that
| this is amounting to all the rest, is it ?
|
| a quick computation gives me, given that my car drinks
| roughly 7 liters of diesel / 100km if i'm not careful:
|
| - 560 liters of diesel / year
|
| - a liter of diesel is apparently ~10.74 kwh -> 6014 kwh
| total
|
| - 6014 / 365 -> 16 kwh a day ? I don't see how this is
| making me any closer to 4000 kwh per day.
| layoric wrote:
| I don't know if the 4kW statistic is right but 16kWh per
| day is 0.667kW continuous (16kW / 24 hours).They
| specifically say not including electricity use but could
| see that continuous number climbing closer to the 4kW
| number if it did.
|
| People who regularly fly would also likely quickly make
| this number rise.
| jeffbee wrote:
| By your metric ways I see you might not be an American.
| However, you can readily divide the total motor fuel
| consumption in the US by the population in the US, and
| use your figure of energy per liter (which is a bit
| higher than pertrol, but it doesn't matter).
|
| The point is that the global emissions story boils down
| to transport fuels, meat, leaky houses, and a long tail
| of irrelevant things, such as your choice of programming
| language at small scale.
|
| At large scale the economic incentives alone are enough
| to encourage huge energy consumers to use a decent
| language (for example, Google and C++). But the whole
| information industry taken together is irrelevant to the
| global emissions story as long as we have an airline
| industry, cars, and hamburgers.
| liuhenry wrote:
| US Department of Transporation says the avg. American
| drives 13.5k miles per year.
|
| Using an average mpg of 21.5 mpg (if the average age of a
| car is 12 years), this comes to ~628 gallons of gas per
| year.
|
| EPA uses 33.7 kWh per gallon for ~21,160 kWh in a year.
| Divide by 360 * 24 and you get 2.5 kW continuous, so it
| seems plausible.
| Jtsummers wrote:
| It likely only matters if you're computationally bound. Many
| (most?) of our uses of computers are IO bound, instead. So some
| degree of inefficiency in the use of CPUs is probably not as
| bad as things like the unnecessary round-tripping of data (or
| constant retrieval) over long distances.
| open-source-ux wrote:
| When PHP 7 was released, Rasmus Lerdorf, the creator of PHP,
| said the performance improvements meant fewer servers, smaller
| memory use and reduced CPU activity - all of which equalled
| less power or electricity consumed. (And remember this is an
| interpreted language.)
|
| When you consider the millions of servers in use, that
| additional language efficiency adds up to a substantial saving
| in electricity use. You can watch a segment from his
| presentation where he talks about this here - and the
| calculations he made of potential CO2 savings:
|
| https://youtu.be/umxGUWYmiSw?t=15m16s
| drmeister wrote:
| Lisp (Common Lisp) beats all the other dynamic languages by a
| considerable margin. This is why I am developing Clasp - a Common
| Lisp implementation based on LLVM that interoperates with C++/C
| (https://github.com/clasp-developers/clasp.git) for scientific
| programming.
|
| With Clasp, we get the best of multiple worlds. We get a dynamic
| language (Common Lisp) with automatic memory management and
| enormous expressive power that can directly use powerful C and
| C++ libraries. All three of these languages are "long-lived"
| languages in that code that was written 10 and 20 years ago still
| works.
|
| Performance is really important to me and I have written a lot of
| code over the past four decades. I won't develop meaningful code
| in any language that falls below Racket in table 4 because these
| language implementations are too inefficient. I furthermore want
| to keep using my code over the years and decades and so I won't
| develop meaningful code in any language where someone else can
| break my code by changing the standard. My program "leap" was
| written 27 years ago in C and it is still being used daily by
| thousands of computational chemists. But it's really hard to
| improve leap because the code is brittle largely because of
| malloc/free-style memory management (brrr). For a compiled, high-
| performance, standard language with proven lasting power and
| performance - Common Lisp is the best choice.
| agumonkey wrote:
| I'm often surprised how sbcl is 'benchmark' competitive with
| other native langs (c, ada, pascal)
| drmeister wrote:
| SBCL is an amazing implementation and it has an amazing
| compiler. I would argue that it is one of the best compilers
| around. Javascript compilers in browsers are pretty
| impressive - but given the far fewer resources that SBCL
| development has had, SBCL is remarkable. It's a fast compiler
| that generates fast code. I would be using it (and do for
| some applications) if I didn't also need my own large C++
| computational chemistry code written over decades.
| agumonkey wrote:
| yes sbcl is "only" a tiny impl. Makes me wonder how far
| franz or other can be .. you know how chez-scheme was
| leagues above the other implementations while nobody knew
| until it was open sourced
| lliamander wrote:
| Depending upon how you define "dynamic" Java wins by a small
| margin.
|
| If we treat "dynamic" as a spectrum though, Lisp still gets you
| a lot more dynamism for a relatively small increase in power
| consumption (and a somewhat larger gap in performance).
| drmeister wrote:
| Hey - props to the developers of Java for bringing automatic
| memory management into the mainstream. But it's not quite
| what I'm looking for when I want to do exploratory
| programming.
| lliamander wrote:
| Agreed - on both fronts.
| sk2020 wrote:
| Given that most of the computationally expensive work in Python
| is usually offloaded to C extensions (and JIT compilation is an
| option with Python), is the cost savings in electricity that
| significant? A desktop PC probably only costs about 10 cents an
| hour to run at most.
|
| Perhaps your interest in CL is because you can recall using it
| in its prime. Nostalgia Or just novelty is certainly a valid
| argument.
| 7thaccount wrote:
| Didn't you do a talk on YouTube? I recall watching it when you
| went over the computational requirements of doing something
| with molecules maybe? I don't work in that field, but remember
| it being interesting enough to watch the full thing.
| drmeister wrote:
| I do have a couple of talks on YouTube and thank you (the
| most recent one:
| https://www.youtube.com/watch?v=mbdXeRBbgDM). Yes - we are
| building molecules using our code. I have started a company
| and we are several months in to developing a new technology
| for warding off future pandemics (maybe even doing something
| about the current one). We literally started compiling the
| first molecules using an application I implemented in Cando
| (Clasp + computational chemistry) yesterday.
| 1980phipsi wrote:
| It would be good to make the slides available.
| jedbrown wrote:
| Is better C++ interop the motivation for Clasp over Julia
| (which has lispy roots and CLOS-like open multimethods, though
| not lispy syntax)? Julia is conspicuously missing in the
| benchmark, but should do pretty well if you don't include
| JIT/start-up time.
| drmeister wrote:
| If the question is why not use Julia? The answer is - for
| several reasons. I started implementing Clasp before Julia
| was a thing. The Julia language keeps changing and it doesn't
| have a standard like Common Lisp, C++ and C do. I need tight
| C++ interoperation and Clasp does C++ interoperation like no
| other language I've see. Clasp uses C++ exception handling
| and calling conventions and this allows us to compile and
| link C++ code with Common Lisp - it's all LLVM under the
| hood. Clasp stack frames and C++ stack frames are interleaved
| and try/catch and RAII and Common Lisp unwind-protect and
| dynamic variable binding work perfectly between C++ and
| Common Lisp code.
| 6keZbCECT2uB wrote:
| Would it have been feasible to improve the FFI of existing
| common lisp implementations? The last talk of yours that I
| watched showed clasp to be slower than common lisp relative to
| C.
| drmeister wrote:
| There was a time when I asked myself that every day (sigh).
| But I don't think so. The details involved in interoperating
| with C++ are so intricate and involved. I don't think I could
| have gotten to the same place. Meanwhile - we are improving
| our compiler performance and the performance of generated
| code. Maybe in the far future I'll start a couple of ancestor
| simulations and do the experiment...
| gok wrote:
| previously https://news.ycombinator.com/item?id=15249289
| stephc_int13 wrote:
| Marginal differences should be ignored in this kind of benchmark.
|
| It is usually well accepted that faster execution leads to lower
| power usage, as long as the CPU is operating in a reasonable
| thermal envelope.
|
| Nothing new here, except that we can have a better grasp of the
| different orders of magnitude.
| leothekim wrote:
| This appears to have been published in 2017?
___________________________________________________________________
(page generated 2020-09-30 23:00 UTC)