Completing C code with D style

[Stanislav Blinov]

On Wednesday, 10 November 2021 at 23:15:09 UTC, forkit wrote:
> On Wednesday, 10 November 2021 at 22:17:48 UTC, russhy wrote:
>> On Wednesday, 10 November 2021 at 06:47:32 UTC, forkit wrote:
>>> btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. 
>>> So I really don't give a damn about allocations .. not one 
>>> little bit ;-)
>>
>
>> Having the right mindset helps not make these mistakes in the 
>> future
>>
>> Changing habits is hard, make sure to train yourself to pick 
>> the right one, early if possible
>
> Umm.. you kinda missed the last part of my post...
>
> ..where I said..'Now if I were running a million processes 
> across 1000's of servers, I probably would give a damn.'

Your CPU executes code speculatively, and in parallel. That's 
just the way it is, it's how the machine works. Therefore, you 
simply cannot afford to NOT think about that. You're just wasting 
your machine time if you're not caring about that. Consequently, 
you're wasting your time, someone else's time, and, well, money.
No, it's not a million processes across 1000s of servers, it's at 
least two processes across n cores, each of which has m ALUs. (At 
least two because the OS is involved). But it's two processes 
from you, two processes from me, four from the other guy, and 
pretty soon you have a monster that struggles to utilize even a 
tenth of your machine. All because "I'll care about it tomorrow".

> C'mon... nothing in my code was 'unacceptable' in terms of 
> speed or efficiency.
>
> Making code transformations to improve speed and efficieny are 
> important, but secondary. A newcomer cannot improve code that 
> they do not understand ;-)

Yes, optimization is hard. Pessimization, though, is laughably 
easy, and should be avoided at all costs. "I don't care" is the 
number 1 reason for the atrocious situation with software that 
we're in right now. And people tend to come up with all sorts of 
ridiculous excuses, but most of them, distilled, do amount to "I 
don't care".
My phone is a thousand times faster, and has two million times 
more memory, than the thing that guided Apollo 11 to the Moon. 
And yet it sometimes takes longer to react to my keystrokes than 
roundtrip for a radio signal to the Moon *and* back.
My desktop is two times faster, and has eight times more memory, 
than my phone. But it consistently takes THREE TIMES the 
roundtrip of a radio signal to the Moon and back to start Visual 
Studio.
Heck, it will take longer than the roundtrip of a radio signal to 
the Moon and back to post this message after I hit "Send". And 
I'm reasonably certain this news server is not on the Moon. This 
all is, plainly, ridiculous.

> Picking understandable code first, IS right.

No. "Understability" is subjective. Show me some code in Scala or 
Fortran, I won't make heads or tails of it, even though it may be 
perfectly obvious to the next guy who also never saw either 
language. What's "right" is writing code that doesn't perform, or 
cause, any unnecessary work. It may not be fast, but at least it 
won't be slow for no reason.

> In any case, I say again, this thread is not about writing 
> performance code per se, but about presenting code to 
> new-comers, that they can make some sense of.

And how does invoking extra work help with that? Coupled with not 
even explaining what that extra work is and why it is there?

> Taking some C code, and writing/presenting it in D (or 
> vica-versa) in such a way that you can longer make any sense of 
> it, is kinda futile.

Original C code from the first post can only fail on I/O, which 
is arguably out of your control. And the meat of it amounts to 10 
conditional stores. Your implementations, in both C and D, are a 
very, very far distance away from that. Like I mentioned before, 
the whole algorithm can already complete even before a single 
`malloc` call starts executing. Not caring about *that* is just 
bad engineering.

If you're writing C, or D, you're not writing pulp fiction for 
the masses. There are other languages for that.