I haven't done much programming in pure C, but I thought this article was interesting. It says C is the most efficient programming language as far as power consumption, speed, and memory usage:

https://bit.ly/3ECS5QT

Full link:

https://cryptomode.com/c-is-the-most-energy-efficient-and-fastest-programming-l anguage-study-finds/

Nightfox
--- SBBSecho 3.14-Win32
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

On 02 Nov 2021 at 09:45a, Nightfox pondered and said...

I haven't done much programming in pure C, but I thought this article was interesting. It says C is the most efficient programming language as
far as power consumption, speed, and memory usage:

Reading through to the actual paper, I'm _far_ from convinced.
In particular, they seem to have run a set of benchmarks from
the Computer Languages Benchmark Game (https://benchmarkgame-team.pages.debian.net), which curiously
says, "Always look at the source code." Ok, fine. I find it
hard to believe that a C compiler will beat FORTRAN for
numeric computation without compiler flags that basically change
the language: C allows aliasing of pointers in ways that FORTRAN
does not, which means that a compiler can be _much_ more
aggressive about optimizing loop computations into SIMD or
vector instructions with a FORTRAN program than C.

The "Binary tree" benchmark seems like a bit of a farce, since
the emergence of cache hierarchies as critical components of
performance have made binary trees much less compelling from a
performance perspective (despite their seemingly advantageous
asymptotic performance characteristics): something like a Btree
or a hash table will generally perform much better these days
(or even binary search in a sorted vector).

Moreover, this depends entirely on the benchmarks themselves and
how they are written. This vaguely reminds me of debacle that
led to this blog post: https://go.dev/blog/pprof The first
paragraph seems most relevant.

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I haven't done much programming in pure C, but I thought this article
was interesting. It says C is the most efficient programming language
as far as power consumption, speed, and memory usage:

I am not too surprised that assembly isn't among the evaluated languages.

It'd destroy them, alongside the fragile egos of those who refuse to learn assembly.

... Press SPACEBAR once to abort, or twice to save changes

--- Mystic BBS v1.12 A47 2021/08/10 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (21:1/158)

On 06 Nov 21 19:58:29, Roc said the following to Nightfox:

I am not too surprised that assembly isn't among the evaluated languages.

It'd destroy them, alongside the fragile egos of those who refuse to learn assembly.

Ahh, assembler. I cut my teeth on 6502 on the Apple 2.

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

On 06 Nov 2021 at 07:58p, Roc pondered and said...

I am not too surprised that assembly isn't among the evaluated languages.

I'm not. It's not all about efficiency with respect to
execution on the machine; it's also about programmer
efficiency. Using a higher level language (almost anything
is higher than assembly except for machine code) allows
the programmer to keep more complexity in their brain;
this allows us to concentrate more on the problem and its
semantics and less the minutia of the keeping the machine
happy.

It'd destroy them, alongside the fragile egos of those who refuse to
learn assembly.

I tend to doubt that, actually. Those who think that their
assembler is better than higher-level languages tend to be
those that concentrate on low-level bit-swizzling to the
exclusion of higher-level optimizations (such as using better
data structures, for example). Often, when you remove the
artificial barriers of complexity imposed by assembly, one
can suddenly see the forest for the trees and come up with
a better overall solution.

Also, modern compilers are impressive in their ability to
generate extremely high-quality object code; being able to
do interprocedural analysis, link-time optimization
facilitated by high-level type information, and aggressive
inlining will often produce a solution that beats the pants
off of hand-rolled assembler, which over time often
becomes a liability as the machine's microarchitecture
evolves (lookin' at you, x86; REP STOSB is often faster
than REP STOSL because the uarch has micro-optimizations
for it, while assembly language programmers would naturally
lean towards the latter).

It may be worth noting that the article the OP linked to
is based on a paper from 2017. The current state of the
Debian benchmarks is rather different, and C does not
look quite as good.

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I used to think similarly re: modern compilers. It happens if, for a while, you forget to look at their output. They do still make a mess of your code, and not necessarily for a good purpose.

I do, however, agree about developer output. With the likes of Python, I do get a lot done and very fast. Often enough, performance doesn't matter, or it does but only in big-O sense.

Still, there's no substitute for assembly, and using it once in a while is definitely insightful.

... Do not underestimate the value of print statements for debugging

--- Mystic BBS v1.12 A47 2021/10/25 (Raspberry Pi/32)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

On 09 Nov 2021 at 04:47p, Roc pondered and said...

I used to think similarly re: modern compilers. It happens if, for a while, you forget to look at their output. They do still make a mess of your code, and not necessarily for a good purpose.

Well, sure. I work on kernels, so I read and write assembler
often. Knowing how to grok it is definitely helpful. On the
other hand, very often that bad code comes from improper
understanding of the semantics of the underlying language.

Then again, the other day a colleague had a really abstruse
sequence of code: "isn't this just `foo = (foo + 1) % N;` ?"
"yeah, but the compiler makes a mess of that so we write
it with if's." "Oh."

I do, however, agree about developer output. With the likes of Python, I do get a lot done and very fast. Often enough, performance doesn't
matter, or it does but only in big-O sense.

I heard from Guido the other day that he's at Microsoft
working at making Python faster. I guess he didn't like
retirement. :-)

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)