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