Did I already mentioned how slow programs became? Not only in running, but also in compiling.
On https://codeberg.org/Windfluechter/builddnet you can find the source code of buildd.net, a framework to monitor the #Debian #autobuilder network back then. Originated from monitoring the buildds on #m68k.
However, see & compare the times of e.g. binutils over time...
The database still exists, but the buildd.net project itself not.
Ah, what I intended to say at the beginning:
When we talk about #GreenIT we should also think about code complexity and code sizes. Letting just the compiler do the optimizations will result in larger packages and longer build times and thus in more wasted energy.
Invest the energy instead into designing an optimized code right from the start - inside of your brain. Think about yourself, where you can optimize your code. Don't let the optimizer of your compiler do it for you.
From the...
... buildd.net database you can find my examples where the build times increased significantly without much benefit.
I don't think that binutils included so many new features between versions 2.22 and 2.24 to rectify the increase of build times from 8 hrs to >2 days.
There is another table that also tracks installed sizes and such, btw...
@ij that argument has one issue:
If I write everything in Ruby, I have no compiletimes at all! If I then run my company on Ruby on a cluster with 20 nodes instead of running everything on one node with, for example, Rust... I waste more energy simply by running a slower language!
This is not a black-white tradeoff at all, there are shades of grey in between! I still agree with you that thinking about resources in the first place can help with #greenit though!
@musicmatze Well, the point was about compilers and compiled packages. Interpreted software is not applicable in this context.