23.11.2021 00:19 Lynn McGuire kirjutas:
> "C Is The Greenest Programming Language" by: Chris Lott
>    https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>
> "Have you ever wondered if there is a correlation between a computer’s
> energy consumption and the choice of programming languages? Well, a

In my experience, any efforts towards more efficient software are easily
defeated by users throwing more data to the program.

Wow, so you can fully analyze a 1024x1024 microscope image in less than
a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
in the next version!

So, you managed to speed up the calculation time of morphological
features by 50%. Fine, now we want to calculate 1000 features instead of
the former 20!

Thus I'm afraid any hopes for a "green" programming language are at best
naïve.

On 12/5/2021 12:51 PM, Paavo Helde wrote:
> 23.11.2021 00:19 Lynn McGuire kirjutas:
>> "C Is The Greenest Programming Language" by: Chris Lott
>>
>> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>
>> "Have you ever wondered if there is a correlation between a computer’s
>> energy consumption and the choice of programming languages? Well, a
>
> In my experience, any efforts towards more efficient software are easily
> defeated by users throwing more data to the program.
>
> Wow, so you can fully analyze a 1024x1024 microscope image in less than
> a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
> in the next version!
>
> So, you managed to speed up the calculation time of morphological
> features by 50%. Fine, now we want to calculate 1000 features instead of
> the former 20!
>
> Thus I'm afraid any hopes for a "green" programming language are at best
> naïve.
>

Fwiw, a hardcore blow up is when I have to render volumes. 256^3 fine,
512^3 okay, 1024^3 slow, 2048^3 slow as shit...

4096^3 slower than a snail hiking up a mountain of salt!

Yikes!

On Monday, 6 December 2021 at 03:20:56 UTC, Chris M. Thomasson wrote:
> On 12/5/2021 12:51 PM, Paavo Helde wrote:
> > 23.11.2021 00:19 Lynn McGuire kirjutas:
> >> "C Is The Greenest Programming Language" by: Chris Lott
> >>
> >> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
> >>
> >> "Have you ever wondered if there is a correlation between a computer’s
> >> energy consumption and the choice of programming languages? Well, a
> >
> > In my experience, any efforts towards more efficient software are easily
> > defeated by users throwing more data to the program.
> >
> > Wow, so you can fully analyze a 1024x1024 microscope image in less than
> > a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
> > in the next version!
> >
> > So, you managed to speed up the calculation time of morphological
> > features by 50%. Fine, now we want to calculate 1000 features instead of
> > the former 20!
> >
> > Thus I'm afraid any hopes for a "green" programming language are at best
> > naïve.
> >
> Fwiw, a hardcore blow up is when I have to render volumes. 256^3 fine,
> 512^3 okay, 1024^3 slow, 2048^3 slow as shit...
>
> 4096^3 slower than a snail hiking up a mountain of salt!
>
If the data represents objects, you can use hierachy.
One byte for each region. If 0, the whole region is empty, if bits are set,
divide the region into 0. Clear regions have their bit clear, full or partially-full
regions have their bit set.
(You have to make your objects hollow, or set up some sort of scheme to
handle 255, to avoid wasting time on fully-filled regions).

On 12/5/2021 9:51 PM, Paavo Helde wrote:
> 23.11.2021 00:19 Lynn McGuire kirjutas:
>> "C Is The Greenest Programming Language" by: Chris Lott
>>
>> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>
>> "Have you ever wondered if there is a correlation between a computer’s
>> energy consumption and the choice of programming languages? Well, a
>
> In my experience, any efforts towards more efficient software are easily
> defeated by users throwing more data to the program.
>
> Wow, so you can fully analyze a 1024x1024 microscope image in less than
> a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
> in the next version!
>
> So, you managed to speed up the calculation time of morphological
> features by 50%. Fine, now we want to calculate 1000 features instead of
> the former 20!
>
> Thus I'm afraid any hopes for a "green" programming language are at best
> naïve.
>

True, but this doesn't make inefficient languages any better, does it?

