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

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: C is the most efficient programming language
By: Nightfox to All on Tue Nov 02 2021 09:45 am

> 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:

They actually have Python over C in regards to memory usage. (!?!)

Assembly language could beat C in those same categories, but it's not a serious contender for similar reasons that C is not a serious contender for a lot of software development tasks - because there are other very important factors such as development time, verification and validation, extensibility and maintenance.

I like and use C a lot, but it's not "the most efficient programming language" for all forms of efficiency. Depending on the job, some other forms of efficiency matter more than eeking out that extra 1% of performance or resource optimization.
--
digital man

Sling Blade quote #2:
Karl (re: killing Doyle): I hit him two good whacks in the head with it.
Norco, CA WX: 69.5øF, 58.0% humidity, 8 mph NW wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: C is the most efficient programming language
By: Digital Man to Nightfox on Tue Nov 02 2021 05:04 pm

DM> They actually have Python over C in regards to memory usage. (!?!)

? C is #3 on their memory list, and Python is #12 on the list for memory usage.

DM> serious contender for similar reasons that C is not a serious contender
DM> for a lot of software development tasks - because there are other very
DM> important factors such as development time, verification and validation,
DM> extensibility and maintenance.

DM> I like and use C a lot, but it's not "the most efficient programming
DM> language" for all forms of efficiency. Depending on the job, some other
DM> forms of efficiency matter more than eeking out that extra 1% of
DM> performance or resource optimization.

I agree. I think the article meant it as efficient for energy use, C, and memory use. But there are other languages that are better for productivity.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: C is the most efficient programming language
By: Nightfox to Digital Man on Tue Nov 02 2021 06:39 pm

> Re: C is the most efficient programming language
> By: Digital Man to Nightfox on Tue Nov 02 2021 05:04 pm
>
> DM> They actually have Python over C in regards to memory usage. (!?!)
>
> ? C is #3 on their memory list, and Python is #12 on the list for memory
> usage.

Sorry, Pascal - the *other* 'P' language. :-)
--
digital man

Sling Blade quote #24:
Karl: Kaiser blade. I hit my mother upside the head with it. Mmm... Killed her.
Norco, CA WX: 80.5øF, 42.0% humidity, 5 mph NNW wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: C is the most efficient programming language
By: Nightfox to All on Tue Nov 02 2021 09:45:49

> 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 mean it's not a huge surprise. They didn't have assembly on there, so you have your low-level/systems languages at the top (C,
C++, Rust) where the specific ordering between them doesn't matter too much. The thing about these cross-language benchmarks is it
all comes down to how the benchmark code was written. I'm surprised to see Fortran do so poorly. Maybe there haven't been any old
geezers writing good Fortran code for the CLBG (which was their source pool).

Also, good job whoever wrote the Python code for CLBG! Ha!

I guess what's new is that this paper puts a new green spin on things. Since we're more energy-conscious these days, we can
describe languages as "energy-efficient" instead of just "efficient". Can I get a carbon tax credit for writing more C code?

---
þ Synchronet þ Mutiny BBS - mutinybbs.com - telnet:2332 - ssh:2232

-=> Digital Man wrote to Nightfox <=-

DM> @MSGID: <6181D1FD.5354.dove-prg@vert.synchro.net>
DM> @REPLY: <61816B3D.3316.dove_dove-prg@digitaldistortionbbs.com>
DM> Re: C is the most efficient programming
DM> language
DM> By: Nightfox to All on Tue
DM> Nov 02 2021 09:45 am

> 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:

DM> They actually have Python over C in regards to memory usage. (!?!)

DM> Assembly language could beat C in those same categories, but it's not a
DM> serious contender for similar reasons that C is not a serious contender
DM> for a lot of software development tasks - because there are other very
DM> important factors such as development time, verification and
DM> validation, extensibility and maintenance.

DM> I like and use C a lot, but it's not "the most efficient programming
DM> language" for all forms of efficiency. Depending on the job, some other
DM> forms of efficiency matter more than eeking out that extra 1% of
DM> performance or resource optimization. --
DM> digital man

