17 ms·
Which Programming Languages Use the Least Electricity? (2018)
- mtreis86 8y agoWhich lisp? Those numbers don't seem right from my experience with SBCL.
- mftrhu 8y agoThe data for the paper the article talks about is online [1], and it says [2] that the benchmarks are "implemented in 28 different languages (exactly as taken from the Computer Language Benchmark Game)". The LISP evaluated by the Benchmark Game - and, apparently, this paper - is indeed SBCL [3], which seems about on par with Java. “Lisp, on average, consumes 2.27x more energy (131.34J) than C, while taking 2.44x more time to execute (4926.99ms), and 1.92x more memory (126.64Mb) needed when compared to Pascal.” [1] https://sites.google.com/view/energy-efficiency-languages/home https://sites.google.com/view/energy-efficiency-languages/ho... [2] https://github.com/greensoftwarelab/Energy-Languages https://github.com/greensoftwarelab/Energy-Languages [3] https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- 4thaccount 8y agoI think this is what is so cool about Common Lisp. You can literally get pretty darn close to C in performance and still be at the highest levels of development efficiency/prototyping speed. I don't think too many other languages can say so. Take Python. It has really fast development time, but very slow performance.
- voldacar 8y agoC and Haskell were about what I expected, but those Pascal results have me scratching my head, given that it performed about as well as C and used even less RAM.
- jandrese 8y agoPascal and C are roughly equivalent in my eyes, at least as far as what they spit out in the end. Both have pretty similar feature sets and development methodologies. What surprised me is how much of a hit the OO programs took. I had thought they would compile down to something reasonably similar to the imperative languages, but C++ ended up being 50% slower.
- kbenson 8y agoInteresting results, but I think the farther you go down the list the more the fact that you're using the Computer Language Benchmark Game affects what you're seeing, as not all languages get the same attention. For example, Javascript and Typescript. Theoretically, I would assume those to be very close, since one compiles to the other. And for memory usage, they are very close. But for running time, Typescript is an order of magnitude slower. That looks suspiciously like entirely different algorithms were used in each implementation (with one being obviously superior in terms of performance), and if that's happening in this specific case, where else is it also causing problems in the analysis?
- gameswithgo 8y agosubmit a better implementation. it is not possible for any one entity to produce optimal implementations for many languages, it is up to us. or, if you dont like their rules, make your own benchmark system with new rules.
- kbenson 8y agoI 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 and effort put into optimizing it. It serves its purpose about as well as can be expected. Unfortunately, using it as the base of further calculations can lead to some of the known quirks of the benchmarks being exaggerated into results that are not always obviously an artifact of the underlying system, as I suspect this is. Making that obvious by pointing it out can be useful.
- gameswithgo 8y agoit is absolutely a flaw in the methodology, but one I think is unavoidable without enormous resources.
- forgot-my-pw 8y agoPHP's performance is quite impressive nowadays. It's one of the top fastest interpreted languages.
- jrwr 8y agoFor how much shit PHP gets, it is a pretty good lang for building things
- ashton314 8y agoI'm curious: I've used PHP (not by choice) for the past two years and I strongly dislike it. (I could wax eloquent on this subject, but I don't want a flame war. :) What do you see of value in PHP? Is it the language itself? Its ecosystem or community?
- sys_64738 8y agoNo COBOL?
- tapland 8y agoSeeing to the amount of transactions running over cobol it might deserve a place in a list like this.
- bastawhiz 8y agoIf you're still using COBOL, power usage is likely very low on your list of concerns
- tapland 8y agoNo? Just about any financial transaction, insurance calculation and a lot of telcos operations run mainly of cobol. Something like 90% of all credit card transactions.
- bastawhiz 8y agoYou can throw money at electricity use, and COBOL is compiled to machine code so the power usage is much less of a concern than it would be in an interpreted language. Much higher on the list of concerns is finding capable COBOL developers, ongoing maintenance, and security. Those are all things that you can't just throw money at.
- kissgyorgy 8y agoNot sure how serious they think this is, and how much is this rather a joke. If it's not a joke, they clearly not see the big picture. For example if you can write a software in a higher level language in a fraction of the time which will spare energy somewhere else in the world, it will use less electricity overall.
- nydel 8y agoi suppose every attempt to figure out which is the best text editor, unix-like os, programming language etc is even more futile than most human endeavor :)
- basementcat 8y agoIt depends. If you're writing a math kernel that will be deployed to a billion IoT devices each with a lifetime of 10 years, you may want to spend some more developer time to shave a few cycles in assembly language. If you're writing some single-use script to automate a single job, do it in the easiest high level language with the library support that you need.
- howiroll 8y agoFor battery powered devices, I suppose, but for plugged in applicants No.
- dahart 8y agoHow 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.
- quickthrower2 8y agoNot everyone works for FAANG. Energy usage doesn’t even come up at most small shops. Cloud hosting costs might, but only if they are really out of whack.
- crimsonalucard 8y agoAssembly language is the lower bound here. This is a 100% correct fact that nothing can use less energy than assembly language. No such statement can be made about other languages.
- geophertz 8y agoNot necessarily. Sometimes compilers give better programs than a programmer can with optimization and stuff.
- crimsonalucard 8y agoRight but if I write a program that converts code into assembly and does the optimizations automatically then I can get something better or equal to a compiler.
- dragonwriter 8y agoIsn't that exactly a compiler?
- crimsonalucard 8y agoYes. And all of my statements are 100% correct except for this one.
- timbit42 8y agoCompiled Forth would give Assembly a run for its money and produce smaller code as well.
- crimsonalucard 8y agoBut could forth beat compiled Assembly language? I think not.
- stareatgoats 8y agoNot sure what to make of this research. It's not like I can switch out JS in favor of these other languages (many of which are compiled binaries) in my web apps. The performance of for example web servers written in the different languages entirely would seem more interesting to compare. The JS/TS comparison was directly fishy. I found no mention in the paper of how they managed to "run" the tasks in Typescript, which AFAIK is not possible, or at least not how one would do it in a real life.
- snek 8y agoMaybe you can switch it out :) https://webassembly.org/ https://webassembly.org/
- blihp 8y agoJust use it as another ballpark reference of what trade-offs are being made when going with one language or another. Not really any different than any other language benchmark/shootout comparison. Unless you have very large numbers of [users|servers|whatever] to amortize the cost of going one way vs another over, it's probably not worth even considering trying to change anything on your end. More likely, your personal or team productivity is the much more important metric to optimize for anyways. If you're doing things at FAANG scale, it's an entirely different story.
- Barrin92 8y ago>Not sure what to make of this research. It's not like I can switch out JS in favor of these other languages Nope but for iot devices or anything in a scenario with scarce energy resources or difficulty to remove heat it's an interesting datapoint. Although I think the results conform mostly with intuition. I doubt anybody would voluntarily compile a lot of haskell on their space satellite
- jayd16 8y agoSo do we think Java is benefiting from J2ME and Android research? Is it just a coincidence?
- dahart 8y ago> A faster language is not always the most energy efficient My rule of thumb now is that memory access, not compute, is the primary consumer of energy. That would tend to confirm the above statement while also supporting the data that scripting languages aren’t super energy efficient, since they tend to do a lot more dynamic allocation than compiled languages, when generally broadly speaking about common programming practices in each language. This is mainly colored by GPU usage and a paper/presentation some friends made: https://www.researchgate.net/publication/324217073_A_Detailed_Study_of_Ray_Tracing_Performance_Render_Time_and_Energy_Cost https://www.researchgate.net/publication/324217073_A_Detaile... In the GPU case, memory access costs sometimes 10x more than compute, meaning that minimizing average (not peak) memory traffic is more or less the only path to significantly reduced energy. (See figs 7 & 10 in the linked paper)
- mehrdadn 8y ago"Costs more" in terms of energy per... what quantity exactly? Instruction executed? Clock cycle? Datum processed?
- dahart 8y agoIn the paper it’s energy per rendered pixel. You could translate that abstractly to watts per flop.
- deleted 8y ago[deleted]
- hermitdev 8y agoI think practically, for useful analysis in business it would be wattage per unit of useful work (or datum processed as you suggest). For instance, I work in finance, so what is the wattage per option price calculation?
- mehrdadn 8y agoThe reason I asked was that it wasn't clear to me if the parent comment was measuring the same way or not re: memory accesses. It seemed pretty expected that a memory access would be more expensive per byte (it takes like hundreds of clock cycles...) but it wasn't obvious to me if it would be so per clock so I wanted to clarify which was meant.
- wolfgke 8y agoNo mention of assembly language, which should be even lower on electricity and RAM usage than C and Pascal.
- ddingus 8y agoI would like to see that benchmarked.
- userbinator 8y agoYes, I was looking for "carefully optimised Asm" on that list too. Even if it's not faster it will pretty much always be smaller. (Compilers are surprisingly easy to beat at size optimisation.)
- makapuf 8y agoWell -Os can be a bit better. However I doubt program size is very significant compared to data size in Compiled languages by example.
- hn_throwaway_99 8y agoHow does "TypeScript" come out to an energy score of 21.50 when "JavaScript" has a score of 4.45 - that makes 0 sense.
- snek 8y agomaybe they included compilation? it would make sense as that's a real world use of cpu/memory/energy.
- hn_throwaway_99 8y agoBut it certainly looks like they didn't include compilation time for all of the compiled-to-machine-code languages. C has the reference value of '1'.
- jandrese 8y agoI think they included compile time if the code is JITed at startup.
- quickthrower2 8y agoWhat about the energy fixing bugs in JS that Typscript found at compile time?
- recursive 8y agoStill doesn't make sense. Build one time, run many times.
- kakarot 8y agoIf I'd hazard a guess before reading the article, it's because of the transpilation phase to regular Javascript. That doesn't come for free.
- prickledpear 8y agoTheir typescript compiler may not be targeting the correct ecmascript version so the typescript generated could be using polyfills instead of native features.
- deleted 8y ago[deleted]
- aheilbut 8y agoAre they counting the electricity used to heat the pizzas that feed the programmers?
- jandrese 8y agoThis was said half in jest I suspect, but it's not a completely off the wall concern. For an infrequently used program the energy burned in its development could easily be a nontrivial amount of the total energy used over its lifetime. If you can write a 5 line Perl script that gets the job done (and is only run a couple dozen times ever), then you're probably saving energy over the 100 line C program despite the massive differences in runtime energy consumption.
- aheilbut 8y agoPhew, somebody gets it.
- Kaveren 8y agoReally silly to state how much electricity "languages" use without specifying implementations. You can specify for unstandardized languages, but languages don't have performance characteristics in the typical sense, implementations do, and this can very greatly between implementation.
- igouy 8y agofyi https://sites.google.com/view/energy-efficiency-languages/setup https://sites.google.com/view/energy-efficiency-languages/se...
- Mugwort 8y agoThey should include Julia in the results.
- howiroll 8y agoManhour >>>>> energy, memory or time. If for the same job i need 100 manhours in python and 1000 manhours in C I’d indefinitely use python. Interesting but useless report.
- xiphias2 8y agoThe heavily parralelized C in the language shootout is not how most code is written. Rust was specifically created to use the paralell hardware resources well, and it excels at it.
- osrec 8y agoI'm a little surprised at where Erlang features in the list. I've never used it personally, but have heard so much about it being an amazing, performant language. I wonder why it's so time/energy/memory inefficient for the algorithms used in this exercise.
- erik_seaberg 8y agoIs this the cost of restarting processes due to "let it crash" error handling?
- osrec 8y agoNo idea, but I doubt it if they're testing with well defined algorithms. I can't imagine the tests throwing lots of errors.
- chris_st 8y agoErlang's use case is handling lots of connections simultaneously, and messaging between processes. These benchmarks are all single-threaded, pure computation. Erlang is pretty slow at that (alas).
- elcritch 8y agoI’d certainly put Erlang (and Elixir) in the class of scripting languages. In that category it beats out most of the other classic scripting languages like Python, Ruby, Perl, and Lua at execution speed and energy usage, aside from JavaScript and oddly PHP. For being a mostly pure functional language it performs pretty well in that category. To the parent comment’s question, the reputation for solid performance likely comes from Ruby/Python developers. When dealing with web server applications it really shines due to how it handles concurrency. Also NIFs are really easy to write, especially in Rust.
- 4thaccount 8y agoIt's built for massively distributed systems and is efficient at that I believe. It's not really designed to be a replacement for numeric languages like C/C++/Fortran/Ada...etc. It's a high level language, so what you gain in user development efficiency, you lose in performance. Someone knowledgeable in Erlang could confirm though as I'm being general.
- jajag 8y agoCan anyone extract what the impact of a JIT compiler is on these figures? The initial performance hit is eventually eroded by the runtime optimizations, so will a long-running Java program eventually close the energy performance gap on a C program?
- oblib 8y agoThe big surprise for me is where Perl stands in the rankings, below Javascript in all three tests.
- ashton314 8y agoAmen: I'd have to take a look at the actual code in use.
- igouy 8y agoYou can, the authors of the paper provide the actual code they used on their website.
- alangpierce 8y agoJavaScript usually runs quite a bit faster than other dynamic languages (after JIT warmup), not because it's fundamentally any faster, just because modern JS engines are so good. Browser competition has meant that the amount of engineering work put into JS performance is much, much more than just about any other language.
- m463 8y agoReversible computing should be mentioned, as it could be the holy grail of low energy use. https://spectrum.ieee.org/computing/hardware/the-future-of-computing-depends-on-making-it-reversible https://spectrum.ieee.org/computing/hardware/the-future-of-c...
- jmartinpetersen 8y agoAlmost 20 years ago I took courses under a professor who was very into reversible computation. As I recall it was mainly on the language side, though. Glad that it's still moving, sad that it's at an even slower pace than the "functional/immutable will save the parallellization worries" stuff I encountered in the same period.
- mceldeen 8y agoIt almost sounds like reversible computing is immutability at the hardware level.
- pauljurczak 8y agoThe language which uses the least energy is the language no one writes programs in.
- codesushi42 8y agoThis study is a bit silly, I had to check whether it was an April Fool's joke. The chipset running the instructions is going to have a far higher impact on energy usage than the language compiling those instructions. For instance, switching to ASICs or even FPGAs that are optimized to handle certain types of computations. Just look at datacenters or mobile devices. Sure, optimizations are made to runtime environments to improve performance, and increase battery life. But you are going to see bigger gains through chip architecture. And that is what vendors focus on.
- codesushi42 8y agoTo the naysayers: these languages are either compiled, or will be JIT'ed at runtime. What they will be compiled to will be chip specific binaries-- x86, ARM, whatever. The energy usage will be markedly different depending on which chip architecture is chosen, and will no doubt be inconsistent between different architectures and languages. Or to put it another way. Why do you think mobile devices almost exclusively use ARM? Why do datacenter operators invest heavily in R&D for ASICs instead of engineering new languages or runtimes? Because languages play a secondary role in energy consumption. This study is just like countless of other meaningless benchmarks seen in language war flame posts. Pointless and misses the big picture.
- Nvorzula 8y agoWith regard to datacenter operators, I would argue that a simpler answer to that observation is that they are investing heavily in the are in which they can actually effect change. That is, they can swap in-and-out their hardware, but language of choice is largely up to their customers - the dev. They can advocate and champion a particular language, but really enforcing it in any meaningful way is narrow casting their own user base.
- codesushi42 8y agoThey could offer their own compilers or runtimes. Some big companies do. But most dollars and time is spent on hardware R&D and upgrades. Facebook and Google both have in house chip designers these days, specifically for their data centers.
- z3t4 8y agoFor example on a server the CPU will likely be set at full thrust even if it has nothing to do. So I don't think this matters until you need to scale, where you would need less servers/power with a more optimized program.
- techspreader 8y agoHope that the cloud providers don't bill according to energy consumption. I like Python a lot...
- eastern 8y agoThey 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.
- monkeyshelli 8y agoThat sounds pretty damn nice - would you happen to have a good link in mind for reading more on the subject?
- makapuf 8y agoWhat'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.
- eastern 8y agoSorry 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.
- makapuf 8y agoThanks this comment is useful, client side integration is integration after all, and I think if it was simple, you would have it done differently (if I understand your words correctly - "cheating").
- amelius 8y agoAren't the savings more in the type of application? For example, driving users to addictive content makes them use their phone more. Also, Bitcoin comes to mind.
- NowThenGoodBad 8y agoTo me, the amount of electricity used is a similar issue to RAM. Just because we have computers with more RAM does NOT mean programs NEED to use that RAM. So many applications right now that don’t need as much memory as they are using but, whether it be lazy or poorly planned code or any other excuse, they guzzle it up like they are the only application running on your device. I’m all for figuring out what’s the most efficient option while also ensuring it’s an effective one as well. If you kept a knife in its sheath to keep it nice, but never take it out to use it, then it’s not servicing its purpose as a tool (ignoring ornamental ones). However, no matter how cool it might seem, you really don’t need a samurai sword to pear apples.
- abalone 8y agoCouple 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 level. Think about it: You, brave software engineer, can literally make a significant contribution to saving the world by adopting a more energy-efficient language, if you are fortunate enough to deploy something at scale. 2- Rust is killing it in these metrics but developer productivity / friendliness is important to overall success. Looking at these results I have a conjecture that is maybe provocative: The top two candidates for long-term success at supplanting Java on the server in my eyes are a) Go b) brace yourself.. Swift Swift is extremely young on the server, to the point where I'd expect your natural reaction to be "WTFLOL?! never heard of it". But here's some food for thought: the Netty team, one of the top performing Java server stacks, has been recruited by Apple and is chewing through all that stuff and just launched their NIO2 release[1] which I've heard is already very close to Netty. Go has an amazing concurrent garbage collector and has really pushed the envelope with that.[2] Swift is unique in the server world in that it uses reference counting which sidesteps the whole GC collection problem, which could translate into very low, very consistent latencies as well as memory usage. It's still quite early days for Swift, but these are the two languages I'm watching the closest. [1] https://forums.swift.org/c/server https://forums.swift.org/c/server [2] https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote
- mises 8y ago> Swift That's a pretty cool idea. I read something on HN the other day about using swift in the back end, but haven't used it myself. Hopefully Apple gets support for non-ubuntu linuxes as well as windows out the door (especially since they're no longer making their own hardware). I've heard anecdotally that it has very slow compile times, so that might be another issue. > Swift is unique in the server world in that it uses reference counting Out of curiosity, why has no-one done automatic reference counting on the server side before? C++11 has smart pointers, and I believe python does as well (can't speak to this one personally). I also feel like most languages using the llvm backend could achieve performance at least close to c++; wasn't that part of the purpose? It seems like Swift might be especially ripe for this because Apple is the big developer of both LLVM and Swift.
- bhauer 8y agoVery interesting! We have wanted to do a similar conversion from the results data in our TechEmpower Framework Benchmarks [1] to energy efficiency. I've wanted to go as far as converting watt-hours to some average carbon emission rate for electricity generation in a given region. I imagine the carbon emission per request would be amusing, if nothing else. [1] https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
- raz32dust 8y agoThe code size metric was pretty interesting to me. I would have imagined that functional programming languages should lead to the most succinct code. But I was surprised to see Haskell in the middle, and Go at the top there! Functional languages are right in the middle for all 3 metrics.
- userbinator 8y agoUnfortunately there are no APL/array languages there, they are notorious for being succinct! It's not a stretch to say "lines of code" in most other languages would be close to "characters of code" in APL. It'd be interesting to compare it using the other metrics too.
- goatlover 8y agoNo Julia or Crystal, that's disappointing.
- mlthoughts2018 8y agoI always feel like there is a big misunderstanding of what it means to “write a program in some language” in these types of comparisons. For example, saying that Python uses much more energy is a foolish thing to say. The “same” algorithm written in pure Python is a very semantically different thing. It involves allocation of flexible objects that obey certain attribute lookup protocols, operator protocols, dynamic attribute mutation / creation, iteration protocols, etc. It is presumed that if you wrote in pure Python, you need this dynamism and ability to introspect at runtime, modify data structure layout arbitrarily, utilize an automatic garbage collector, etc. So you’d need a benchmark test that requires all that functionality before it could possibly make sense to test Python. Otherwise you’re penalizing Python for a bunch of expensive overhead, which is totally unfair and foolish because the whole point is that such overhead exists for use cases where either the costs are negligible or the flexibility that necessitates that overhead in any language happens to be a desired and important part, such that to write the same functionality in other languages would first require building all the protocols, garbage collection, etc. machinery that essentially defines Python. If instead you have some benchmark problem that can be solved in e.g. C or Rust without needing any runtime dynamism or heavy machinery of certain protocols or garbage collection, then to write it in Python you would just write it in Cython or as a hand-made C extension module to specifically bypass the overhead of the interpreter or Python protocols / dynamic lookups / etc. Basically, it never makes sense to compare Python and C on a benchmark that doesn’t require reimplementing most of Python in C first. Because to solve that problem in Python, the ubiquitous, basic, Python 101 way to do it would be to use Cython or numba or write your own extension module. Python is basically a special C language DSL for dynamic types, garbage collection, and a set of conventions and protocols. “Pure Python” is a linguistic trick for saying “a huge ton of tools that make C-level polymorphic structs easy to use.”
- mempko 8y agoYes except some people are using python where they should be using C++ and powet consumption is a good reason not to use python in these cases.
- mlthoughts2018 8y ago
- v_lisivka 8y agoI improved Rust's version of binary-trees by about 0.05s (on my CPU): https://salsa.debian.org/benchmarksgame-team/benchmarksgame/issues/113 https://salsa.debian.org/benchmarksgame-team/benchmarksgame/... , so Rust score may rise.
- arduanika 8y agoCan't run Rust without powering the HN servers, to host the screeds of its acolytes. I jest, (and I'm a Rust admirer myself), but my more serious point is: so many different kinds of electricity go into a plush tech company with its well paid developers and our copious brain food that powers us through all our developing and debugging. If you want to talk about sustainability, ask about the lifecycle maintenance of a software base. These benchmarks are cute, but academic, and only tenuously related to any green solutions. Especially if people in this thread are taking this seriously in terms of "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", then this is an feels like an awful, awful way to measure it. What language is most conducive to writing algorithms that are smart in terms of Big O, or designing systems that can be refactored intelligently instead of throwing boxes at the problem?
- davedx 8y agoScala is a nice sweet spot. Good type system, solid for refactoring, good for expressing algorithms. You burn tons of CPU compiling but that’s one dev footprint. Anyone from Twitter care to comment on this?
- Proven 8y agoThe dead ones use the least power. In other words, other things being equal, the more power a programming language uses the more useful it has to be (by, for example, saving power or time). If it's not, its use will not be higher than its economic benefit.
- bibyte 8y agoSo Rust is a little bit more efficient then C++. That's kind of surprising. And I knew Lisp was fast but I am still surprised it scored so high.
- bsenftner 8y agoNow, seriously: C and the boogieman of managing your own memory is a myth. Anything you want from another language can be built up from C, and be in your direct source code control working in C. Far too much propaganda is written telling programmers perfectly capable of the gains from working in C that they should be afraid of working with their own memory allocations. As if being organized is impossible.
- tannhaeuser 8y agoLanguage runtime analysis for server-like programs seems obsessed with putting everything into a single process and address space. With C/Unix, traditionally or at least since inetd, the way to go is start a fresh process per request, which mostly just solves the problem of manual memory management (eg. because the O/S clears up the mess you left behind), at the price of latency. I'd like to see a benchmark comparing these approaches, since gc is far from being free of overhead either.
- the_why_of_y 8y agoHow would that prevent any of these CWE-415 or CWE-416 vulnerabilities? https://www.cvedetails.com/vulnerability-search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=415&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem= https://www.cvedetails.com/vulnerability-search.php?f=1&vend... https://www.cvedetails.com/vulnerability-search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=416&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem= https://www.cvedetails.com/vulnerability-search.php?f=1&vend... Pedantic note: quite a few of these vulnerabilities don't technically contradict the GP's claim because they're in C++, not C, but I hope there are enough C ones to disprove the point.
- userbinator 8y agoBut at the same time, when manipulating strings with regular expression, three of the five most energy-efficient languages turn out to be interpreted languages (TypeScript, JavaScript, and PHP), “although they tend to be not very energy efficient in other scenarios.” I believe that's because they're all using a regular expression library which is probably written in C/C++, maybe even with some pieces in optimised Asm, so none of the actual RE-work is being done in the interpreted language itself. If you wrote actual RE processing in the interpreted language and let the interpreter interpret/JIT it, I bet they would be as (in)efficient as the "other scenarios" where the "heavy lifting" is running through the interpreter.
- seaish 8y agoQuestion: if these were run on underclocked hardware, would they use less energy? It seems like you'd need an increasingly large amount of energy to run something in a smaller amount of time.
- pulketo 8y agovery stupid but clickbaiting question... everything wastes everything...
- RobLach 8y agoWhat does “everything wastes everything” mean?
- alexott 8y agoI really wonder that FORTRAN is so bad - I think that they didn’t try good compiler, like Intel’s
- igouy 8y agofyi ifort 17.0.3 https://sites.google.com/view/energy-efficiency-languages/setup https://sites.google.com/view/energy-efficiency-languages/se...
- stewbrew 8y ago“On average, compiled languages consumed 120J [joules] to execute the solutions, while for a virtual machine and interpreted languages this value was 576J and 2365J, respectively.” IMHO it's not quite right to evaluate energy efficiency just by looking at the runtime performance. Compiled (incl. JIT) programs have to be compiled. So for compiled programs, you have upfront costs (e.g. rust, haskell much more than c), you would have to include in the calculation. Then you have programs/script that run once (a day maybe). I wouldn't be surprised if taking this into account would change the calculation.
- Too 8y agoIs JIT, interpreter and VM startup time included? Some benchmarks finish in just a few seconds. With Python for example just launching the process takes in the order of 100ms, which would be significant time in such short benchmarks.
- anonytrary 8y agoI did not expect Lua to be that far down the list. I thought Lua was a go to choice for scripting embedded software. Also, I'm not surprised that JavaScript outperforms most of the other scripting languages (according to this potentially erroneous benchmark).
- fit2rule 8y agoI also was disappointed that my favourite language did so poorly in these tests - I wonder, though, what the stats would have been like had LuaJIT been factored in. Perhaps something for future evaluation ..
- speedplane 8y agoHistorically, virtually every move up the abstraction level sacrificed performance to gain programming efficiency. Assembly to C, C to C++, C++ to Java, Java to Python/Javascript. And now there are wars over Javascript vs. Typescript, and jQuery vs. React/Angular. Every new step up the stack claims that the higher level of abstraction can either be implemented with only a minimal penalty, or could actually improve performance due to easier automated optimization. However, every time, it seems that in practical applications, performance is sacrificed to make software development faster. I don't know enough about the performance of Javascript vs. Typescript to form a strong opinion about it, but if history is any guide, it's likely that it improves software development efficiency at the expense of performance.
- vanderZwan 8y agoI mean, JavaScript comes out 4.5x slower and consuming 6.5x more memory. For TypeScript the numbers are 22x and 46x respectively. That honestly makes me very suspicious about the benchmark set-up.
- CapsAdmin 8y agoTypescript usually transpiles to javascript, just without the type information, and this is not done in the browser. If you target old browsers it can add maybe add some overhead like babel does. I don't know about javascript's usual JIT compilers, but LuaJIT's JIT compiler (trace compiler) does a pretty good job of figuring out abstractions.
- toolslive 8y agoIt would be interesting to match these results to what you get using EO-(efficiency-oriented)languages. (MOQA for example). There's a whole branch of computer science involved in static average-case analysis for algorithms and data structures. The results are 'interesting'.
- vbuwivbiu 8y agoI'd be interested to know the added energy cost (in terms of programmers) of writing the code in the first place and subsequently maintaining it * edit- thinking about it it's probably negligable
- marsokod 8y agoCost is a good first order proxy for energy used, so this is not negligible if you want to take into account all the energy used by the developer (including home activities). As for any other product, this is a trade-off between fixed and variable cost: want to do some quick processing on an hourly basis? Just write a quick python script with a Cron. Want to compute something billions of time? Use C or something more modern that compiles. Need even more savings? Build an ASIC doing the job.
- tomohawk 8y agoYMMV. Our experience with Go vs Java showed we could run the same workload on far fewer machines using Go than Java.
- tjpnz 8y agoHow is JavaScript so far up the list? Slack commits murder on my MBP battery every day.
- sod 8y agoUsing https://github.com/xtermjs/xterm.js https://github.com/xtermjs/xterm.js as an example (the terminal used in vscode), they draw on a canvas to achieve better rendering in the browser. So I guess not javascript is the cpu hogging bottleneck, but the complexety of html/css. There are just too many footguns that slows down the rendering. If there only was something like "use strict" for html/css.
- mlinksva 8y ago> We then gathered the most efficient (i.e. fastest) version of the source code in each of the remaining 10 benchmark problems, for all the 27 considered programming languages. I wonder if anyone has attempted to rate how idiomatic or typical CLBG entries are, and whether choosing the most idiomatic implementation for each language would have obtained different results?
- apta 8y ago> Of the top five languages in both categories, four of them were compiled. (The exception? Java.) Java is also compiled.
- deleted 8y ago[deleted]
- danielscrubs 8y ago"Of the top five languages in both categories, four of them were compiled. (The exception? Java.)" and "While Erlang is not an interpreted language." Had to check Wikipedia to make sure I haven't become crazy.