Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #124501 > unrolled thread

What is a genius programmer (e.g. C, Pascal, Foxpro)?

Back to article view | Back to comp.lang.c++

Contents

  What is a genius programmer (e.g. C, Pascal, Foxpro)? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-07-31 22:33 +0800
    Re: What is a genius programmer (e.g. C, Pascal, Foxpro)? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-31 22:47 +0800
      Re: What is a genius programmer (e.g. C, Pascal, Foxpro)? BGB <cr88192@gmail.com> - 2026-08-04 15:27 -0500
        Re: What is a genius programmer (e.g. C, Pascal, Foxpro)? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 05:22 +0800
          Re: What is a genius programmer (e.g. C, Pascal, Foxpro)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-05 07:24 +0000
    Re: What is a genius programmer (e.g. C, Pascal, Foxpro)? R Kym Horsell <kym@sdf.org> - 2026-07-31 17:09 +0000
    Re: What is a genius programmer (e.g. C, Pascal, Foxpro)? John McCue <jmclnx@gmail.com.invalid> - 2026-08-03 21:15 +0000
    Understanding difference Queue and Mutex? (Was: What is a genius programmer) Mild Shock <janburse@fastmail.fm> - 2026-08-03 23:35 +0200
      What does Dmitry Vyukov teach us? (Was: Understanding difference Queue and Mutex?) Mild Shock <janburse@fastmail.fm> - 2026-08-03 23:36 +0200
        Parking is more expensive than spinning (Re: What does Dmitry Vyukov teach us?) Mild Shock <janburse@fastmail.fm> - 2026-08-03 23:44 +0200
          In Praise of Slacking (Was: Parking is more expensive than spinning) Mild Shock <janburse@fastmail.fm> - 2026-08-03 23:56 +0200
            Re: In Praise of Slacking (Was: Parking is more expensive than spinning) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-04 08:29 +0800
              You should write a blog about it [(Was: In Praise of Slacking) Mild Shock <janburse@fastmail.fm> - 2026-08-04 02:49 +0200
                Re: You should write a blog about it [(Was: In Praise of Slacking) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-04 09:47 +0800

#124501 — What is a genius programmer (e.g. C, Pascal, Foxpro)?

What is a genius programmer?

-- 

    @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
   / v \  May the Force and farces be with you! Live long and prosper!!
  /( _ )\ https://sites.google.com/site/changmw/
    ^ ^   https://github.com/changmw/changmw
          The game is afoot... Meow...

[toc] | [next] | [standalone]

#124504

On 31/07/2026 10:33 PM, Mr. Man-wai Chang wrote:
> 
> What is a genius programmer?
> 

I don't know.  I've found myself to be approximately the smartest
person in any given project.  I don't do active "IQ" measurements,
nor one-up-manship in team projects.

I've noticed a lot of comp.lang.c regulars think they own the place,
and can dictate who is and isn't a "smart programmer."  Mostly I find
such posturing stupid.

They know who they are.

-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com

[toc] | [prev] | [next] | [standalone]

#124585

On 7/31/2026 9:47 AM, Johann 'Myrkraverk' Oskarsson wrote:
> On 31/07/2026 10:33 PM, Mr. Man-wai Chang wrote:
>>
>> What is a genius programmer?
>>
> 
> I don't know.  I've found myself to be approximately the smartest
> person in any given project.  I don't do active "IQ" measurements,
> nor one-up-manship in team projects.
> 

Similar experience sometimes.

I know about where my IQ score is, but don't want to flaunt it, 
seemingly, I have enough to do the things that I do, and maybe not 
enough for the things I don't do. It seems to roughly balance out in 
this sense at least.

One can be, by conventional metrics, near the upper end of human 
capability, but among other "actually smart people", just kinda meh...


Usually not worth saying or trying to brag. If others are around a 
similar level, they will not care. If others are lower, they will think 
one is trying to one-up them, and/or assume that one thinks that being 
"more smart" means one is also (or thinks they are) entitled to more or 
to special treatment or whatever (or, people might go on the whole "if 
you are so smart, why aren't you rich/famous?!" thing).

But, then failing to realize that this is akin to going up to, say, 
someone who is 6'4" or whatever and being like, "If you are so giant, 
why not knocking over mountains?". Like, in much the same way, a person 
can be the tallest person in the room and still not have anything 
particularly "superhuman" in an absolute sense.


Well, say, because in this case the actual relative/immediate difference 
in ability is comparably minor, but compounds over time to lead to 
different trajectories. Not all trajectories lead to fame and/or wealth.



Some just lead to a tendency to obsess on technical interests and projects.

Well, and my power isn't really "top of the world" intelligence, but 
rather apparently the feature of "near superhuman levels of ability to 
focus on technical esoteria" (can obsess on things well past the point 
where others would have gotten bored and gone off to something different).

Well, or leave background mental tasks grinding away at random things, 
or allowing multiple paths to coexist (sometimes, actually, it is 
"mental single-tasking" that is more difficult). Well, or to some 
extent, I am fragmented, and while one of my personas manages the 
outside world, another goes on obsessing on whatever half-interesting 
things I last encountered (well, and the personas can have disagreements 
on various points as well; converging when one path or another becomes 
"sufficiently eliminated").

Well, I am not a person with any real skill at planning or long range 
thinking, more just sort of a lot of bottom-up patterns and actions that 
aim to skew probabilities towards more desirable outcomes (whether or 
not any materialize being a more secondary matter).

If one does try to plan something, almost invariably it blows up in some 
way, with the sequence of events falling out-of-sync with the 
planned-for event sequence. Like, it being annoyingly difficult to know 
in advance what all things will happen, what everyone will say and how 
they will respond to each specific scenario, etc; so it is necessary to 
take a more probabilistic or heuristic approach to things.

Ability to run scenarios and possible response chains and similar in 
advance sometimes fails to keep up with real-time (but, at the same 
time, can't really maintain every possible tree in advance either). Not 
really sure how more normal people manage this stuff.

...



Well, and sometimes just feeling stupid, where I encountered something 
that seemed like a mystery ("why is some code running an order of 
magnitude slower than expected?"), only to look at the Makefile and 
realized that it was being compiled using stupid flags ("/Os" with MSVC, 
then looking into it and being like, "Yeah... That seems to have been 
the issue...").

Though to be fair, typically the delta between "/Os" or "/O0" and "/O1" 
or "/O2" is usually more around 2x than 10x. No real difference between 
"/O1" and "/O2" in this case ("/O2" is sometimes faster, sometimes 
slower, but usually a whole lot bulkier).

I think it was a side effect of before I switched the Makefile to "/Os" 
to try to evaluate binary sizes and forgot to switch it back. Then 
realized I had misunderstood what "/Os" was supposed to do here 
(thinking it was like "-Os" in GCC or similar), hence why it sucked.

Say:
   GCC:
     -O0: "Load, Load. Op, Store"
     -O1: Basic opts
     -O2: More opts (but stay sane).
     -O3: Go fast and break stuff.
     -Os: Optimize for smallest binary.
   Vs, MSVC:
     /O0: "Load, Load. Op, Store"
     /O1: Fast but Small (less autovectorization)
     /O2: Fast but Fast (lots of autovectorization)
     /Os: Apparently merely specifies a size-optimization preference.
       Doesn't actually do much on its own.

Annoyingly, MSVC lacks an "optimize everything but disable 
auto-vectorization" option; because its auto-vectorization is a foot gun 
(more so if AVX is enabled, then the program gets actively slower). 
Presumably MSVC being tuned for CPUs where aggressive auto-vectorization 
and using AVX ops when enabled is a net-win (rather than detrimental).

Well, at least luckily I am no longer running a CPU with spectacularly 
slow integer divide.


> I've noticed a lot of comp.lang.c regulars think they own the place,
> and can dictate who is and isn't a "smart programmer."  Mostly I find
> such posturing stupid.
> 
> They know who they are.
> 

I used to be more disinclined towards the standards-obsessed "nasal 
demons" crowd, but realized they are more just a different perspective 
(as in, approaching it from a "plain programmer only that wants to write 
code that could potentially run on anything" stance).

Whereas, say:
"I have a handful of targets I care about, and all of them work in this 
particular way." is a different stance, as is "The corpus of existing 
code tends to expect this particular language construct to behave in 
this particular way, else chaos ensues" (so if implementing a compiler, 
it is well advised to keep this particular behavior).



It also being possible to find the line for what places one can cut 
corners to avoid needless costs. Some standards went the other direction 
and had over-specified some things, and one may find it better to simply 
disregard the actual standard and take an official stance of non-compliance.


Like, I can be like:
Yeah, my FPU doesn't actually fully implement IEEE-754, but for most 
code, it doesn't actually matter (and, for the code that it does, one 
can have the option to fall back to trap-and-emulate or similar).

Some use-cases instead need speed as the overriding concern, with any 
semblance of accuracy being optional. Some others falling into the 
domain of needing a certain amount, but beyond this, it ceases to matter.

Typically, the properties that actually matter to code are more indirect 
things that were not formally specified.


The formats matter though, these are basically non-negotiable in 
practice (and there is no obvious "cheaper alternative" either). Say, 
while one could save some logic cost in some places by going to a 
non-normalized format, this would make other cases more expensive, so 
the normalized-only formats make sense.


Say:
   *(float *)(&y)=*(float *)(&x);
One making the observation that code exists that will break if y does 
not contain a bit-identical copy of x.

Well, and while sub-ULP rounding doesn't usually matter, the ability of 
exact inputs to produce exact outputs when staying within the precision 
range of the mantissa, does actually matter.

Like, if one cuts enough corners such that:
   1.0-3.0 => -1.999999
This is no longer acceptable (for scalar code), and code will start 
breaking.

Though, such a restriction can be relaxed for SIMD operations (assuming 
that auto-vectorization is not allowed for these ops). SIMD operations 
can either go through the SIMD unit (fast but inaccurate) or main FPU 
(slower but more accurate) depending on specific operation and parameters.


So, practically, one doesn't end up with a single do-everything, but 3 
sub-tools:
   Fast but inaccurate (SIMD unit);
     4 FP-ops per cycle throughput
     Claim to accuracy: "Mostly respects all the mantissa bits..."
     Only does Binary16 and Binary32 (but, poorly for the latter).
   Slower but more accurate scalar unit:
     Non-pipelined, everything takes 6/10/12 cycles;
     Acceptable for more general purpose use.
     Can use trap-and-emulate fallbacks for more accuracy.
     If not strict-mode enabled, uses DAZ/FTZ.
   Strict Mode:
     Enables trap-and-emulate for accuracy;
     Often needlessly slower for most code.
     controlled as a compiler command-line option.
       Some instructions need to be explicitly forbidden.
       Load/Store + Convert or Op+Convert: Forbidden.
     This mode respecting things like subnormal numbers, etc.


Then, per format:
   short float : Binary16, assumes speed and low accuracy as priority
   float       : Binary32, scalar form, assumes accuracy (so, main FPU);
   double      : Binary64, main FPU only
   long double : Binary128, trap-and-emulate only.
     Unlike the others, Binary128 tends to assume strict IEEE semantics.

Can note also:
   double fma(double x, double y, double z);
     Internally needs to use Binary128 for accurate results.
   long double fmal(long double x, long double y, long double z);
     Internally needs to use Binary256 for accurate results.

Realistically, neither larger format can be supported by the FPU, seemed 
better to invest in 128-bit ALU ops and large-integer arithmetic here.


Note that in this case, in the case of RV64G support, some ops needed to 
be implement via trap-and-emulate to match the specified semantics, but 
this does mean that (if compiling code with GCC, and GCC uses them 
implicitly), there is a severe speed penalty.


So, basically:
   FMADD.D/FNMADD.D/...
   FDIV.x/FSQRT.x
Are: Don't use, these are slow.

In the case of FMADD and similar, it is because FMADD.x specifies 
single-rounding,
   FPU can't do this natively for Binary64.
   Except for Binaty16 and Binary32, which the FPU can do in HW.
     Mostly because, internally, the Binary64 path has enough bits.

Other people are allowed to implement a more proper FPU though, as there 
is nothing mandating the FPU needs to suck.


But, this sort of thing can get annoyingly controversial.

[toc] | [prev] | [next] | [standalone]

#124586

On 05/08/2026 4:27 AM, BGB wrote:
> On 7/31/2026 9:47 AM, Johann 'Myrkraverk' Oskarsson wrote:
>> On 31/07/2026 10:33 PM, Mr. Man-wai Chang wrote:
>>>
>>> What is a genius programmer?
>>>
>>
>> I don't know.  I've found myself to be approximately the smartest
>> person in any given project.  I don't do active "IQ" measurements,
>> nor one-up-manship in team projects.
>>
> 
> Similar experience sometimes.
> 
> I know about where my IQ score is, but don't want to flaunt it, 
> seemingly, I have enough to do the things that I do, and maybe not 
> enough for the things I don't do. It seems to roughly balance out in 
> this sense at least.
> 
> One can be, by conventional metrics, near the upper end of human 
> capability, but among other "actually smart people", just kinda meh...

Really capable people often recognize one another.  I remember decades
ago, when I was starting out programming the PlayStation 2, as a hobby,
and then professionals had no problem teaching me.  I don't mean on the
technical level, but social.  I was dedicated enough that I used the
tools at my disposal which weren't much.  Back then, I didn't know about
SPIM, Mars, and the related emulators; or they didn't exist.  I was
struggling with the assembly code without a budget to buy a book to
help.

Anyway, those social contacts managed to get me a tour through the
studio that made Hitman, and other games; back when they were in
Denmark.  I'm not sure that game studio still exists, nor do I recall
their name at the moment.

> 
> 
> Usually not worth saying or trying to brag. If others are around a 
> similar level, they will not care. If others are lower, they will think 
> one is trying to one-up them, and/or assume that one thinks that being 
> "more smart" means one is also (or thinks they are) entitled to more or 
> to special treatment or whatever (or, people might go on the whole "if 
> you are so smart, why aren't you rich/famous?!" thing).

If you ever read /End of Alchemy/ by Mervyn King, who was at some time
working for the -- I think it's called -- the British Mint, you'll find
that most people who get wealthy do so because of luck.

Though that was probably just a minor paragraph in the whole book.

And most, if not all, programmers -- I'll stick to programmers for the
time being -- who got rich, got rich because of external factors they
mostly weren't aware of.

I can make the case that for instance Microsoft got wealthy because of
the 1992 memory shortage.  It was probably the primary cause companies
computerizing their offices in the 90s chose IBM compatible PCs over
DEC VAXen, or Unix workstations.

You can prove me wrong, of course, by traveling back in time and remove
the 1992 memory crisis.

> 
> But, then failing to realize that this is akin to going up to, say, 
> someone who is 6'4" or whatever and being like, "If you are so giant, 
> why not knocking over mountains?". Like, in much the same way, a person 
> can be the tallest person in the room and still not have anything 
> particularly "superhuman" in an absolute sense.
> 
> 
> Well, say, because in this case the actual relative/immediate difference 
> in ability is comparably minor, but compounds over time to lead to 
> different trajectories. Not all trajectories lead to fame and/or wealth.
> 
> 
> 
> Some just lead to a tendency to obsess on technical interests and projects.


I'm kind of the same.  I had a lot of opportunities to "invest" in the
stock market, and even cryptocurrencies, but chose back then to invest
in myself by buying books, study, and learn all kinds of things.

I'm not "poor" now, but I have a job -- or will have a job soon -- and
just want to live a normal life.

And whether my choices back then will lead to a different kind of wealth
just remains to be seen.

> 
> Well, and my power isn't really "top of the world" intelligence, but 
> rather apparently the feature of "near superhuman levels of ability to 
> focus on technical esoteria" (can obsess on things well past the point 
> where others would have gotten bored and gone off to something different).
> 
> Well, or leave background mental tasks grinding away at random things, 
> or allowing multiple paths to coexist (sometimes, actually, it is 
> "mental single-tasking" that is more difficult). Well, or to some 
> extent, I am fragmented, and while one of my personas manages the 
> outside world, another goes on obsessing on whatever half-interesting 
> things I last encountered (well, and the personas can have disagreements 
> on various points as well; converging when one path or another becomes 
> "sufficiently eliminated").

I'm sort of the same, but also I have different talents.  My "skillset"
so to speak isn't limited to technology and computers.  Just recently I
decided to learn to play the violin, and it's all kinds of fun.

> 
> Well, I am not a person with any real skill at planning or long range 
> thinking, more just sort of a lot of bottom-up patterns and actions that 
> aim to skew probabilities towards more desirable outcomes (whether or 
> not any materialize being a more secondary matter).
> 
> If one does try to plan something, almost invariably it blows up in some 
> way, with the sequence of events falling out-of-sync with the planned- 
> for event sequence. Like, it being annoyingly difficult to know in 
> advance what all things will happen, what everyone will say and how they 
> will respond to each specific scenario, etc; so it is necessary to take 
> a more probabilistic or heuristic approach to things.

There is an old saying about men making plans, and the gods laughing.
Just let the gods laugh, and deal with life as it happens.  Enjoy it.

> 
> Ability to run scenarios and possible response chains and similar in 
> advance sometimes fails to keep up with real-time (but, at the same 
> time, can't really maintain every possible tree in advance either). Not 
> really sure how more normal people manage this stuff.


We -- the regular humans -- aren't trying to prognosticate the future.
Let's leave that to Nostradamus and the like.

> Well, and sometimes just feeling stupid, where I encountered something 
> that seemed like a mystery ("why is some code running an order of 
> magnitude slower than expected?"), only to look at the Makefile and 
> realized that it was being compiled using stupid flags ("/Os" with MSVC, 
> then looking into it and being like, "Yeah... That seems to have been 
> the issue...").

Yes, sometimes we do run into our past, and other people's stupidity.  I
have run into a global ISAM table locking an entire site because it was
important to someone to run statistics.

Changing that to InnoDB fixed the global locking problem.

> 
> Though to be fair, typically the delta between "/Os" or "/O0" and "/O1" 
> or "/O2" is usually more around 2x than 10x. No real difference between 
> "/O1" and "/O2" in this case ("/O2" is sometimes faster, sometimes 
> slower, but usually a whole lot bulkier).
> 
> I think it was a side effect of before I switched the Makefile to "/Os" 
> to try to evaluate binary sizes and forgot to switch it back. Then 
> realized I had misunderstood what "/Os" was supposed to do here 
> (thinking it was like "-Os" in GCC or similar), hence why it sucked.
> 
> Say:
>    GCC:
>      -O0: "Load, Load. Op, Store"
>      -O1: Basic opts
>      -O2: More opts (but stay sane).
>      -O3: Go fast and break stuff.
>      -Os: Optimize for smallest binary.
>    Vs, MSVC:
>      /O0: "Load, Load. Op, Store"
>      /O1: Fast but Small (less autovectorization)
>      /O2: Fast but Fast (lots of autovectorization)
>      /Os: Apparently merely specifies a size-optimization preference.
>        Doesn't actually do much on its own.
> 
> Annoyingly, MSVC lacks an "optimize everything but disable auto- 
> vectorization" option; because its auto-vectorization is a foot gun 
> (more so if AVX is enabled, then the program gets actively slower). 
> Presumably MSVC being tuned for CPUs where aggressive auto-vectorization 
> and using AVX ops when enabled is a net-win (rather than detrimental).


And not to mention that some CPUs run at lower clock speed with AVX
enabled.  As far as I know, nobody in terms of compiler optimizations
takes that into account.

If you're aware of a paper or a benchmark that shows how and when it's
better to use AVX vs. normal code running on a CPU that has higher clock
frequency without the AVX, please let me know.

> 
> Well, at least luckily I am no longer running a CPU with spectacularly 
> slow integer divide.

Lucky you.  I have a feeling my PIC32 is one of them!
>> I've noticed a lot of comp.lang.c regulars think they own the place,
>> and can dictate who is and isn't a "smart programmer."  Mostly I find
>> such posturing stupid.
>>
>> They know who they are.
>>
> 
> I used to be more disinclined towards the standards-obsessed "nasal 
> demons" crowd, but realized they are more just a different perspective 
> (as in, approaching it from a "plain programmer only that wants to write 
> code that could potentially run on anything" stance).
> 
> Whereas, say:
> "I have a handful of targets I care about, and all of them work in this 
> particular way." is a different stance, as is "The corpus of existing 
> code tends to expect this particular language construct to behave in 
> this particular way, else chaos ensues" (so if implementing a compiler, 
> it is well advised to keep this particular behavior).

The problem is sometimes the standards committee, and sometimes the
people making the compilers.  We're "told" it's always the programmers'
faults when things go haywire on a different system, or a different com-
piler, but I make the case -- without anecdotal details this time --
that the compiler makers and/or the standards committee are /stupid
evil/, the worst alignment out there.
> It also being possible to find the line for what places one can cut 
> corners to avoid needless costs. Some standards went the other direction 
> and had over-specified some things, and one may find it better to simply 
> disregard the actual standard and take an official stance of non- 
> compliance.
> 
> 
> Like, I can be like:
> Yeah, my FPU doesn't actually fully implement IEEE-754, but for most 
> code, it doesn't actually matter (and, for the code that it does, one 
> can have the option to fall back to trap-and-emulate or similar).
> 
> Some use-cases instead need speed as the overriding concern, with any 
> semblance of accuracy being optional. Some others falling into the 
> domain of needing a certain amount, but beyond this, it ceases to matter.
> 
> Typically, the properties that actually matter to code are more indirect 
> things that were not formally specified.


The needs of the individual, or the organization sponsoring the code,
matter a lot.  And those sometimes conflict with the people making the
computers, and/or the compilers.  I'll not expand on that today.
> The formats matter though, these are basically non-negotiable in 
> practice (and there is no obvious "cheaper alternative" either). Say, 
> while one could save some logic cost in some places by going to a non- 
> normalized format, this would make other cases more expensive, so the 
> normalized-only formats make sense.
> 
> 
> Say:
>    *(float *)(&y)=*(float *)(&x);
> One making the observation that code exists that will break if y does 
> not contain a bit-identical copy of x.
> 
> Well, and while sub-ULP rounding doesn't usually matter, the ability of 
> exact inputs to produce exact outputs when staying within the precision 
> range of the mantissa, does actually matter.
> 
> Like, if one cuts enough corners such that:
>    1.0-3.0 => -1.999999
> This is no longer acceptable (for scalar code), and code will start 
> breaking.
> 
> Though, such a restriction can be relaxed for SIMD operations (assuming 
> that auto-vectorization is not allowed for these ops). SIMD operations 
> can either go through the SIMD unit (fast but inaccurate) or main FPU 
> (slower but more accurate) depending on specific operation and parameters.
> 
> 
> So, practically, one doesn't end up with a single do-everything, but 3 
> sub-tools:
>    Fast but inaccurate (SIMD unit);
>      4 FP-ops per cycle throughput
>      Claim to accuracy: "Mostly respects all the mantissa bits..."
>      Only does Binary16 and Binary32 (but, poorly for the latter).
>    Slower but more accurate scalar unit:
>      Non-pipelined, everything takes 6/10/12 cycles;
>      Acceptable for more general purpose use.
>      Can use trap-and-emulate fallbacks for more accuracy.
>      If not strict-mode enabled, uses DAZ/FTZ.
>    Strict Mode:
>      Enables trap-and-emulate for accuracy;
>      Often needlessly slower for most code.
>      controlled as a compiler command-line option.
>        Some instructions need to be explicitly forbidden.
>        Load/Store + Convert or Op+Convert: Forbidden.
>      This mode respecting things like subnormal numbers, etc.
> 
> 
> Then, per format:
>    short float : Binary16, assumes speed and low accuracy as priority
>    float       : Binary32, scalar form, assumes accuracy (so, main FPU);
>    double      : Binary64, main FPU only
>    long double : Binary128, trap-and-emulate only.
>      Unlike the others, Binary128 tends to assume strict IEEE semantics.
> 
> Can note also:
>    double fma(double x, double y, double z);
>      Internally needs to use Binary128 for accurate results.
>    long double fmal(long double x, long double y, long double z);
>      Internally needs to use Binary256 for accurate results.
> 
> Realistically, neither larger format can be supported by the FPU, seemed 
> better to invest in 128-bit ALU ops and large-integer arithmetic here.
> 
> 
> Note that in this case, in the case of RV64G support, some ops needed to 
> be implement via trap-and-emulate to match the specified semantics, but 
> this does mean that (if compiling code with GCC, and GCC uses them 
> implicitly), there is a severe speed penalty.
> 
> 
> So, basically:
>    FMADD.D/FNMADD.D/...
>    FDIV.x/FSQRT.x
> Are: Don't use, these are slow.
> 
> In the case of FMADD and similar, it is because FMADD.x specifies 
> single-rounding,
>    FPU can't do this natively for Binary64.
>    Except for Binaty16 and Binary32, which the FPU can do in HW.
>      Mostly because, internally, the Binary64 path has enough bits.
> 
> Other people are allowed to implement a more proper FPU though, as there 
> is nothing mandating the FPU needs to suck.
> 
> 
> But, this sort of thing can get annoyingly controversial.
> 
> 

I would be much happier of more CPU cores implemented hardware
accelerated monetary calculations.  My go to reference in C is

   https://github.com/dnotq/decNumber/

but this library has a few drawbacks.  The only upshot is that
it's the reference library and is therefore likely to be as accurate
as you can get, in C.


Now, I can hear the standard thumping trolls scream "but we don't
implement monetary transactions in C!"  And that's only their own
fault.

I've now added comp.arch to the discussion, so they can add their
input on hardware accelerated monetary transactions.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#124591

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>I can make the case that for instance Microsoft got wealthy because of
>the 1992 memory shortage.

Asking search engines for "1992 memory shortage" brought up no sign of
a 1992 memory shortage, but an article about a 1988 memory shortage,
which says:

|The 1988 shortage, while the most painful, isn’t history’s only RAM
|shortage. For example, in 1995, a fire on Penang Island in Malaysia
|caused a power outage so dramatic that semiconductor factories were
|shut down for nearly three weeks.

Looking at <https://humanprogress.org/dataset/historical_price_of_computer_memory_and_storage?countries=Historical+price+of+memory-Historical+price+of+flash+memory-Historical+price+of+disk+drives-Historical+price+of+solid-state+drives&primary-data=10811&compare=null&chart-type=Table&view=selected&value-type=score&calc-table-country-a=null&calc-table-country-b=null&x-axis-start=0&x-axis-end=10&y-axis-start=10.617405&y-axis-end=3786967000000000&y-axis-log=false&x-axis-log=false&auto-scale=true&map-color=Monochromatic+Sky&region-calculation=Mean&start-date=1956&end-date=2023&the-year=2023&sort-bar-chart-ascending=true>

The prices per TB for "memory" are:

  1991       1992       1993  
75,538,730 48,417,580 47,029,436

So the price fell from 1991 to 1992, which indicates that there was no
shortage in 1992.  The prices did not fall much from 1992 to 1993.

>It was probably the primary cause companies
>computerizing their offices in the 90s chose IBM compatible PCs over
>DEC VAXen, or Unix workstations.

A shortage that did not exist as explanation, that does not convince
me.

BTW, I bought an IBM compatible PC in 1993, which I used as a "Unix
workstation" (running Linux).

Followups set to comp.arch.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

[toc] | [prev] | [next] | [standalone]

#124514

In comp.lang.c Mr. Man-wai Chang <toylet.toylet@gmail.com> wrote:
> What is a genius programmer?

I think I saw a recent example on this group.

Back in the olden times I worked in the math dept of a small college.
A story went around that a wizz in group theory was doing a programming
course as many staff did. He'd been given an exercise up his alley --
write a program to count the number of ways X. If I think for long enough
I might get the X, but it doesnt matter.
He set to with his color polynomials and mental sliderule and figured
out a formula to calculate the number given the basic parameters of the
problem and wrote a 3 line read param, calculate result, print result
and handed it in. Quelle sooprize -- got an F.

-- 
We'll build a world of our own, that no one else will share
All our sorrows we'll leave far be-hind us there
And I know that you'll find, there'll be peace of mind
When we live in a world of our own 
-- "World of Our Own", (Tom) Springfield Music, May 1965

[toc] | [prev] | [next] | [standalone]

#124558

Follorups to: comp.lang.c

In comp.lang.c Mr. Man-wai Chang <toylet.toylet@gmail.com> wrote:
> 
> What is a genius programmer?
> 

Of course:

https://users.cs.utah.edu/~elb/folklore/mel.html

But to me, someone who gets it done the way the
user wants it the first time and quickly.

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#124562 — Understanding difference Queue and Mutex? (Was: What is a genius programmer)

Hi,

Understanding the difference between Queue and Mutex?

Mutex: A single binary semaphore

Queue: A condition to signal non empty
        A condition to signal non full
        A monitor for the critical section

Monitors were invented by Per Brinch Hansen
and C. A. R. Hoare. Although the critical section
could be modelled by a simple mutex,

The condition wait has to leave the critical
section temporarily, so the conditions sit on
the monitor mutex. So who is the biggest moron?

Well Chris M. Thomasson, I already talk like
for one month, about the need for bounded queues,
but all he can present recently was some

C code for a spin backoff mutex?

Bye

Mr. Man-wai Chang schrieb:
> 
> What is a genius programmer?
> 

[toc] | [prev] | [next] | [standalone]

#124563 — What does Dmitry Vyukov teach us? (Was: Understanding difference Queue and Mutex?)

Hi,

The clever soluton by Dmitry Vyukov shows
that the monitor is not necessarily canonical, when
we allow spinning. But spinning sometimes runs

counter to what we expect an operating system
respectively a language runtime does with processes
and threads, namely they are parked.

The absense of parking in GPU can now give the
false impression, that spinning is not allowed.
But why did Dmitry Vyukov develop his solution,

and had a website called 1000 cores? Because
with a large number of cores and certain systolic
payloads, i.e. always enough work for all threads,

the operating systems model of 2000 threads being
parked, this requirement can severly be challenged,
and allows a fundamental rethinking.

Bye

Mild Shock schrieb:
> Hi,
> 
> Understanding the difference between Queue and Mutex?
> 
> Mutex: A single binary semaphore
> 
> Queue: A condition to signal non empty
>         A condition to signal non full
>         A monitor for the critical section
> 
> Monitors were invented by Per Brinch Hansen
> and C. A. R. Hoare. Although the critical section
> could be modelled by a simple mutex,
> 
> The condition wait has to leave the critical
> section temporarily, so the conditions sit on
> the monitor mutex. So who is the biggest moron?
> 
> Well Chris M. Thomasson, I already talk like
> for one month, about the need for bounded queues,
> but all he can present recently was some
> 
> C code for a spin backoff mutex?
> 
> Bye
> 
> Mr. Man-wai Chang schrieb:
>>
>> What is a genius programmer?
>>
> 

[toc] | [prev] | [next] | [standalone]

#124566 — Parking is more expensive than spinning (Re: What does Dmitry Vyukov teach us?)

Hi,

One core problem in the design of algorithms
for a large number of cores, such as found in a
GPU, and in general, is the fact, that parking

is most often more expensive than spinning.
So if you have short wait times or few waiters ,
the cost model looks favorable if you use

spinning, versus the same thing implemented
with parking. The Java libraries by Doug Lea found
in java.concurrency go even that far to use hybrid

algorithms, that use spinning and parking. I guess
its pretty easy, you just do backoff by using parking.

Bye

Mild Shock schrieb:
> Hi,
> 
> The clever soluton by Dmitry Vyukov shows
> that the monitor is not necessarily canonical, when
> we allow spinning. But spinning sometimes runs
> 
> counter to what we expect an operating system
> respectively a language runtime does with processes
> and threads, namely they are parked.
> 
> The absense of parking in GPU can now give the
> false impression, that spinning is not allowed.
> But why did Dmitry Vyukov develop his solution,
> 
> and had a website called 1000 cores? Because
> with a large number of cores and certain systolic
> payloads, i.e. always enough work for all threads,
> 
> the operating systems model of 2000 threads being
> parked, this requirement can severly be challenged,
> and allows a fundamental rethinking.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Understanding the difference between Queue and Mutex?
>>
>> Mutex: A single binary semaphore
>>
>> Queue: A condition to signal non empty
>>         A condition to signal non full
>>         A monitor for the critical section
>>
>> Monitors were invented by Per Brinch Hansen
>> and C. A. R. Hoare. Although the critical section
>> could be modelled by a simple mutex,
>>
>> The condition wait has to leave the critical
>> section temporarily, so the conditions sit on
>> the monitor mutex. So who is the biggest moron?
>>
>> Well Chris M. Thomasson, I already talk like
>> for one month, about the need for bounded queues,
>> but all he can present recently was some
>>
>> C code for a spin backoff mutex?
>>
>> Bye
>>
>> Mr. Man-wai Chang schrieb:
>>>
>>> What is a genius programmer?
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#124567 — In Praise of Slacking (Was: Parking is more expensive than spinning)

Hi,

While in 2012 spinning was absolute no go,
reflecting somehow the economic mantra
of rationalization:

“I want to say, in all seriousness, that a
great deal of harm is being done in the
modern world by belief in the virtuousness
of work, and that the road to happiness
and prosperity lies in an organised
diminution of work.”
-- Bertrand Russell, In Praise of Idleness

My work premis on the other hand, is challenging
the root assumption behind the economic mantra,
which is scarce resources. We can see the GPU

as a device that provides a place for slacking
at the workplace, lifting procrastination to
the status of working:

   I'm a spinner, I'm a sinner
   I spin on CAS loops for my dinner
   Some call it busy-wait, I call it fate
   When the queue is empty, I just rotate

Bye

Mild Shock schrieb:
> Hi,
> 
> One core problem in the design of algorithms
> for a large number of cores, such as found in a
> GPU, and in general, is the fact, that parking
> 
> is most often more expensive than spinning.
> So if you have short wait times or few waiters ,
> the cost model looks favorable if you use
> 
> spinning, versus the same thing implemented
> with parking. The Java libraries by Doug Lea found
> in java.concurrency go even that far to use hybrid
> 
> algorithms, that use spinning and parking. I guess
> its pretty easy, you just do backoff by using parking.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> The clever soluton by Dmitry Vyukov shows
>> that the monitor is not necessarily canonical, when
>> we allow spinning. But spinning sometimes runs
>>
>> counter to what we expect an operating system
>> respectively a language runtime does with processes
>> and threads, namely they are parked.
>>
>> The absense of parking in GPU can now give the
>> false impression, that spinning is not allowed.
>> But why did Dmitry Vyukov develop his solution,
>>
>> and had a website called 1000 cores? Because
>> with a large number of cores and certain systolic
>> payloads, i.e. always enough work for all threads,
>>
>> the operating systems model of 2000 threads being
>> parked, this requirement can severly be challenged,
>> and allows a fundamental rethinking.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Understanding the difference between Queue and Mutex?
>>>
>>> Mutex: A single binary semaphore
>>>
>>> Queue: A condition to signal non empty
>>>         A condition to signal non full
>>>         A monitor for the critical section
>>>
>>> Monitors were invented by Per Brinch Hansen
>>> and C. A. R. Hoare. Although the critical section
>>> could be modelled by a simple mutex,
>>>
>>> The condition wait has to leave the critical
>>> section temporarily, so the conditions sit on
>>> the monitor mutex. So who is the biggest moron?
>>>
>>> Well Chris M. Thomasson, I already talk like
>>> for one month, about the need for bounded queues,
>>> but all he can present recently was some
>>>
>>> C code for a spin backoff mutex?
>>>
>>> Bye
>>>
>>> Mr. Man-wai Chang schrieb:
>>>>
>>>> What is a genius programmer?
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#124569 — Re: In Praise of Slacking (Was: Parking is more expensive than spinning)

On 04/08/2026 5:56 AM, Mild Shock wrote:
> Hi,
> 
> While in 2012 spinning was absolute no go,
> reflecting somehow the economic mantra
> of rationalization:
> 
> “I want to say, in all seriousness, that a
> great deal of harm is being done in the
> modern world by belief in the virtuousness
> of work, and that the road to happiness
> and prosperity lies in an organised
> diminution of work.”
> -- Bertrand Russell, In Praise of Idleness
> 
> My work premis on the other hand, is challenging
> the root assumption behind the economic mantra,
> which is scarce resources. We can see the GPU
> 
> as a device that provides a place for slacking
> at the workplace, lifting procrastination to
> the status of working:
> 
>    I'm a spinner, I'm a sinner
>    I spin on CAS loops for my dinner
>    Some call it busy-wait, I call it fate
>    When the queue is empty, I just rotate
> 

I found some old code recently that used

#include <stdlib.h>
#pragma intrinsic ( _rotl )
#define rotl32( x, c ) _rotl( x, c )

with the comment that this intrinsic is not documented as such on the
Microsoft website.  I hope this tidbit is of use to someone who wants
to implement bit rotation as a single instruction.  I have not tested
this on VS 2026 yet,  so please let me know if this  doesn't work for
your use case.


Best wishes, and happy rotation!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#124570 — You should write a blog about it [(Was: In Praise of Slacking)

Hi,

You should write a blog about it. Could
give new live to the blog in your footer.
The blog has also seen better times,

the last post was July 20, 2020. And then?
The big reset? All brain cells gone?

Bye

Johann 'Myrkraverk' Oskarsson schrieb:
 >> When the queue is empty, I just rotate
 >
> I have not tested this on VS 2026 yet,  so 
> please let me know if this  doesn't work for
> your use case.

 > Johann | email: invalid -> com | http://www.myrkraverk.com/blog/

[toc] | [prev] | [next] | [standalone]

#124572 — Re: You should write a blog about it [(Was: In Praise of Slacking)

On 04/08/2026 8:49 AM, Mild Shock wrote:
> Hi,
> 
> You should write a blog about it. Could
> give new live to the blog in your footer.
> The blog has also seen better times,
> 
> the last post was July 20, 2020. And then?
> The big reset? All brain cells gone?

Life happened.  Thanks for caring.  I did micro-blog with WordPerfect
for DOS on a different website for a bit, but haven't picked that up
either.  Blogging is not a priority now.  I'm picking up coding again
after an extended break.  By that I mean my own projects.  My next job
is also on hold for a few more months.  They know how to reach me if
they need me in a hurry.

And my braincells are functioning even better than in 2020.

And on that subject, is there a better blogging platform than Word-
Perfect for DOS?  I used to write the blog entries in WPDOS, then
open with WPwin2021 and export to HTML.  That works fine for some
workflows, but does get cumbersome after a while.

All the open source blogging platforms seem geared towards SEO and
monetization, which isn't a priority for me, with my personal blog.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web