I wouldn't call Assembly a Language. There isn't really a language per so,
just mnemonics and instructions to the assembler itself. It is more a system
to assembly machine code, and the efficiency of assembly is heavily dependent
on the ability of the programmer.

... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.52
þ Synchronet þ MS & RD BBs - bbs.mozysswamp.org

Re: C is the most efficient p
By: Boraxman to Digital Man on Sat Nov 06 2021 07:33 pm

> I wouldn't call Assembly a Language. There isn't really a language per so,
> just mnemonics and instructions to the assembler itself. It is more a
> system to assembly machine code, and the efficiency of assembly is heavily
> dependent on the ability of the programmer.

Agreed, except, the different assemblers do have their own "language". They're unique and non-standard, but still a language of sorts.
--
digital man

Rush quote #54:
He'd love to spend the night in Zion, he's been a long, long while in Babylon
Norco, CA WX: 62.8øF, 90.0% humidity, 2 mph W wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: C is the most efficient p
By: Boraxman to Digital Man on Sat Nov 06 2021 07:33 pm

Bo> I wouldn't call Assembly a Language. There isn't really a language per so,
Bo> just mnemonics and instructions to the assembler itself. It is more a
Bo> system to assembly machine code, and the efficiency of assembly is heavily
Bo> dependent on the ability of the programmer.

I always thought assembly was a language, in that it consists of statements you can use to control logic and program flow. Assembly has a 'vocabulary' of keywords (or instructions) that make up the language. But every CPU has its own assembly.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

-=> Nightfox wrote to Boraxman <=-

Ni> @MSGID: <6186CB4C.3331.dove_dove-prg@digitaldistortionbbs.com>
Ni> @REPLY: <61863E0B.2745.dove-prg@bbs.mozysswamp.org>
Ni> Re: C is the most efficient p
Ni> By: Boraxman to Digital Man on
Ni> Sat Nov 06 2021 07:33 pm

Bo> I wouldn't call Assembly a Language. There isn't really a language per so,
Bo> just mnemonics and instructions to the assembler itself. It is more a
Bo> system to assembly machine code, and the efficiency of assembly is heavily
Bo> dependent on the ability of the programmer.

Ni> I always thought assembly was a language, in that it consists of
Ni> statements you can use to control logic and program flow. Assembly has
Ni> a 'vocabulary' of keywords (or instructions) that make up the language.
Ni> But every CPU has its own assembly.

Ni> Nightfox
Ni>
Ni> ---
Ni> = Synchronet = Digital Distortion: digitaldistortionbbs.com

True, but with C, something like
for (int x = 0; x < 100; ++x) {
a*=x;
}

That code is defined by a language, a specification. What "for" and "int" mean
are defined by the language. The structure of the code is defined by the
language. That is to say, C is actually a set of rules, a formal language that
then gets converted to machine code.

But with Assembler, there is not formal Assembler specification, no Assembly
keywords, etc, they are all implementation specific.

... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.52
þ Synchronet þ MS & RD BBs - bbs.mozysswamp.org

Re: C is the most efficient p
By: Boraxman to Nightfox on Fri Dec 24 2021 10:17 pm

Bo> That code is defined by a language, a specification. What "for" and "int"
Bo> mean are defined by the language. The structure of the code is defined by
Bo> the language. That is to say, C is actually a set of rules, a formal
Bo> language that then gets converted to machine code.

Bo> But with Assembler, there is not formal Assembler specification, no
Bo> Assembly keywords, etc, they are all implementation specific.

But still, assembler for each processor is defined by the operations that the processor understands, and there is a specific syntax for each operation.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

-=> Nightfox wrote to Boraxman <=-

Ni> @MSGID: <61C60A0E.3336.dove_dove-prg@digitaldistortionbbs.com>
Ni> @REPLY: <61C5AF39.2749.dove-prg@bbs.mozysswamp.org>
Ni> Re: C is the most efficient p
Ni> By: Boraxman to Nightfox on
Ni> Fri Dec 24 2021 10:17 pm

Bo> That code is defined by a language, a specification. What "for" and "int"
Bo> mean are defined by the language. The structure of the code is defined by
Bo> the language. That is to say, C is actually a set of rules, a formal
Bo> language that then gets converted to machine code.

