Quantum Mechanics demystified, a try
Green Coding. Develop computer programs which consume less energy. It has recently risen to limelight. For a reason. Power consumption of ICT sector is nowadays enormous. They say it is between 5 and 10 percent of overall power consumption nowadays. Prognosis is it will rise to 20% in ten years.
Likely some of it is due to mining cryptocurrencies currently with GPUs. If or when Quantum Computers can some day do the stuff, less energy might be used. But if Quantum Computing would be reality, encryption currently used with cryptocurrency blockchains looses its meaning. Kind of a which was first situation, the hen or the egg.
In the old days, Cray X-MP/464 at CSC was using electricity worth of 30-40 Sauna’s stoves. Primary cooling circuit was with freon, which was cooled down with the secondary water based cooling system. Coolers were up on the roof of the computing center. Crows and other birds were happy to get warmer climate there :-).
Nowadays we are on the greener side with this, extra heat gets utilized. E.g. data centers are being located on colder surroundings where generated heat will be utilized for warming up buildings and other infrastructure in neighbourhood.
Computer centers are still one of the biggest consumers. But networking related power consumption has raised a lot since. Personal devices take their part of consumption, of course.
There certainly is a difference on how cost-effective different programming environments are energy wise. Cray at CSC was mostly programmed with Fortran and c. Even with CAL assembler. Those are nowadays regarded as most energy effective languages.
With assemblers, Fortran and c languages programmer is working closer to grass-roots level. One have to code things that fit straight to the case in question. Whereas e.g. a Python programmer can use ready made sophisticated frameworks instead. Those frameworks has to adopt to different instances and thus have a lot of extra conditional coding among other things. Python is an interpreted language, which makes it run a bit slower if compared to compiled code.
Thus, Python has been said to use tens and tens of times more energy in performing the same tasks if compared to c. This means that required time is also longer in about the same proportion.
Other side of the coin is of course that the programmer uses a lot less time to implement an algorithm in Python if compared in implementing it with c.
As man work has traditionally been regarded more valuable than energy, the trend has been towards tools that can produce results in shorter time.
Development cycle speed gets maximized with code generating systems. Low Code being current trend. Application is designed on graphical level with the code then generated automatically. Code may be enhanced manually. Generated code may also be edited e.g. to speed it up.
On some restricted environments we may use a No Code system, where generated code is not enhanced or modified manually at all.
In addition to development cycles being fast, also personnel with little or no IT experience are able to develop applications.
There have been code generating systems for ages. Only they haven’t been called Low Code until recently. Current Low Code systems include additional functionalities on top of code generation, like testing, integration and deployment.
One of the first code generation tools I was involved with was named Delphi, which generated Pascal code per graphical specification. But it didn’t quite get up to speed. On the way I have used some other code generating UI design tools, like JDE OneWorld and Gognos Powerbuilder.
OneWorld was very much a Low Code system. Generated c code was enhanced with business functions and generated code could be modified to speed it up or to change functionality for a reason or another. Logic of generated code was somewhat hard to catch though. As it inevitably is with any of code generating system.
No benchmark data seems to be available to compare performance of Low Code generated code to e.g. c implementation of the same case. I see it would require quite some effort to set up such a benchmark. Neither any interest exists for it, as the benefit in speeding up the development cycle is currently the matter that rules.
Considering the characteristics of Low Code systems together with past experiences with generated code, Low Code presumably performs not well at all. Inevitably they will consume far more energy over traditional systems.
Low Code systems are not Green at all.
Probably some day man work is less expensive than energy. And code gets green again.