191–200 of 267 posts
How is JavaScript so far up the list? Slack commits murder on my MBP battery every day.
Reversible computing should be mentioned, as it could be the holy grail of low energy use. https://spectrum.ieee.org/computing/hardware/the-future-of-c...
I'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
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.
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.
In that case, the characteristics of the system will dominate.
Earlier quoted context omitted.
Check out gl-matrix.js, that’s one designed for being fast. It’s a simple math library, but the main way it achieves fast is by not allocating memory. After having worked on JS for some large web apps that need good graphics performance, the two rules of thumb in my head for making JS fast are: 1- avoid dynamic memory allocation, and 2- avoid using the functional primitives like map. The first one is more or less tru…
> 2- avoid using the functional primitives like map I understand that map requires creating a new array, and that is already included in point 1. What overhead are functional primitives subject to apart from memory allocation? e.g. forEach
BTW, it's easy to test the basic primitives. I use Chrome snippets.
test = (name, fn) => {
const timeLimitMs = 1000
let start = Date.now(), count = 0
while (Date.now() - start { for (var i = 0; i { a = a.map((x,i) => i) })
test('forEach', _=> { a.forEach((v,i,a) => a[i] = i) })
for loop 941
map 37
forEach 69
Earlier quoted context omitted.
You might be misunderstanding. AWS and Google and a few others are hosting everyone’s code, all the big shops and all the small shops and everyone in between. They do things to optimize everybody’s code, because it saves literally millions on their power bills.
Yes I can see that. As a small shop developer, I will make my choice of language based on programmer convenience rather than energy usage. I have never heard any developer talk about "kilowatts" when choosing tech (outside of bitcoin mining perhaps).
Perhaps awareness and concrete data of energy usage has to come first? Yes, the article is pointing out something that all the developers you talk to might not know. Doesn’t that make it a good thing? Maybe in the near future you will hear them start to talk about energy. Maybe now that you’re becoming aware, you can be the first among the people you know to talk about the energy usage of your software choices.
Anecdotally, my own experience is that I didn’t hear a lot or think a lot about energy usage until I switched from games & web development to working at a hardware company. My peers now do talk about energy, even though most only write software.
You’re right that most people do choose based on convenience, especially when they lack any other reasons to make the choice. Historically, choosing solely on convenience has contributed to global environmental problems, and people globally are only just becoming aware of the environmental costs of their choices. Separately, Moore’s law only just recently stopped working, so it’s not surprising to me that energy usage has suddenly become more important. Reducing energy use is now one of the primary ways we can increase speed & efficiency, unlike the recent past.
Earlier quoted context omitted.
I 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?
The 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.
What's important is wattage per unit of useful end product, in my example pricing an option. For others, it might be wattage per web page served or anything else.
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…
???
You're recommending a slower language, that uses more watts, on a presumably 24/7 backend...
to save a few bucks on memory?
As I said, if you want a company to switch to c++ or rust because you want to save money on memory IN ADDITION to all the money you're saving on watts, while getting the same or better performance? That might make some sense.
Switching to go makes, No, sense. You end up paying more money per user session to do the equivalent work. (Even worse, each user waits longer because the work is done slower.)
And then, like typical engineers, we'd proceed to explain to our bosses that all of this is actually better...
because our new program uses less memory.
Now, 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.
Language 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…
https://www.cvedetails.com/vulnerability-search.php?f=1&vend...
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.
Earlier quoted context omitted.
I don't think carbon footprint is the be-all end-all you suggest. In a startup that has yet to scale, trading off efficiency for, say, flexibility, safety, or expressiveness may have minimal carbon impact but major benefit for your business. After all, few here will defend the choice of C for web service development these days.
I think 'safety' is the key term here. In the future we will see more self-driving cars and other self-... machines. I would like them to provably not crash (into me). If it were up to me, no matter the energy consumption, a piece of software in that realm should be proven correct (both crash-free and doing what the specification says).
You do realize that a lot of autonomous driving software uses ML techniques that make providing guarantees like that difficult, right? (To be honest, oftentimes we can't even provide an explanation of why an ML decision was made, let alone "prove" why an ML decision is made. We only show tha most of the time, 98.3995% or whatever, the system should do "something like this".)
But in any case, none of that would affect the languages at issue here, because no one would write self driving software in any of these languages. There's about a 10,000% chance that any such startup would use GPU languages to do the meat of that work. Almost 0% chance any reputable company relies on something like go or swift to drive an automobile out on public roads.