Bo> But with Assembler, there is not formal Assembler specification, no
Bo> Assembly keywords, etc, they are all implementation specific.

Ni> But still, assembler for each processor is defined by the operations
Ni> that the processor understands, and there is a specific syntax for each
Ni> operation.

Ni> Nightfox
Ni>
Ni> ---
Ni> = Synchronet = Digital Distortion: digitaldistortionbbs.com

Have you ever used AT&T syntax?

... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.52
þ Synchronet þ MS & RD BBs - bbs.mozysswamp.org

Re: C is the most efficient p
By: Boraxman to Nightfox on Sat Dec 25 2021 09:12 am

Ni>> But still, assembler for each processor is defined by the operations
Ni>> that the processor understands, and there is a specific syntax for
Ni>> each operation.

Bo> Have you ever used AT&T syntax?

I haven't.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

-=> Nightfox wrote to Boraxman <=-

Ni> @MSGID: <61C6BCF6.3338.dove_dove-prg@digitaldistortionbbs.com>
Ni> @REPLY: <61C649CF.2751.dove-prg@bbs.mozysswamp.org>
Ni> Re: C is the most efficient p
Ni> By: Boraxman to Nightfox on
Ni> Sat Dec 25 2021 09:12 am

Ni>> But still, assembler for each processor is defined by the operations
Ni>> that the processor understands, and there is a specific syntax for
Ni>> each operation.

Bo> Have you ever used AT&T syntax?

Ni> I haven't.

It's an alternative syntax for assembler, used by GAS and I guess other
assemblers for Unix too.

An example from a program I wrote is below

movl %eax, BRK_Start
movl %eax, BRK_End
movl (%esp), %ecx
cmp $1, %ecx
je clifail
cmp $3, %ecx
jg clifail
movl 8(%esp), %ebx
jl success
movb (%ebx), %al


As you can see, the syntax is familiar, but different. Source and destination
are the other way around for MOV commands, the offset notation is different,
immediate values are prefixed with a $.

... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.52
þ Synchronet þ MS & RD BBs - bbs.mozysswamp.org

Re: C is the most efficient p
By: Boraxman to Nightfox on Sun Dec 26 2021 09:27 pm

> -=> Nightfox wrote to Boraxman <=-
>
> Ni> @MSGID: <61C6BCF6.3338.dove_dove-prg@digitaldistortionbbs.com>
> Ni> @REPLY: <61C649CF.2751.dove-prg@bbs.mozysswamp.org>
> Ni> Re: C is the most efficient p
> Ni> By: Boraxman to Nightfox on
> Ni> Sat Dec 25 2021 09:12 am
>
> Ni>> But still, assembler for each processor is defined by the operations
> Ni>> that the processor understands, and there is a specific syntax for
> Ni>> each operation.
>
> Bo> Have you ever used AT&T syntax?
>
> Ni> I haven't.
>
> It's an alternative syntax for assembler, used by GAS and I guess other
> assemblers for Unix too.
>
> An example from a program I wrote is below
>
> movl %eax, BRK_Start
> movl %eax, BRK_End
> movl (%esp), %ecx
> cmp $1, %ecx
> je clifail
> cmp $3, %ecx
> jg clifail
> movl 8(%esp), %ebx
> jl success
> movb (%ebx), %al
>
>
> As you can see, the syntax is familiar, but different. Source and
> destination are the other way around for MOV commands, the offset notation
> is different, immediate values are prefixed with a $.

Motorola 68K assemblers used the "move source, destination" as well (opposite of Intel/x86 assemblers).

Basically, there's no real "standard" when it comes to assembly languages.
--
digital man (rob)

This Is Spinal Tap quote #38:
Artie Fufkin: I'm not asking, I'm telling with this. Kick my ass.
Norco, CA WX: 48.9øF, 79.0% humidity, 3 mph NW wind, 0.23 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

-=> Digital Man wrote to Boraxman <=-

