| Manfred <noname@add.invalid>: Nov 23 08:29PM +0100 On 11/23/2021 4:50 PM, Kenny McCormack wrote: > It depends, of course, on what exactly you mean by a "slower" language. > It is true that if you run the CPU at a slower speed (and that would make > for a slower processing model), then you will use less energy. Well, CPU speed is not a property of the language... |
| Manfred <noname@add.invalid>: Nov 23 08:59PM +0100 On 11/23/2021 5:51 PM, David Brown wrote: > time and energy, so you don't want to do it too often - hence the > "big-little" processor combinations where you have a slower core that > can be switched on and off more efficiently. I am not sure about that "rule" - in general modern integrated electronics waste most energy during state transitions, and that is directly coupled with clock frequency, but I admit there may be more to it that I don't know. One consideration about the balance between clock speed and efficiency is that it is totally relative to how old the technology is. I am pretty confident that an old Pentium is much less efficient than a modern i7 (just to consider popular PC stuf only), even if the latter runs faster than the former. The reason is not just because of the added value of the environmental footprint in today's public opinion; the fact is that heat dissipation is a major bottleneck in IC technology, so in order for a modern processor to perform according to nowadays' standards and not melt after a few minutes of operation, it /has/ to be built with efficient technology. But then comes "modern" programming, with all its fuzz of managed code, JIT gibber, thousands of DLL dependencies, etc., not to forget "modern" OS's that eat Tflops just to perform even the simplest of tasks, and there goes all of that efficiency. |
| Bart <bc@freeuk.com>: Nov 23 08:50PM On 23/11/2021 19:59, Manfred wrote: > JIT gibber, thousands of DLL dependencies, etc., not to forget "modern" > OS's that eat Tflops just to perform even the simplest of tasks, and > there goes all of that efficiency. This is why talk of the greenest language is nonsense. How about writing efficient applications? And efficient OSes (there might be 1000 processes on my PC right now). Access any webpage, and the fast download speeds mask how much data is being transmitted, which all still requires code to process it. Hardware can barely keep up. Or, how about efficient compilers? David Brown always contemptuously dismisses mine even though they are fast, yet they show that the basic job of source->binary translation can be done 1-2 magnitutes faster than the heavy-duty compilers he favours. (For a couple of years one of my compilers was run as interpreted, dynamic bytecode. It was still double the speed of gcc!) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 01:12PM -0800 On 11/22/2021 11:10 PM, Juha Nieminen wrote: >> Interesting. However, I can write something in C that uses all CPU's >> 100%. > I don't think that's the point. Humm... I was just thinking along the lines of 'what does the C code actually do?' If it ends up blasting the system, how green is it? Well, yeah, that is a different point. You are right Juha. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 01:23PM -0800 On 11/22/2021 11:10 PM, Juha Nieminen wrote: >> Interesting. However, I can write something in C that uses all CPU's >> 100%. > I don't think that's the point. Side note: Humm... Perhaps we can say that lock-free is "greener" than using locks. Say a computation using a nice lock-free algo takes 5 minutes. Vs, something using locks that takes 30 minutes to get the same result. I remember back in the day where I had to terminate the lock-based tests because they took way too long. |
| Ian Collins <ian-news@hotmail.com>: Nov 24 11:18AM +1300 On 24/11/2021 09:50, Bart wrote: > the heavy-duty compilers he favours. > (For a couple of years one of my compilers was run as interpreted, > dynamic bytecode. It was still double the speed of gcc!) Well if it generates unoptimised code, it is still not very "green" is it? Unless you are compiling often and running once... -- Ian. |
| David Brown <david.brown@hesbynett.no>: Nov 23 11:35PM +0100 On 23/11/2021 20:59, Manfred wrote: > electronics waste most energy during state transitions, and that is > directly coupled with clock frequency, but I admit there may be more to > it that I don't know. That is correct. There are two aspects to the energy usage of the switching - there is the charge transfer that depends on the capacitance of the gates and the voltage, and there is the leakage current during switching while the gate is half-open. The first is pretty much independent of frequency of switching, so the same transitions (i.e., the same calculations) take the same energy regardless of how fast they are done. The second is dependent on the switching speed, which goes up with the voltage (that's why you increase the voltage for higher frequencies, to get shorter switching times - a higher voltage pulls the electrons across the gaps faster). The switching time is basically independent of the switching frequency, except that it has to be shorter to support higher frequencies. I believe (and this is getting a bit outside my knowledge) that for CPU internals, it is the charge transfer that dominates, not the loses during the switching period. (I have plenty of practical experience with low-power devices, but that is primarily for microcontrollers. If people really want to go into depth about the power consumption of "big" processors, it would probably make more sense to start a thread in comp.arch rather than in C and C++ groups. There are folks over there who have worked on serious cpu design and know a lot about this stuff.) > confident that an old Pentium is much less efficient than a modern i7 > (just to consider popular PC stuf only), even if the latter runs faster > than the former. Yes, mostly. Modern devices have smaller geometries - that means faster switching times and less capacitance, so smaller charge transfers and lower dynamic power for the work done. But it also means more leakage and thus more static power. And in order to get higher clock frequencies and more instructions per clock, pipelines are longer, paths are wider, there is more speculative execution, branch prediction, caching, and all the rest of it. These features don't actually contribute anything to the work being done. Thus an old Pentium running a given piece of code will involve perhaps orders of magnitude fewer transistor switches than you would have in a modern i7. (This is another reason for the big-little pairings for low-power processors - the simpler "little" cpu will have fewer switches and less energy than the "big" cpu for the same real work, regardless of frequency.) Modern devices also have much smarter power and clock gating that was simply not used in older devices - otherwise the static leakage power would be far too high. > is a major bottleneck in IC technology, so in order for a modern > processor to perform according to nowadays' standards and not melt after > a few minutes of operation, it /has/ to be built with efficient technology. Absolutely. I remember reading that the first Itanium processors had higher power densities than the core of a nuclear reactor - these devices handle a lot of power in a small space, and it all ends up as heat. > JIT gibber, thousands of DLL dependencies, etc., not to forget "modern" > OS's that eat Tflops just to perform even the simplest of tasks, and > there goes all of that efficiency. Wirth's law - "Software gets slower faster than hardware gets faster" - is over 20 years old, and there is no sign of a change yet. That's one of the reasons I like programming small microcontrollers - it's all /my/ code, and there's no fuzz or gibber unless I put it in myself. |
| David Brown <david.brown@hesbynett.no>: Nov 23 11:46PM +0100 On 23/11/2021 21:50, Bart wrote: >> "modern" OS's that eat Tflops just to perform even the simplest of >> tasks, and there goes all of that efficiency. > This is why talk of the greenest language is nonsense. Agreed (mostly). > How about writing efficient applications? And efficient OSes (there > might be 1000 processes on my PC right now). Yes - it is the software that takes energy, not the language. It's fair to say that the software does a lot more now than it used to, but it's equally fair to question whether that extra work is necessary. > dismisses mine even though they are fast, yet they show that the basic > job of source->binary translation can be done 1-2 magnitutes faster than > the heavy-duty compilers he favours. Yes. But that is because I understand the difference between compiling code and /running/ compiled code. As long as your compilation process is not so slow that it hinders the development process, it doesn't matter. If a program is only going to be used on a few systems or by a few people, then the dominant cost is the programmer (and their energy needs massively outweighs the compiler's). If it is going to be used a lot, then the dominant cost is the target systems' runtime (and thus you want as efficient results as you can get from the source code). At no point is the effort or energy required by the compiler at all relevant in the total sum. |
| Bart <bc@freeuk.com>: Nov 23 10:58PM On 23/11/2021 22:18, Ian Collins wrote: >> dynamic bytecode. It was still double the speed of gcc!) > Well if it generates unoptimised code, it is still not very "green" is > it? Well, so was gcc-O0, which was how the comparison was made. Otherwise the disparity would have been greater. And aside from the speed, my stuff also tends to be small, so also economising on storage, loading, storing, downloading, memory... Here are compilation rates for my tools (build from source), using my current compiler: mm 10 Hz (main compiler) pc 14 Hz (IL project, my version of llvm) aa 20 Hz (assembler/linker) qq 10 Hz (interpreter) bcc 9 Hz (C compiler) 10 Hz means I can build the project 10 times in one second (and using one core). I'd be interested to see the equivalent figure for gcc or llvm. If it was only running my stuff, my PC would have very little to do! > Unless you are compiling often and running once... During development that's exactly what you do. For a production program, then yes you can go to town on optimising, because you don't do it repeatedly. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment