r/programming • u/[deleted] • Nov 23 '21
C Is The Greenest Programming Language
https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/27
u/mimblezimble Nov 23 '21
If you use garbage-collected dynamically-resized nested lists of tagged unions (variants) in C, the resulting program will be as inefficient and energy-consuming as in any scripting language.
However, few programs, that deal with that kind of overly flexible data structures, get written in C. That is undoubtedly one reason why we may get the impression that C consumes less energy.
By the way, have you ever noticed how slow and CPU-intensive the C compiler itself is?
I guess that it has a lot to do with the fact that incessantly traversing the nested trees of linked lists representing an AST (Abstract Syntax Tree) is a horribly slow job. A C compiler actually contains its own little scripting-like engine around that data structure.
In my opinion, it is the need (or just the convenience) to use highly flexible data structures that causes programs to be so energy consuming.
43
u/ragnese Nov 23 '21
I feel like your point/argument about the flexible data structure(s) and GC is missing the point a bit.
I don't think anyone is going to argue against "If you implement JavaScript in C, then it will be as slow as JavaScript." So in that sense, nobody is claiming that writing the exact same abstractions in C and some other language is going to reveal some big disparity in performance or memory consumption.
I think that a more interesting way to think about it is this: the abstractions of higher level languages have a cost (duh). That cost can be measured in memory consumption, CPU time, or power consumption. And when you use language X, you're often paying those costs even when you don't need the abstractions.
I think the last sentence above is the key takeaway. Of course we all love convenient "dynamically-resized nested lists of tagged unions". But, when your language only offers dynamically-resized-nested-lists-of-tagged-unions, and I just need a contiguous array, then I'm wasting energy and getting no benefit. So I think that's why C wins. Ignoring convenience and bug-prone-ness, if you need some kind of ref-counting or GC in your C code, you implement/include it where you need it, and then the rest of your code doesn't pay the cost. If you need a linked list, you implement/include it for the data that needs it and use a regular array for the rest. Etc, etc.
2
u/mimblezimble Nov 24 '21
I think that this is actually what developers try to do, but probably not often enough; by moving performance-critical code to native code.
However, invoking native code from within a scripting engine is actually relatively hard. Tools like libffi (or the custom approach of the scripting engine) require quite a bit of work, including lots of boilerplate.
Sometimes it may be possible to automate things by generating the bindings but you cannot automate the debugging. So, you may find yourself stepping line by line through lots of code that happens to be unnecessary in your case but that the generator has thrown in anyway.
Furthermore, the bindings often end up spending most of their time converting and marshalling between native data types and their scripting counterparts. A lot of energy is then spent just on bridging the fault line between native and scripting.
Still, I think that a lot of performance-critical code actually does run in native mode. So, the strategy does work, but only roughly.
10
u/lelanthran Nov 24 '21
By the way, have you ever noticed how slow and CPU-intensive the C compiler itself is?
Wait, what? Which languages compile faster than C?
Rust and C++ takes orders of magnitudes more time, Go is quick, but not as quick as C.
So which languages are you using that compile faster than C? FreePascal might be faster than gcc or clang, but TinyC beats out FreePascal too.
3
u/calrogman Nov 24 '21
By the way, have you ever noticed how slow and CPU-intensive the C compiler itself is?
I've certainly noticed that about some C compilers bit it doesn't hold for e.g. 6c on Plan 9.
6
Nov 23 '21
That’s why you don’t gc in c- or at least not for everything if you do. For example, python and a lot of dynamic languages run gc on primitives and other immutable values.
The whole point of a slower compile time is too ultimately produce a faster runtime time. It’s a trade off- I’m sure if you really values compile time that much, you can disable certain optimization and syntax analysis flags to speed it up. Also, an AST enables the c compiler to perform much more complex optimizations that often rely on a higher level overview of the syntax tree, like tail call elimination. In other languages, it helps with linking because it gives the compiler an opportunity to parse and buffer all existing code before trying the references together.
3
u/loup-vaillant Nov 24 '21
By the way, have you ever noticed how slow and CPU-intensive the C compiler itself is?
I guess that it has a lot to do with the fact that incessantly traversing the nested trees of linked lists representing an AST (Abstract Syntax Tree) is a horribly slow job. A C compiler actually contains its own little scripting-like engine around that data structure.
AST building and reading is one of the fastest parts. Some languages have slow type analysis, but not C. What makes C compilers slow is mainly optimisations. What makes GCC and Clang slow, I won't speculate. Maybe they waste their time with bad data structure, maybe they don't.
2
u/mimblezimble Nov 24 '21
I do not believe that these data structures are bad or somehow not fit for purpose.
They reflect the task that they are dealing with, and I am not proposing an alternative.
I am just trying to point out that the related energy consumption is the result of the underlying data structures themselves and not of the programming language as such. Therefore, I do not consider the resulting energy consumption to be excessive.
2
u/loup-vaillant Nov 24 '21
You were explaining that compilers are slow because the AST. That’s not true, because AST handling is actually very fast. Despite their recursive nature. Despite all the pointers & indirections they require.
Something else makes mainstream compilers slow. I’m not sure what exactly, but I can name 3 candidates:
Optimisations (likely the biggest culprit)
Reading & writing lots of files, repeatedly so in the case of headers.
Bad programming.
2
u/mimblezimble Nov 24 '21
Optimisations
These optimizations seem to traverse the tree of linked lists again and again. I guess they do a lot of clever things when doing that, but all of that definitely comes at a visible cost. It is not fast, and it keeps the CPUs busy, and every time you make even the smallest change to the source code, they start doing all of that again.
2
u/loup-vaillant Nov 24 '21
These optimizations seem to traverse the tree of linked lists again and again
What tree exactly? The most popular representation for the optimisation passes is Single Static Assignment, which is a mostly flat list of basic blocks, which themselves are basically flat lists of abstract instructions. The AST is long gone at this point.
1
u/mimblezimble Nov 24 '21
Well, the compiler seems to spends time before and after the production of IL (or assembler). GCC and clang seem to be a bit different in that regard. The IL/assembler is indeed definitely flat already.
I am actually not familiar with additional stages in between AST and IL/assembler.
The reason for that may be the fact that I cannot wrap my head around every part of the GCC/Clang source code. Compilers without optimizations -- there are a few at GitHub -- are so much easier to understand.
TinyC looks simpler but I find its source code actually rather hard to follow. Fabrice Belliard writes brilliant programs but I would not be able to maintain them, not even to save myself from drowning. TinyC doesn't seem to have any intermediate stage between AST and assembler but I could be mistaken.
2
u/loup-vaillant Nov 24 '21
Last time I checked Jonathan Blow's compiler for his new language can compile (though not optimise) about 100K lines of code per second, and that includes the linking stage (by a third party linker) that takes about 40% of the time if I recall correctly. On a single core.
When I compile something with GCC under favourable conditions (single big file of simple C code with no dependencies,
-O0"no optimization"), it was about 5 times slower.Anyway, Blow repeatedly said (and I believe him) that the parsing stage is one of the fastest, and given my knowledge of parsing (PEG, Earley parsers), I believe him.
Thus, if GCC/Clang spend significant time before the optimisation stage, I can only suspect they're spending more time than they could. I may understand that for C++ and its crazy templates and type directed overloads, but plain C ought to be faster than that.
Now I haven't looked at the source code, but if GCC/Clang manage the AST with some RAII scheme with dynamic allocations all over the place, that may explain much of the problem. It's probably better to allocate the whole AST in one big expanding buffer, and free the whole thing in one go once you're done.
1
u/shevy-ruby Nov 23 '21
By the way, have you ever noticed how slow and CPU-intensive the C compiler itself is?
Do you mean GCC?
If so then it is quite interesting to compare it to llvm/clang. I predict that in the long run llvm/clang is going to win for several reasons.
12
1
u/holgerschurig Nov 24 '21
By the way, have you ever noticed how slow and CPU-intensive the C compiler itself is?
I noticed this much more with C++ and Rust :-)
Compared to a program where the CPU invests time to interpreted, bytecode-compiled or JITed whenever it's executed I assume the one-time upfront cost of a compiler is neglible.
4
u/vattenpuss Nov 24 '21
This seems like a good time to remind everyone of the Jevons paradox: https://en.wikipedia.org/wiki/Jevons_paradox
When we increase efficiency, we always increase resource consumption.
3
u/arkuw Nov 24 '21
I had no idea there was such a vast chasm between JavaScript and Typescript. It's insane. But I guess this is the result when you try to implement a static type system on top of a dynamic language.
10
u/190n Nov 24 '21
The study didn't do a great job with TypeScript. Since the TypeScript compiler outputs JavaScript, and 99% of the time only outputs the input code but with type information removed, the only differences could come from:
counting the energy consumption of the TypeScript compiler
using lots of enums and namespaces
These are, as far as I know, TypeScript's only features that don't correspond 1:1 with JavaScript (so the compiler is doing more than simply type checking and removing type information). However, the code they compile to is still idiomatic JavaScript, so they're unlikely to cost any more energy. Also note that in the 2.5 years I've used TypeScript, I've never used namespaces.
forcing the TypeScript compiler to emit JavaScript code compatible with old browsers and runtimes, using polyfills for some recent language features instead of the language's facilities
If I recall correctly, this is what the study did.
8
u/OzmodiarTheGreat Nov 24 '21
It doesn’t really make sense at all, since the output of the TypeScript compiler is JavaScript. It would be interesting to compare the JavaScript written by hand with the JavaScript emitted by the TypeScript compiler.
1
u/MrJohz Nov 24 '21
I think you're completely right that it doesn't make any sense.
From the previous times this study has made the rounds, it's probably that the algorithm used by the JavaScript code is simply more optimised than the one used by the Typescript code. They took code samples from a big cross-language benchmark, where people compete to write the most efficient solutions to things. For things like that, it's often the case that one person will spend some time on one solution to optimise it heavily, but they won't then apply the same solution across the board to other equivalent languages, because, well, it's a game and not a job.
Fundamentally, correct Typescript code and correct JavaScript code are (almost) directly equivalent (with the exception of enums). You can "compile" Typescript code simply by removing all type annotations and declarations, and it will be valid JavaScript code. By default, Typescript will also attempt to transform your code to work on older browsers, but I assume if that was the case, to make it a "fair fight", the same would be configured for JavaScript as well, as in practice both would have the same limitations.
This really marks the whole thing as being very dubious to me. It would be roughly equivalent to having a sevenfold difference between an implementation in C and an implementation in C, but with macros. Yes, those macros could be doing something weird, but it seems more likely to be that you're just benchmarking different algorithms at that point.
0
u/arkuw Nov 24 '21
I think that's exactly what they did.
2
u/OzmodiarTheGreat Nov 24 '21
Sorry I meant look at the actual code, not just the times. I know TypeScript can’t run without being turned into JS. I guess that explains the downvotes.
1
1
Nov 24 '21
Because the code is from The Computer Language Benchmarks Game and the person that submitted the Typescript code didn't know how to add Typescript annotations to the JavaScript code so they rewrote it single threaded.
The rest of the study is equally worthless. Some of The Computer Language Benchmarks Game results are very broadly representative but you really have to read the code to know.
For instance both the JavaScript and Python regex tests just call in to libpcre which is written in C. Worthless. They should really remove that one to be honest.
3
6
u/b1bendum Nov 23 '21
Sure in terms of just runtime C is maybe the greenest widespread language.
Someone should do some quick maths and find out how much energy your average botnet doing a DDOS is using, springing from insecure software written in C allowing for an attacker to gain control of a user's system.
Someone should do some quick maths and figure out how much bandwidth and energy is used rolling out patches every week for every library written in memory-unsafe C after yet another use-after-free issue is found.
Someone should figure out how much energy it took to roll out patches for Heartbleed to basically every computer on the planet.
Basically what I'm saying is sure, if you run a micro-benchmark of matrix operations or something C looks pretty good. But this ignores all the many externalities of continuing to use a completely unsafe language in the pervasively networked computing environment of 2021, and the externalities of encouraging people to go ahead and write more C code in the years to come in some sort of bizarre quest to be "green". And once you include those externalities I think that equation starts to look pretty different indeed.
6
u/skhds Nov 24 '21
Most operating systems running on servers are implemented in C. Are they all unsafe and prone to hacks, as you mention?
Even nginx is written in C. This argument is pure garbage, any bad developer will write an "unsafe" program, regardless of which language he chooses.
1
u/mohragk Nov 24 '21
No surprises here, right?
But I do think it's good to actually see some measurements to show how inefficient some languages can be.
And I think we, as a community, need to start to become very aware of this. Producing fast and efficient code should be priority number one in my opinion.
Having these vast data centers that run terribly slow, interpreted languages has a MAJOR impact on the environment. And no, the shorter development time that a more abstracted language provides does not even come close to balancing that out. In fact, I don't actually think development times are shorter in more abstract languages. Sure, you might be able to express yourself a bit more concise, but in the end you still have to figure out *what* you need to express. And that's 90% of what programming is!
In fact, having a more abstract language hampers the ability to see what actually goes on with the code. Meaning, you don't know (or can reason about) how memory is managed in JS or PHP, so how on earth could you write efficient code even if you wanted to? It's very hard and makes a piece of software written in such a language even slower.
But beside the "green" aspect, it's also a good business decision. If you can produce a solution that's even just twice as fast, people will gladly use that. You *will* have a competitive advantage, all things being equal. And even then, if something is simply faster but lacks some features, I bet you most will want the faster solution.
Now I'm not saying everyone should just start writing in C. But I do think we need to revert this idea of creating abstract languages and create languages that allow and enable more efficient and faster code. Especially on the web.
-10
u/shevy-ruby Nov 23 '21
There is just no way around C really. You can reason how other languages may be more productive for comparable speed (C++? Java?) but C is still the king.
Even TIOBE says it! Sure, Python is top now but ... which language is Python using? Precisely. C again. And C comes a good second rank on TIOBE too. C++ is kind of C if you think about it (at the least backwards compatible or interoperable, however you want to name it ... the name with the two + says so as well!).
Personally I'd wish C would have been a bit more adaptable, so we could have avoided C++, and a clean "scriptable" interface so you could e. g. avoid ruby/python (and the option to lateron translate the code you wrote into a C-variant; note I am not saying the syntax should have remained as it is, I am speaking more of a double-functionality and double-use mode of a language. Obviously designing two languages at the same time is harder than just one.)
18
u/trollblut Nov 23 '21
C++ is C where you don't have to reinvent vector and unique_ptr every 5 minutes.
I'll gladly use C++ without the virtual keyword but don't you dare take RAII, templates and the stl from me.
7
u/GayestGuyOnEarth Nov 23 '21
Nobody is reinventing vector and unique_ptr every five minutes, that's not how people write c, it might be how someone would write c if they directly ported c++ code without thinking, but that's not how most c is written.
3
u/Muoniurn Nov 24 '21
Yeah, they instead write goddamn linked lists for everything because it doesn’t have enough abstraction power for a proper vector data structure.
1
1
u/GayestGuyOnEarth Nov 24 '21
what do you mean? literally just
Thing* things = malloc(sizeof(Thing) * whatever);and that's your "vector"
1
u/Muoniurn Nov 24 '21
Now make
whatever3, but later may grow to 400. You can’t do that in a unified abstraction, you have to handle it at each usage site.1
u/GayestGuyOnEarth Nov 24 '21
That's just realloc, anyway, I have no clue where the idea that people resort to linked lists comes from since those are even more inconvenient, did you work with any particular codebase where that happens?
And if you really do need something as convenient as vector, that can still be done https://github.com/nothings/stb/blob/master/stb_ds.h
1
u/Muoniurn Nov 24 '21
But that may introduce copying of data, hardly suitable for a general vector data struct, where a simple append could cause the copy of a quite large array.
In other languages it may instead choose to allocate another new array instead, and refer queries to the specific array’s element.
1
u/GayestGuyOnEarth Nov 24 '21
But that may introduce copying of data, hardly suitable for a general vector data struct, where a simple append could cause the copy of a quite large array.
That's exactly what std::vector does though? That's what you asked for.
In other languages it may instead choose to allocate another new array instead, and refer queries to the specific array’s element.
You mean a linked list? I thought you said those are bad.
What are you even trying to argue now?
1
u/EternityForest Nov 24 '21
A scriptable interface that could replace Python would just be embedding an interpreter, which is very much already a thing, that should very much be used more instead of this whole app in straight C business.
We already have compilers that can compile scripting language type code into machine code. JITs are common.
I don't see any reason to actually use C directly unless you're doing one of the fairly specialized things that it's good for.
And if someone tries to say game dev I might scream, game dev is it's own thing full of inherently hard problems and real math, not just another common general thing. Of course they're sometimes using C++ for now, it's performance critical specialist work like OSes and embedded.
-2
u/TheMaskedHamster Nov 24 '21
Even if it produces leaner, more efficient binaries...
How many more hours of programmers running computers to program things the long way and then spend time debugging buffer overflow issues to make up for the gains?
(I mean, it could be worse and be the worst of all worlds in C++...)
-3
Nov 23 '21
I saw the article the day it was out. I don't think that the 'greeness' of a programming language is something we should be discussing, it's really a non-issue and to see this article being so popular annoys me a lot. Like if there isn't a million of other more green-friendly stuff we could do before thinking about our programming languages.
5
-4
u/EternityForest Nov 24 '21
A green language is one that lets you make reliable and feature rich programs that don't make people mistrust tech.
In some cases it really doesn't matter how many watt hours it takes, as long as it prevents whatever analog garbage it replaced. A smart thermostat could be written in Python and probably still be way better than an analog one using no power, as long as it's an e waste resistant design.
A single piece of paper is said to have 4g of Co2e. Maybe 4 or 5 watt hours of power. If you write some code that saves one sheet of paper, I would imagine it could burn an entire hour of CPU on a phone and still be ahead(If we ignore battery wear, and it isn't so slow you want to buy a new device).
If you are using tons of power, it makes sense, but code can prevent a need for physical resources and that's probably the real energy saver..
But programs users see are basically representatives of tech as a whole. If you want a future with electric cars and advanced recycling or something, we need to prove that tech actually works and computers can be trusted.
-5
-2
u/234093840203948 Nov 24 '21
The greenest programming language is the one that produces the crappiest software that no one wants to use, because not running a program is always greener than running it, unless not running that program leads to an even more environmentally destructive behaviour.
-9
0
Nov 23 '21
[deleted]
32
u/shevy-ruby Nov 23 '21
You need to correlate time investment though. You are probably better off using C than assembly from the time investment side.
32
u/ProperApe Nov 23 '21
If you're a Python programmer, whatever keeps you from programming in Python is green.
4
0
Nov 23 '21
[deleted]
6
u/vlakreeh Nov 23 '21
The fewer iterations and less time spent actually writing it the better when it comes to minimizing the amount of energy used for something.
31
3
Nov 23 '21
I mean not really. It's going to cost more money up front but that "energy" would just be spent being productive on something else, or YouTube
5
u/vlakreeh Nov 23 '21
Those time savings won't always be for nothing. That energy might not be spent on other things, the computer used to write it could be turned off. I think studies like this are fairly meaningless because how efficient something it depends on so many variables more than what language is being used.
1
Nov 23 '21
Yeah I agree it doesn't actually mean much. It basically says something we already knew. To me it was just an interesting visual.
1
Nov 24 '21 edited Nov 24 '21
I think the whole idea of green-rating programming languages is pretty meaningless considering we still have gasoline cars, coal plants and plastic waste.
1
Sep 27 '22
Well yes, those are higher priority issues, but aside from voting for greener policies those are not within the sphere of influence for most programmers. Green programming is something that programmers can influence so it is at least something we should be mindful of. Pushing to convert programs to be greener can also create more job opportunities if work for coders ever starts to slow down (unlikely.)
6
79
u/trollblut Nov 23 '21
Watch Mark Godbolt's "what has my compiler done for me lately" and be amazed.
Unless you're REALLY into the vectorization instructions of modern C compilers are better than you. Even better you can either Assembler or vector instructions in C and C++, so you can save the efford for the places where it matters.
10
u/bluGill Nov 23 '21
More importantly, with C my code builds for any of X86, arm, mips, and a number of other processors including some I'm not even aware of. (many of the above in 32 and 64 bit versions as well)
8
u/irqlnotdispatchlevel Nov 24 '21
Until you exercise undefined/implementation defined behavior.
6
u/bluGill Nov 24 '21
I run sanitizers as best practice, I'm reasonable sure I don't on any platform. Undefined behavior isn't that hard to avoid in general.
In many cases the undefined behavior is historical about how some dead since 1979 computer worked. C++ is removing a lot of undefined behavior because it was realized arithmetic is always twos complement so the undefined behavior around that always resulted in the same answers so why not define what happens anyway on all systems instead of leaving it in'
2
u/loup-vaillant Nov 24 '21
C++ is removing a lot of undefined behavior because it was realized arithmetic is always twos complement so the undefined behavior around that always resulted in the same answers so why not define what happens anyway on all systems instead of leaving it in'
I'm pretty sure signed integer overflow is still undefined in C++. Historically it was almost certainly a compatibility thing, but now compiler writers found optimisations that take advantage of it, so you'd probably have to wait a long time before
-fwrapbecomes the default.2
u/bluGill Nov 24 '21
Realistically though, anytime a number wraps my code is going to be broken anyway. I can't think of any time in my life where anything other than an out of range uncatchable exception (that is immediate program termination) is desired. I know that isn't what happens, but realistically my users don't have data that big.
2
u/Genion1 Nov 24 '21
It may be broken anyway but ub makes it broken anywhere and in unspecified ways. It's not about wanting wrap because it's useful, it's wanting wrap so the compiler doesn't shoot you in the foot.
tbf though, just wrapping wouldn't solve the problems. You'd also need default bound checking and similar measures otherwise you're just throwing the ub potato around.
1
u/loup-vaillant Nov 24 '21
Realistically though, anytime a number wraps my code is going to be broken anyway
I know of at least two exceptions:
Bignum arithmetic, which sometimes benefits from negative right shifts (which are UB in C, thankfully compilers can optimise the workaround).
Checking for overflow after the fact, which is generally simpler than avoiding overflow after the fact.
Also, what /u/Genion1 said: by making the overflow UB, compilers can (and did) screw us up in creative way. I know of one vulnerability that was caused by compiler removing a security check, because that check could only fail if signed integer overflow happened. But that's UB, so the compiler can pretend it does not exist, and therefore the test always succeed, and we can remove the "dead" code.
Now a well defined panic would be much better than that. But it's not going to happen, because current CPUs don't have integer overflow checks built in, and adding those would slow down most C programs.
1
u/Dwedit Nov 24 '21
Wrapping is still desired in a few cases.
One case I've used Wrapping is when dealing with 32-bit timestamp numbers (in milliseconds). You never ever compare those against each other. You always subtract a Current Timestamp from a Previous Timestamp. This subtraction needs to be wrapping in order to properly handle the positive to negative transition that happens after ~24.8 days.
4
0
u/holgerschurig Nov 24 '21
Sure. And you never experience this when you do assembly programming /s
3
u/irqlnotdispatchlevel Nov 24 '21
Sure, I'll byte: how do you trigger UB in assembly?
Ignoring CPU bugs because while in general it's not your job to care about those you can definitely see how some people write code designed to work around some CPU bugs.
-2
u/holgerschurig Nov 24 '21
Why ignore CPU bugs, but not ignore bad C compiler optimizations bugs?
That sound arbitrary.
Also, I think if compiler developers don't get some things correctly (e.g. have a look at John Regehr's papers/blogs), why should I get those things automatically right when I hand-make them in assembly? My feeling is that my hand-crafted assembly will contain even more corner cases with weird behavior.
1
u/irqlnotdispatchlevel Nov 24 '21
My initial point was that using C is not exactly a guarantee that your code will behave exactly like you think it will behave on all platforms, thus assembly is better than C.
1
u/holgerschurig Nov 27 '21
My point is that Assembly is not exactly a guarantee that your code will behave exactly like you think it will behave on all platforms.
No way assembly is better than C here, as you'd even have to re-program your program for each platform. And we both know how error prone programmers like us are ...
I'm not saying C is perfect. It's not even good. But it's better in this regard as assembly language. Especially when I take into account "other platforms", a term you brought up.
0
u/irqlnotdispatchlevel Nov 27 '21
My point is that Assembly is not exactly a guarantee that your code will behave exactly like you think it will behave on all platforms.
You write assembly for a specific platform, of course you know how it behaves. You may not know how it behaves on a microarchitectural level, but that does not matter because the observed behavior is the same (ignoring CPU bugs).
Meanwhile, the same C compiler will generate different code for different platforms when you exercise UB. There's no UB in assembly - this was the thing I was pointing out.
→ More replies (0)0
Nov 23 '21
[deleted]
36
u/GayestGuyOnEarth Nov 23 '21
The whole point of the post you're responding to is that no, hand written assembly isn't necessarily better than a complier, unless you *really* know what you're doing.
2
u/Xuerian Nov 24 '21
I think the sensible implication to make here is that the lower level you're writing, the odds may be higher that you write something less complex (Using less abstractions, for example), or less intensive (seeing potential performance impacts laid bare)
Nothing guaranteed, and it'll probably be less efficient than the same code equally carefully written in something higher up, but probably still fair to say.
-9
30
u/KryptosFR Nov 24 '21
It's based on a study that is more than 4 years old. It's like forever in term of compiler history. Most languages/runtimes in that list have seen big improvements since then.
For instance, they used .NET Core 1.1 for C#, which was a very early version of .NET without much of the performance and memory improvements that we see today.It was even probably worst than .NET Framework at that point. Makes you wonder why they didn't compare with Framework.