DM> @MSGID: <61C89E1F.5377.dove-prg@vert.synchro.net>
DM> @REPLY: <61C84490.2753.dove-prg@bbs.mozysswamp.org>
DM> Re: C is the most efficient p
DM> By: Boraxman to Nightfox on
DM> Sun Dec 26 2021 09:27 pm

> -=> Nightfox wrote to Boraxman <=-
>
> Ni> @MSGID: <61C6BCF6.3338.dove_dove-prg@digitaldistortionbbs.com>
> Ni> @REPLY: <61C649CF.2751.dove-prg@bbs.mozysswamp.org>
> Ni> Re: C is the most efficient p
> Ni> By: Boraxman to Nightfox on
> Ni> Sat Dec 25 2021 09:12 am
>
> Ni>> But still, assembler for each processor is defined by the operations
> Ni>> that the processor understands, and there is a specific syntax for
> Ni>> each operation.
>
> Bo> Have you ever used AT&T syntax?
>
> Ni> I haven't.
>
> It's an alternative syntax for assembler, used by GAS and I guess other
> assemblers for Unix too.
>
> An example from a program I wrote is below
>
> movl %eax, BRK_Start
> movl %eax, BRK_End
> movl (%esp), %ecx
> cmp $1, %ecx
> je clifail
> cmp $3, %ecx
> jg clifail
> movl 8(%esp), %ebx
> jl success
> movb (%ebx), %al
>
>
> As you can see, the syntax is familiar, but different. Source and
> destination are the other way around for MOV commands, the offset notation
> is different, immediate values are prefixed with a $.

DM> Motorola 68K assemblers used the "move source, destination" as well
DM> (opposite of Intel/x86 assemblers).

DM> Basically, there's no real "standard" when it comes to assembly
DM> languages. --

Exactly, which is why I don't consider a language, because there isn't actually
a standard to construct a language. Each author of an assembler can make up
whatever they like. FASM is a language. MASM is a language, AT&T Intel is a
language, NASM is a language, etc etc


... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.52
þ Synchronet þ MS & RD BBs - bbs.mozysswamp.org

Re: C is the most efficient p
By: Boraxman to Digital Man on Wed Dec 29 2021 03:30 pm

Bo> Exactly, which is why I don't consider a language, because there isn't
Bo> actually a standard to construct a language. Each author of an assembler
Bo> can make up whatever they like. FASM is a language. MASM is a language,
Bo> AT&T Intel is a language, NASM is a language, etc etc

I see what you mean about assembler. But I'd think you could also argue that each processor's assembler is its own language, even though there is no standard for assembler.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

-=> Nightfox wrote to Boraxman <=-

Ni> I see what you mean about assembler. But I'd think you could also
Ni> argue that each processor's assembler is its own language, even though
Ni> there is no standard for assembler.

There sort of is. Back in the 80's they had macro assemblers.

Think of these as in between something like C and assembler. It looked like
assembly language, but it was "generic" (to a point). The compiler (that's
what it was) would convert your generic assembler into the specific assembly
code for your procssor.

So, in theory, you could write one set of code for a family of processors
(Intel 80x or Z80) that could be compiled across all the processors in the
family.

I don't know if they had one that would let you write for something like the
Z80 and the 6502, though.


... Lead me not into temptation, I can find my own way
--- MultiMail/Linux v0.52
þ Synchronet þ Diamond Mine Online BBS - bbs.dmine.net:24 - Fredericksburg, VA USA

-=> Dr. What wrote to Nightfox <=-

DW> @MSGID: <61CDB562.2970.dove-program@dmine.net>
DW> @REPLY: <61CC93F1.3342.dove_dove-prg@digitaldistortionbbs.com>
-=> Nightfox wrote to Boraxman <=-

Ni> I see what you mean about assembler. But I'd think you could also
Ni> argue that each processor's assembler is its own language, even though
Ni> there is no standard for assembler.

DW> There sort of is. Back in the 80's they had macro assemblers.

