From Newsgroup: comp.arch
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