You seem to like the lines-of-code metric. There are many lines of GNU code in a typical Linux distribution. You seem to suggest that (more LOC) == (more important). However, I submit to you that raw LOC numbers do not directly correlate with importance. I would suggest that clock cycles spent on code is a better metric. For example, if my system spends 90% of its time executing XFree86 code, XFree86 is probably the single most important collection of code on my system. Even if I loaded ten times as many lines of useless bloatware on my system and I never excuted that bloatware, it certainly isn’t more important code than XFree86. Obviously, this metric isn’t perfect either, but LOC really, really sucks. Please refrain from using it ever again in supporting any argument.
Yes.
Also the required clock cycles depends a lot on individual CPU architectures.
For example division: Some CPUs have hardwired logic to compute the division operation directly on circuit level. Others are basically running a for loop with substraction. The difference in required clock cycles for a division operation can then be huge.
Another example: is it a scalar or superscalar CPU?
A rather obvious example: the bit width of the CPU. 32 bit systems compute 64 bit data much more inefficiently than 64 bit systems.
Then there is other stuff like branch prediction, or system dependencies like memory bus width and clock, cache size and associativity etc. etc…
Long story short: When evaluating the performance of code, multiple performance metrics have to be considered simultaneously and prioritized according to the development goals.
Lines of code is usually a veeery bad metric. (I sometimes spend hours just to write a few lines of code. But those are good ones then.) Cycles per code segment is better, but also not good (except you are developing for a very specific target system). Do benchmarking, profiling, run it on different systems and maybe design individual performance metrics based on your expectations.
No, he doesn’t. He suggests that there are Linux systems with no GNU code, like one I’m replying from, and whether “no” meant “no SLOC” or “no instructions spent executing” or “no packages” absolutely doesn’t matter.
I wrote a program that does nothing but busy loop on all cores. stylist_trend/Linux is my favourite OS.
i’m partial to the more relaxing sleep(500)/linux os, but to each their own
Any good sleep will give back control to other threads.
Wouldn’t clock cycles also be bad, as it would reward inefficient code or code that is simply bloat that runs all the time, but doesn’t really matter.
Yes. Also the required clock cycles depends a lot on individual CPU architectures.
For example division: Some CPUs have hardwired logic to compute the division operation directly on circuit level. Others are basically running a for loop with substraction. The difference in required clock cycles for a division operation can then be huge.
Another example: is it a scalar or superscalar CPU?
A rather obvious example: the bit width of the CPU. 32 bit systems compute 64 bit data much more inefficiently than 64 bit systems.
Then there is other stuff like branch prediction, or system dependencies like memory bus width and clock, cache size and associativity etc. etc…
Long story short: When evaluating the performance of code, multiple performance metrics have to be considered simultaneously and prioritized according to the development goals.
Lines of code is usually a veeery bad metric. (I sometimes spend hours just to write a few lines of code. But those are good ones then.) Cycles per code segment is better, but also not good (except you are developing for a very specific target system). Do benchmarking, profiling, run it on different systems and maybe design individual performance metrics based on your expectations.
Then this:
:(){ :|:& };:is most important code in existence.What you refer to as Linux, is actually called Forkbomb/Linux, or as I’ve recently taken to calli-
[Process Killed]deleted by creator
No, he doesn’t. He suggests that there are Linux systems with no GNU code, like one I’m replying from, and whether “no” meant “no SLOC” or “no instructions spent executing” or “no packages” absolutely doesn’t matter.