DW> Think of these as in between something like C and assembler. It looked
DW> like assembly language, but it was "generic" (to a point). The
DW> compiler (that's what it was) would convert your generic assembler into
DW> the specific assembly code for your procssor.

DW> So, in theory, you could write one set of code for a family of
DW> processors (Intel 80x or Z80) that could be compiled across all the
DW> processors in the family.

DW> I don't know if they had one that would let you write for something
DW> like the Z80 and the 6502, though.

Was HLA (High Level Assembly) one of those? I did look into it, but I always
preferred to be explicit about the instructions I used. When I use assembler,
it is because I am targetting an explicit instruction set and want to make the
decisions about which instructions to use myself. The one time I thought a
"generic" solution would be useful is when I want assembler that runs on both
32bit and 64bit Intel natively.

Otherwise, I just use C as my generic assembler, with intrinsics where need be.

... Overtly resist change
--- MultiMail/Linux v0.52
þ Synchronet þ MS & RD BBs - bbs.mozysswamp.org

-=> Boraxman wrote to Dr. What <=-

Bo> Was HLA (High Level Assembly) one of those? I did look into it, but I
Bo> always preferred to be explicit about the instructions I used. When I
Bo> use assembler, it is because I am targetting an explicit instruction
Bo> set and want to make the decisions about which instructions to use
Bo> myself. The one time I thought a "generic" solution would be useful is
Bo> when I want assembler that runs on both 32bit and 64bit Intel natively.

I never really got into assembly language other than to know it was there.
I've learned much more as I've been doing more research into the history of
PCs.

I went from BASIC as a kid, straight to FORTRAN, Pascal, LISP, C and more.

I think I did one class in Univac assembly in college. But it was mainly to
know what was happening "under the hood" when we worked in the higher level
languages.

I did work on some FORTRAN programs for GM 20+ years ago that used an assembly
language subprogram that was self-modifying. The computer had a fancy
instruction they needed to use, but the assembler didn't support it, so they
wrote their subprogram to modify itself to use the fancy instruction the first
time it was called.

Assembler was mostly frowned upon in my work because of the time and resources
it took to use it. People time was more expsensive than computer time.


... I'm spending a year dead for tax purposes.
--- MultiMail/Linux v0.52
þ Synchronet þ Diamond Mine Online BBS - bbs.dmine.net:24 - Fredericksburg, VA USA

-=> Dr. What wrote to Boraxman <=-

-=> Boraxman wrote to Dr. What <=-

Bo> Was HLA (High Level Assembly) one of those? I did look into it, but I
Bo> always preferred to be explicit about the instructions I used. When I
Bo> use assembler, it is because I am targetting an explicit instruction
Bo> set and want to make the decisions about which instructions to use
Bo> myself. The one time I thought a "generic" solution would be useful is
Bo> when I want assembler that runs on both 32bit and 64bit Intel natively.

DW> I never really got into assembly language other than to know it was
DW> there. I've learned much more as I've been doing more research into the
DW> history of PCs.

DW> I went from BASIC as a kid, straight to FORTRAN, Pascal, LISP, C and
DW> more.

DW> I think I did one class in Univac assembly in college. But it was
DW> mainly to know what was happening "under the hood" when we worked in
DW> the higher level languages.

DW> I did work on some FORTRAN programs for GM 20+ years ago that used an
DW> assembly language subprogram that was self-modifying. The computer had
DW> a fancy instruction they needed to use, but the assembler didn't
DW> support it, so they wrote their subprogram to modify itself to use the
DW> fancy instruction the first time it was called.

DW> Assembler was mostly frowned upon in my work because of the time and
DW> resources it took to use it. People time was more expsensive than
DW> computer time.

I went straight from Basic to Assembler. Mostly because I wanted to write
'machine code' for a while, and at the time, that is what I got, an assembler.
Didn't have a C compiler or anything like that. It was slow going to develop
stuff, especially when it was so easy to hard lock the computer, and this was
on a machine without a reset button. So I would have to turn it off and on to
reset.

But it IS fun, and even recently I've enjoying doing some simply assembler
stuff for Linux, the Vic 20 and for DOS. Something satisfying about having
complete control of the hardware, playing with hardware interrupts, being able
to account for every byte, self modifiable code.

... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.52
þ Synchronet þ The Horizon bbs - bbs.horizonbbs.org