06.12.2021 13:28 Manfred kirjutas:
> On 12/5/2021 9:51 PM, Paavo Helde wrote:
>> 23.11.2021 00:19 Lynn McGuire kirjutas:
>>> "C Is The Greenest Programming Language" by: Chris Lott
>>> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>>
>>> "Have you ever wondered if there is a correlation between a
>>> computer’s energy consumption and the choice of programming
>>> languages? Well, a
>>
>> In my experience, any efforts towards more efficient software are
>> easily defeated by users throwing more data to the program.
>>
>> Wow, so you can fully analyze a 1024x1024 microscope image in less
>> than a second! Wonderful, let's upgrade our hardware to take 2160x2160
>> images in the next version!
>>
>> So, you managed to speed up the calculation time of morphological
>> features by 50%. Fine, now we want to calculate 1000 features instead
>> of the former 20!
>>
>> Thus I'm afraid any hopes for a "green" programming language are at
>> best naïve.
>>
>
> True, but this doesn't make inefficient languages any better, does it?

No, it does not.

Am 05.12.2021 um 21:51 schrieb Paavo Helde:

> In my experience, any efforts towards more efficient software
> are easily defeated by users throwing more data to the program.

And that should determine the absolute possible efficiency of a
programming language? I think not.

On 12/6/2021 1:52 AM, Malcolm McLean wrote:
> On Monday, 6 December 2021 at 03:20:56 UTC, Chris M. Thomasson wrote:
>> On 12/5/2021 12:51 PM, Paavo Helde wrote:
>>> 23.11.2021 00:19 Lynn McGuire kirjutas:
>>>> "C Is The Greenest Programming Language" by: Chris Lott
>>>>
>>>> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>>>
>>>> "Have you ever wondered if there is a correlation between a computer’s
>>>> energy consumption and the choice of programming languages? Well, a
>>>
>>> In my experience, any efforts towards more efficient software are easily
>>> defeated by users throwing more data to the program.
>>>
>>> Wow, so you can fully analyze a 1024x1024 microscope image in less than
>>> a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
>>> in the next version!
>>>
>>> So, you managed to speed up the calculation time of morphological
>>> features by 50%. Fine, now we want to calculate 1000 features instead of
>>> the former 20!
>>>
>>> Thus I'm afraid any hopes for a "green" programming language are at best
>>> naïve.
>>>
>> Fwiw, a hardcore blow up is when I have to render volumes. 256^3 fine,
>> 512^3 okay, 1024^3 slow, 2048^3 slow as shit...
>>
>> 4096^3 slower than a snail hiking up a mountain of salt!
>>
> If the data represents objects, you can use hierachy.
> One byte for each region. If 0, the whole region is empty, if bits are set,
> divide the region into 0. Clear regions have their bit clear, full or partially-full
> regions have their bit set.
> (You have to make your objects hollow, or set up some sort of scheme to
> handle 255, to avoid wasting time on fully-filled regions).
>

Fwiw, here is an example of some of my work wrt generating a "special"
volumetric Mandelbulb:

https://pastebin.com/raw/v1NNbDRz

https://www.fractalforums.com/index.php?action=gallery%3Bsa%3Dview%3Bid%3D17187

It dumps out a stack of images that can be rendered in 3d as a volumetric.

On 12/6/2021 12:19 PM, Chris M. Thomasson wrote:
> On 12/6/2021 1:52 AM, Malcolm McLean wrote:
>> On Monday, 6 December 2021 at 03:20:56 UTC, Chris M. Thomasson wrote:
>>> On 12/5/2021 12:51 PM, Paavo Helde wrote:
>>>> 23.11.2021 00:19 Lynn McGuire kirjutas:
>>>>> "C Is The Greenest Programming Language" by: Chris Lott
[...]
> Fwiw, here is an example of some of my work wrt generating a "special"
> volumetric Mandelbulb:
>
> https://pastebin.com/raw/v1NNbDRz

Oops! I do not think that the code I referenced computes my special
power stacked mandelbulb. Sorry!

>
> https://www.fractalforums.com/index.php?action=gallery%3Bsa%3Dview%3Bid%3D17187

I have pseudo code contained in the content of the link above for the
power stacked bulb.

Sorry everybody!

