From Newsgroup: comp.lang.c

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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-a-a-a-a-a A condition to signal non full
-a-a-a-a-a-a 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?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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-a-a-a-a-a-a A condition to signal non full
-a-a-a-a-a-a-a 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?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Hi,

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

rCLI 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.rCY
-- 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-a-a-a-a-a-a A condition to signal non full
-a-a-a-a-a-a-a 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?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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:

rCLI 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.rCY
-- 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:

-a I'm a spinner, I'm a sinner
-a I spin on CAS loops for my dinner
-a Some call it busy-wait, I call it fate
-a 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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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,-a so
please let me know if this-a doesn't work for
your use case.

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

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.-a I've found myself to be approximately the smartest
person in any given project.-a 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."-a 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.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.-a I've found myself to be approximately the smartest
person in any given project.-a 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:
-a GCC:
-a-a-a -O0: "Load, Load. Op, Store"
-a-a-a -O1: Basic opts
-a-a-a -O2: More opts (but stay sane).
-a-a-a -O3: Go fast and break stuff.
-a-a-a -Os: Optimize for smallest binary.
-a Vs, MSVC:
-a-a-a /O0: "Load, Load. Op, Store"
-a-a-a /O1: Fast but Small (less autovectorization)
-a-a-a /O2: Fast but Fast (lots of autovectorization)
-a-a-a /Os: Apparently merely specifies a size-optimization preference.
-a-a-a-a-a 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."-a 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:
-a *(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:
-a 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:
-a Fast but inaccurate (SIMD unit);
-a-a-a 4 FP-ops per cycle throughput
-a-a-a Claim to accuracy: "Mostly respects all the mantissa bits..."
-a-a-a Only does Binary16 and Binary32 (but, poorly for the latter).
-a Slower but more accurate scalar unit:
-a-a-a Non-pipelined, everything takes 6/10/12 cycles;
-a-a-a Acceptable for more general purpose use.
-a-a-a Can use trap-and-emulate fallbacks for more accuracy.
-a-a-a If not strict-mode enabled, uses DAZ/FTZ.
-a Strict Mode:
-a-a-a Enables trap-and-emulate for accuracy;
-a-a-a Often needlessly slower for most code.
-a-a-a controlled as a compiler command-line option.
-a-a-a-a-a Some instructions need to be explicitly forbidden.
-a-a-a-a-a Load/Store + Convert or Op+Convert: Forbidden.
-a-a-a This mode respecting things like subnormal numbers, etc.

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

Can note also:
-a double fma(double x, double y, double z);
-a-a-a Internally needs to use Binary128 for accurate results.
-a long double fmal(long double x, long double y, long double z);
-a-a-a 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:
-a FMADD.D/FNMADD.D/...
-a 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,
-a FPU can't do this natively for Binary64.
-a Except for Binaty16 and Binary32, which the FPU can do in HW.
-a-a-a 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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 4 Aug 2026 15:27:55 -0500, BGB wrote:

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

Fun fact: along lots of metrics, most people are above average. ItrCOs
not really that exceptional.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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, isnrCOt historyrCOs 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>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/4/2026 5:51 PM, Lawrence DrCOOliveiro wrote:

On Tue, 4 Aug 2026 15:27:55 -0500, BGB wrote:

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

Fun fact: along lots of metrics, most people are above average. ItrCOs
not really that exceptional.

It is kind of a thing of "versus an average person on a street" or
"versus other programmers".

Like, say, on the street one can represent roughly the top 1% of the population, but among other programmers, it doesn't amount to much
(since likely most of the lower 90% or so had already self-excluded).

But, then one can ask:
Does it actually matter?...


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 5 Aug 2026 13:08:18 -0500, BGB wrote:

On 8/4/2026 5:51 PM, Lawrence DrCOOliveiro wrote:

On Tue, 4 Aug 2026 15:27:55 -0500, BGB wrote:

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

Fun fact: along lots of metrics, most people are above average.
ItrCOs not really that exceptional.

It is kind of a thing of "versus an average person on a street" or
"versus other programmers".

No, itrCOs just simple arithmetic -- how you compute the arithmetic mean
(the usual meaning of rCLaveragerCY) over a population distribution that
is typically skewed upwards somewhat.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/5/2026 2:59 PM, Lawrence DrCOOliveiro wrote:

On Wed, 5 Aug 2026 13:08:18 -0500, BGB wrote:

On 8/4/2026 5:51 PM, Lawrence DrCOOliveiro wrote:

On Tue, 4 Aug 2026 15:27:55 -0500, BGB wrote:

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

Fun fact: along lots of metrics, most people are above average.
ItrCOs not really that exceptional.

It is kind of a thing of "versus an average person on a street" or
"versus other programmers".

No, itrCOs just simple arithmetic -- how you compute the arithmetic mean
(the usual meaning of rCLaveragerCY) over a population distribution that
is typically skewed upwards somewhat.

Well, perhaps the bifurcation algo might help, a little:

https://youtu.be/ovJcsL7vyrk

Fwiw, I made one from pure trig:

https://youtu.be/XKhS_nklCkE

My algo is in the description as pseudo code that can be implemented in
any lang:

A highly experimental #iterated function system of mine that creates
many #fractal #bifurcation diagrams locked in the unit square. Afaict,
the animation makes it appear as if everything is rotating around a
cylinder. Here is my #IFS that was used to create this animation: ______________
// px_mutation interpolates from -4...4 across each frame; 1440 here.

render frames:
_________
// angle interpolates from 0...pi2 across iterations
// px = py = 0

// Iteration:
px = sin(angle * px_mutation);
py = cos(angle * py);
______________

Plot every pixel in the ifs. Actually, I am adding color to each pixel
visited during iteration.
--- Synchronet 3.22a-Linux NewsLink 1.2