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.
51–60 of 267 posts
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.
Not 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.
It 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.
Assembly 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.
Not necessarily. Sometimes compilers give better programs than a programmer can with optimization and stuff.
Earlier quoted context omitted.
Not necessarily. Sometimes compilers give better programs than a programmer can with optimization and stuff.
Right 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.
Interesting 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…
I'd be very interested in seeing a few energy benchmarks not here, for example: energy to route 1B hits to a web endpoint, energy to parse a Json, energy to grab an auth token from a web request and forward to an auth server. Energy to forward 1M 1k files from the filesystem to the network, etc.
Earlier quoted context omitted.
You can write literally any JavaScript program with TypeScript (falling back to the `any` type if you really need to), so this doesn't really work in this case. Also, typical TypeScript programs are faster than typical JavaScript programs, because JavaScript JITs like predictable object shapes and monomorphic functions for the same reasons that other language implementations require them. Libraries like lodash and bl…
>typical TypeScript programs are faster than typical JavaScript programs Person who works on js engines here :) You would think this is the case, but in actuality, js and ts are about on par in performance (assuming similarly written code). This is in fact due to the fact engines optimize for idiomatic js patterns, not idiomatic typescript patterns. often these will align, but in some cases (usually revolving around…
Not 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.
How does less dev time save energy “somewhere else in the world”? Google & AWS pay money to develop & acquire technologies that save energy because of their scale. The energy used in dev is scratch compared to the energy used to run programs at scale. Google, for example, has a PHP compiler that makes all PHP web pages execute in a fraction of the energy usage of running the PHP interpreter.
Rust was specifically created to use the paralell hardware resources well, and it excels at it.
Earlier quoted context omitted.
> you’re using that assumption to cast slippery-slope doubt on the whole project without knowing anything specific. No! I think this is a very useful project and analysis. I just think that some languages might have extremely optimized versions (or possibly more likely, some languages don't quite yet have that extremely optimized version that has propagated throughout the others) and that might be affecting specific…
> I did not know if my concern was correct, and wondered if it was, what else it might affect. That’s exactly what I mean by casting doubt. If the concern might not be correct, why lead into speculation about further concerns? Let’s find out what the actual reason that TypeScript is measured slower, rather than guess as what else could be wrong if unverified theoretical assumptions might be correct.
https://sites.google.com/view/energy-efficiency-languages/ho...
Many benchmarks have no TS implementations, TS/JS results are about the same except for fannkuch-redux which is about a zillion times slower in the TS implementation. When looking at that kind of massive discrepancy in similar languages with the same runtime, the guess kbenson made was a perfectly sensible one. The authors of the study should have examined that kind of crazy outlier more closely and it's, as pointed out, not that unusual when using the benchmark game as a starting point.