>
>
> It dumps out a stack of images that can be rendered in 3d as a volumetric.

In comp.lang.c Bart <bc@freeuk.com> wrote:
> Consider that on my machine, even an empty program takes 0.02 seconds to
> run...

Get a better system if you care about such runtimes. _Statically_
compiled program on Linux needs less than 300 uS to run (of course
this assumes file caching works as intended, if you have spinning
disk first access still needs seek time).
--
Waldek Hebisch

In comp.lang.c Bart <bc@freeuk.com> wrote:
>
> (Also, how did Lisp manage to be only 3 times as slow as C? It was both
> interpreted /and/ dynamically typed last I looked.)

Lisp may be compiled to machine code and when speed is important
you will choose implementation with good compiler. Concerning
"dynamically typed": Lisp has type declarations which are
optional. Without declarations your types can be anything so
you get true dynamic typing. With declarations you can declare
that your variable contains machine integers or doubles and
good Lisp compiler will generate directly machine code.

It is debatable how much C features contribute to speed of
resulting machine code. In Lisp each data structure has
identifying header and you get efficient code only for arrays
of "primitive types", there is no way in Lisp to get something
with memory layout of C array of structs. So in principle
in C you may have more compact data structures that keep
related items together, which leads to better cache use
and consequently less time spent on memory accesses.
When it comes to computations, it is mostly matter of
effort spent on compiler. There was enormous effort spent
on C compilers and compilers like gcc are hard to beat.
Still, it depends on specific code: for simple code with
memory accesses that hit cache using Lisp I usually get about
half of speed of gcc-compiled C. More tricky cases may be
somewhat slower. For example I noted that Lisp compiler that
I use will use multiplication when sequentlially accessing
row of two dimensional array in a loop. This lead to machine
code that is 4-5 times slower than code generated by gcc.
When code is memory-intensive (say pointer chaising) speed
is essentially indepenent of language (of course assuming
that language can express reasonanably efficient pattern
of memory accesses).

Looking at generated machine code I would expect that Lisp
will give me better or equal runtime speed compared to
your C compiler.

As little anecdote, I wrote code compiled via Lisp compiler
that was intended to be speed competivive with code in
interpreted language calling to optimized C libraries to
do main work. AFAIK my code was faster, mainly because
I was able to create combined operation which saved essentally
half work compared to separate library calls. That was
enough to compensate better code generator from C compiler.
Of course, coding my routine in C I would have both gain
form combined operation and gain from better compiler
optimization. OTOH affected routines were about 60 lines
of code, while the whole thing was about 6000 lines.
Writing all in C would take _much_ more effort and the
result would be less useful as my routines were integrated
into existing program (which would be harder to do with
C code).

--
Waldek Hebisch

On 11/12/2021 13:25, antispam@math.uni.wroc.pl wrote:
> In comp.lang.c Bart <bc@freeuk.com> wrote:
>> Consider that on my machine, even an empty program takes 0.02 seconds to
>> run...
>
> Get a better system if you care about such runtimes. _Statically_
> compiled program on Linux needs less than 300 uS to run (of course
> this assumes file caching works as intended, if you have spinning
> disk first access still needs seek time).

You wouldn't normally care about 20ms overhead to start and terminate a
process, but when a program takes 60ms anyway for example, then it can
be significant if you want to know or compare actual performance.

Actually that 20ms isn't accurate. Measuring a block of 100 empty
programs (in both cases from a BAT or Bash script, both with SSD), takes
7ms per invocation on Windows, and 3ms [real time] on WSL.

3ms is 3000 us; not far off your 300 us figure, considering your machine
is likely faster and running true Linux.

Allowing for that 7ms on Windows, then 'tcc hello.c' takes 0.11ms; bcc
takes 18ms, and gcc takes 280ms.

On 11/12/2021 14:07, antispam@math.uni.wroc.pl wrote:
> In comp.lang.c Bart <bc@freeuk.com> wrote:
>>
>> (Also, how did Lisp manage to be only 3 times as slow as C? It was both
>> interpreted /and/ dynamically typed last I looked.)
>
> Lisp may be compiled to machine code and when speed is important
> you will choose implementation with good compiler. Concerning
> "dynamically typed": Lisp has type declarations which are
> optional. Without declarations your types can be anything so
> you get true dynamic typing. With declarations you can declare
> that your variable contains machine integers or doubles and
> good Lisp compiler will generate directly machine code.
>
> It is debatable how much C features contribute to speed of
> resulting machine code. In Lisp each data structure has
> identifying header and you get efficient code only for arrays
> of "primitive types", there is no way in Lisp to get something
> with memory layout of C array of structs. So in principle
> in C you may have more compact data structures that keep
> related items together, which leads to better cache use
> and consequently less time spent on memory accesses.
> When it comes to computations, it is mostly matter of
> effort spent on compiler. There was enormous effort spent
> on C compilers and compilers like gcc are hard to beat.
> Still, it depends on specific code: for simple code with
> memory accesses that hit cache using Lisp I usually get about
> half of speed of gcc-compiled C. More tricky cases may be
> somewhat slower. For example I noted that Lisp compiler that
> I use will use multiplication when sequentlially accessing
> row of two dimensional array in a loop. This lead to machine
> code that is 4-5 times slower than code generated by gcc.
> When code is memory-intensive (say pointer chaising) speed
> is essentially indepenent of language (of course assuming
> that language can express reasonanably efficient pattern
> of memory accesses).
>
> Looking at generated machine code I would expect that Lisp
> will give me better or equal runtime speed compared to
> your C compiler.

To me the most apt description of Lisp seems to be 'shape-shifting'.

The language is dynamically typed when it suits, but can switch to
static typed when someone complains of the speed (but it needs someone
to revise the program).

It also can be run-from-source, or it can compile to some interpreted
internal form, or to native code (or, I guess, use some sort of JIT).

It also seems to be capable of anything; don't like how it does
assignment; there several other ways it can pull out of the hat. That
loop not powerful enough, there are half a dozen other forms with any
number of parameters.

You just can't pin it down. And therefore it seems immune to any
criticism; there is always a way to change it.

> As little anecdote, I wrote code compiled via Lisp compiler
> that was intended to be speed competivive with code in
> interpreted language calling to optimized C libraries to
> do main work. AFAIK my code was faster, mainly because
> I was able to create combined operation which saved essentally
> half work compared to separate library calls. That was
> enough to compensate better code generator from C compiler.
> Of course, coding my routine in C I would have both gain
> form combined operation and gain from better compiler
> optimization. OTOH affected routines were about 60 lines
> of code, while the whole thing was about 6000 lines.
> Writing all in C would take _much_ more effort and the
> result would be less useful as my routines were integrated
> into existing program (which would be harder to do with
> C code).

I always reckoned that the right balance of dynamic code plus static
code, should not be more than 1-2 times as slow as 100% static (save for
programs with short runtimes)

And, sometimes, as you found, it can be a bit faster!

Bart <bc@freeuk.com> writes:

> To me the most apt description of Lisp seems to be 'shape-shifting'.
>
> The language is dynamically typed when it suits, but can switch to
> static typed when someone complains of the speed (but it needs someone
> to revise the program).

Handy that. Rapid prototyping and robust production code. It's the
same language though, you just use more if it as and when needed.

> It also can be run-from-source, or it can compile to some interpreted
> internal form, or to native code (or, I guess, use some sort of JIT).

Yes, there are a wide variety of implementations to suit different
needs.

> It also seems to be capable of anything;

It is. That is obviously literally correct (Turing completeness and all
that) but modern Common Lisp is extraordinarily capable.

> don't like how it does assignment; there several other ways it can
> pull out of the hat. That loop not powerful enough, there are half a
> dozen other forms with any number of parameters.

There /is/ a lot to learn. That's the perennial language design
dilemma. You can have small and a bit rigid, or large and very
flexible.

> You just can't pin it down. And therefore it seems immune to any
> criticism; there is always a way to change it.

Actually it is pretty well pinned down. There is a stable standard for
Common Lisp which is widely implemented and does not change half as much
as, say, the C standard.

--
Ben.

>"C Is The Greenest Programming Language" by: Chris Lott

Assuming by "Green", he means which programming language allows a programmer
to "accomplish the most goals" with the least amount of cycles (energy use)...

I'd first say It's not going to be "cut and dried" because "schlock" can be
written in pretty much any language... so for any sort of valid comparison
you'd have to be using very (and equally) competent programmers, equally
skilled in the languages being used :-)

That being said, I'd first think of "Assembly language" as having the highest
possibility of achieving such a goal because it gives you instruction level
control of exactly what gets done, and makes if at least "possible" to make an
optimal solution to a given goal.

This would have to be tempered by the fact that the number truly competent
assembly programmers is more limited (I'd say that over the years I've seen
more "schlock" written in assembly then most others). Add to this portability
(and other) issues which make it not truly suitable for many goals, and I have
to admit: It's probably not a good one to consider.

IMHO, C comes pretty close, because it allows one to do much of the lower
level "stuff" you might not be able to efficiently accomplish on other higher
level languages, and in a good implementation these kinds of operations can
product code not all that much different from what a good assembly programmers
would have done...

And it "solves" or at least improves many of the main issues that can crop
up in assembly:

- Portability, C code can be generic enough that it needs little to no changes
when moving to another system. And C is (IMHO) one of the most common higher
level languages available on different systems (and has been for some time).

- It makes it "easy" to control the use of memory. Just "declare" things and
the compiler will take care of allocating space for them in applicable areas
of memory. No worrying about "what would best go here...".

It also handles stack frames and automatic allocation/free of local "things"
when entering/exiting a "function" (applicable to below)

- It makes it much easier to break up your program into logical blocks or
subroutines. Sure: Assembly almost always has the ability to CALL/JSR
(I've worked on some minimal CPUs which don't!) but you have to worry
about passing information to and getting information from such blocks,
and how to make memory available to them "as they run" (if you need to),
but C does all of this in some very straight forward/efficient ways (at
least most systems do :-)

- Commonly used more complex operations can be maintained in a (hopefully
very efficient) "library" and made available "as you need them" without
having to do such things "again and again".

There are of course some potential downsides:

- You don't control the code being generated at the instruction level (but
with some Cs you come pretty close). Hopefully the designers of the compiler
did a good job, but you may see some non-optimal output from time to time.

- "Libraries" although mentioned above can be a "good thing", but in my
experience they can also be "not so good". Supplied libraries are made such
that they will appeal to many programmers, and may therefore not do exactly
what (and only what) you would like. There is often a sometimes large amount
of "extra stuff" brought in because it's used somewhere in the library code.
And being so readily available, there's a lot of temptation to "just use" them.

In most cases these aren't much of a problem, but when you are looking at
"fastest and smallest" it can surprise you. In "modern times" of multi Ghz
processing and multi Gb memory systems, it's really not an issue many
programmers even think about.

I could go on ... but I hope I've made at least a bit of a point.

All of this is or course my own "opinion" and comes from many years working
on very small/slowish and often quite memory limited targets. A lot of this
was done in assembly language at first because I didn't find a higher level
language that came "close enough". As time progressed I did switch a lot of
my development to C because in many cases it did (come close enough). I still
use dribbles of assembly "as needed" (the main reason my compiler has fairly
capable "inline assembly" capabilities! :-)

Regards,
Dave

Dave Dunfield <dave.dunfield@gmail.com> writes:

>>"C Is The Greenest Programming Language" by: Chris Lott
>
> Assuming by "Green", he means which programming language allows a programmer
> to "accomplish the most goals" with the least amount of cycles (energy
> use)...

Why are you replying to me? Why do you include a quoted line that was
not in the post you are replying to? Maybe something is wrong with your
news client.

--
Ben.

On Monday, December 13, 2021 at 10:18:36 PM UTC-5, Ben Bacarisse wrote:
> Dave Dunfield writes:
>
> >>"C Is The Greenest Programming Language" by: Chris Lott
> >
> > Assuming by "Green", he means which programming language allows a programmer
> > to "accomplish the most goals" with the least amount of cycles (energy
> > use)...
> Why are you replying to me? Why do you include a quoted line that was
> not in the post you are replying to? Maybe something is wrong with your
> news client.

Sorry, I "thought" I had removed attrition - and just quoted a line I recalled seeing in the initial posting
(that I could see) - curious to know how it shows up as "a reply to you", as I don't see any mention
of you in my reader" ...

I probably should have removed the extra '>' showing "a quote of a quote" but as there was no other
text it didn't seem (to me) to be an issue... It's pretty clearly only referencing the initial text.
sorry if this oversight bothered you.

I do know my reader is "broken", I'm still using "Google Groups" while I decide if it's worth getting back
into this or not ... GG isn't at all friendly to "C" or programming - groups. (I've no doubt that a number of
people who have also "responded to me" will be pleased I'm leaning toward the "not" :-)

Dave

Dave Dunfield <dave.dunfield@gmail.com> writes:

> On Monday, December 13, 2021 at 10:18:36 PM UTC-5, Ben Bacarisse wrote:
>> Dave Dunfield writes:
>>
>> >>"C Is The Greenest Programming Language" by: Chris Lott
>> >
>> > Assuming by "Green", he means which programming language allows a programmer
>> > to "accomplish the most goals" with the least amount of cycles (energy
>> > use)...
>> Why are you replying to me? Why do you include a quoted line that was
>> not in the post you are replying to? Maybe something is wrong with your
>> news client.
>
> Sorry, I "thought" I had removed attrition - and just quoted a line I
> recalled seeing in the initial posting (that I could see)

You had removed all attributions. By the way, that's not considered
good form. People like to know who said what.

> - curious to know how it shows up as "a reply to you", as I don't see
> any mention of you in my reader" ...

Post have an "In-Reply-To" header that gives the ID of the message you
are replying to. Posts also contain a "References" header that gives
the whole chain of "parent" articles.

> I probably should have removed the extra '>' showing "a quote of a
> quote" but as there was no other text it didn't seem (to me) to be an
> issue... It's pretty clearly only referencing the initial text. sorry
> if this oversight bothered you.

I was not bothered. I knew it was reply to me because my newsreader is
set to give them priority. But anyone who wanted to see who said what
you were replying to would be baffled. They'd go up to the parent
article and see it was from me, but they would also see that I have not
said what was quoted.

--
Ben.

On Thursday, December 16, 2021 at 5:04:01 PM UTC-5, Ben Bacarisse wrote:
> You had removed all attributions. By the way, that's not considered
> good form. People like to know who said what.

I am aware of that, but in this case the "quoted" line was the same as the title!
I wasn't trying to quote anybody, I just wanted to put the context of my reply in
the frame of "the subject of this thread". I amm guilty of being lazy and not
cutting/pasting the title since it was easier to just clip where someone else had
posted it. I should have removed the extra '>'

> I was not bothered. I knew it was reply to me because my newsreader is
> set to give them priority.

I guess another downside of "Google Groups" - I use "reply all". Which I thought
would just post to the thread as a whole, not to a particular participant.

> But anyone who wanted to see who said what
> you were replying to would be baffled.

Out of curiosity - what is "good form" to reference the title?

Dave ::: https://dunfield.themindfactory.com

Dave Dunfield <dave.dunfield@gmail.com> writes:

> On Thursday, December 16, 2021 at 5:04:01 PM UTC-5, Ben Bacarisse wrote:
<cut>
>> I was not bothered. I knew it was reply to me because my newsreader is
>> set to give them priority.
>
> I guess another downside of "Google Groups" - I use "reply all". Which
> I thought would just post to the thread as a whole, not to a
> particular participant.

As far as I know, you can't post in an existing thread without it being
a reply to some other specific post.

>> But anyone who wanted to see who said what
>> you were replying to would be baffled.
>
> Out of curiosity - what is "good form" to reference the title?

If the subject line is the only significant context (i.e. you are not
replying to some specif point where quoting that point will help), then
I think the clearest thing it to reply to the head post. It will appear
to be a reply to whoever posted that head post, but you can't avoid
appearing to replying to someone.

You'll sometimes see people start a post with "piggybacking...", by
which they mean that are replying to one post but they are not really
making any specific points about it.

--
Ben.