In article <scpstk$rm3$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> Hmm... a bit of a search turns up a Wikipedia aricle on
> https://en.wikipedia.org/wiki/Novec_649/1230 which cites a source
> that this has already been tried by Intel and SGI, so the
> idea isn't new ...

The original "Merced" Itanium had internal liquid cooling. If you shook
the module that contained the CPU and its cache, you could hear sloshing
IIRC.

John

On 7/15/2021 8:28 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 7/15/2021 4:04 AM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>> On 7/15/2021 3:44 AM, Thomas Koenig wrote:
>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>>>
>>>>>> Currently, the power density of hot chips seems to be at maybe
>>>>>> 200W/cm^2 (140W for a Ryzen 3800XT with 0.7cm^2 chiplet area), with
>>>>>> higher power density in various spots on the die.
>>>>>
>>>>> That's a high enery density, but it is within the range that
>>>>> can be removed by pool boiling, certainly of water, possibly
>>>>> by refrigerants (especially if you have some space between
>>>>> the chips).
>>>>>
>>>>> Mechanical stresses on the delicate chips could be another matter,
>>>>> though.
>>>>>
>>>
>>>> Did you used to work on pressurized water reactors?
>>>
>>> No, but my diploma thesis was in the field of pool boiling,
>>> and the subject of how much heat you can remove by boiling
>>> (a.k.a. the critical heat flux) is a standard topic in studying
>>> chemical engineering.
>>>
>>
>> My second guess was superheaters in steam locomotives :-)
>
> My name is not, and has never been, David Wardale :-) (who, AFAIK,
> was the last person to do serious steam locomotive engineering).
>
> #ifdef PEDANTIC
>
> Superheaters do what the name says, they superheat steam.
> When steam leaves a boiler, is in equilibrium with the liqid it
> is in close contact with. A superheater is a heat exchanger which
> increases the temperature further. This is a pure gas-phase heat
> exchanger, with much lower heat transfer coefficients, but also
> with a much lower heat load, so this is not a big problem.
>
> So, you could in principle use a boiling liquid for cooling
> compouter chips if you can solve the mechanical and other assorted
> problems, but using a steam superheater would make little sense.

Not my understanding, nor Wikipedia's. The input to the superheater is
wet steam, with liquid droplets embedded in the gas phase carrier with
the temperature at the phase boundary for the pressure. A superheater
moves the whole thing into gas phase. The benefit is partly the
additional energy, but they were first introduced for a different
reason: the wet steam would condense in the power cylinders and valves,
leading to maintenance problems. https://en.wikipedia.org/wiki/Superheater

On Thursday, July 15, 2021 at 11:57:10 AM UTC-6, Thomas Koenig wrote:

> So, another liquid would be called for, preferably something legal,
> moral and non-fattening, with a boiling point of around 60°C, or
> maybe a bit lower.

And here I thought it was due to Oscar Wilde, but I see it actually
originated with Alexander Woolcott, and then was taken up by
W. C. Fields.

However, being non-conductive is probably more important in that
application.

John Savard

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Thursday, July 15, 2021 at 12:57:10 PM UTC-5, Thomas Koenig wrote:
>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>> > On Thursday, July 15, 2021 at 9:28:30 AM UTC-6, Thomas Koenig wrote:
>> >
>> >> So, you could in principle use a boiling liquid for cooling
>> >> compouter chips if you can solve the mechanical and other assorted
>> >> problems,
>> >
>> > Isn't that what heat pipes use *already*?
>> Yep, but I was thinking of direct contact of the chips with the
>> boiling liquid (with a thin insulating laryer, presumably).
>>
>> _Much_ more efficient. The nice thing is that your temperature
>> stays pretty much constant as long as there is enough liquid -
>> no hot edges.
><
> And a bit more dangerous. Boiling a liquid requires the liquid to
> create bubbles (of the gas) and these bubbles invariably form at
> the solid liquid interface. These microscopic bubbles can lift the
> solid surface one atom at a time causing the surface to decompose
> over time--limiting lifetime.

Abrasion is not a big issue in pool boiling, especially with
the right choice of materials and design.

Like I said, I would be more concerned about vibrations, but
that could also be reduced by mounting the chips on the
back of, let's say, a thin metal plate with reasonably high
conductivity, and have the boiling liquid on the other side.

On the other hand, if your system havs high-velocity two-phase flow,
that can be quite abrasive. The solution is simple, then: Just don't
design the system that way.

> Non-boiling temperature transfer has much longer actual lifetimes.

For a misdesigned boiling heat transfer system vs. a well-designed
single-phase system, this is certainly true.

If you go to the turbulent regime, you also have vibrations.
In the laminar regime, you have _much_ lower heat transfer
coefficients unless you go micro heat exchanger, and then
you have large pressure drops.

And so on... there's a huge design space with heat exchangers,
and people have been very busy the last 150 years or so.

Question: Is there any actual experience with a cooling through
boiling system, apart from the (apparently) short trials mentioned
at Wikipedia?

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 7/15/2021 8:28 AM, Thomas Koenig wrote:

>> Superheaters do what the name says, they superheat steam.
>> When steam leaves a boiler, is in equilibrium with the liqid it
>> is in close contact with. A superheater is a heat exchanger which
>> increases the temperature further. This is a pure gas-phase heat
>> exchanger, with much lower heat transfer coefficients, but also
>> with a much lower heat load, so this is not a big problem.
>>
>> So, you could in principle use a boiling liquid for cooling
>> compouter chips if you can solve the mechanical and other assorted
>> problems, but using a steam superheater would make little sense.
>
>
> Not my understanding, nor Wikipedia's. The input to the superheater is
> wet steam, with liquid droplets embedded in the gas phase carrier with
> the temperature at the phase boundary for the pressure. A superheater
> moves the whole thing into gas phase. The benefit is partly the
> additional energy, but they were first introduced for a different
> reason: the wet steam would condense in the power cylinders and valves,
> leading to maintenance problems. https://en.wikipedia.org/wiki/Superheater

"Wet steam" is just a nickname for saturated steam.

What you write about maintenance being the reason for introduction
is not what I read in the article, which only mentions maintenance
in the context of maintenance on the superheater, maybe you have
some other source or somebody changed this five minutes ago :-)

The reason why a superheater increases efficiency is that steam
gives off mechanical work during expansion, so it's basically
pressure times volume difference (I will spare you the integrals).
If part of the steam condenses, then there is less volume, therefore
less mechanical work to do. Bringing the steam away from the
saturation line means that it will be less or no condensation
during expansion, leading to more work done and (on the whole)
better efficiency.

You can also do the calculation with an enthalpy-entropy diagram
for water if you're really interested, but you may not be :-)

For piston engines, the problem is worse than for a turbine.
During the expansion of the steam in the cylinder, it cools,
cooling the walls of the cylinder with it. When the hot steam
enters the cylinder in the next cycle, part of it will be
cooled and may condense, so superheating also helps against
those losses.

This is one reason why double or even triple expansion steam
engines were used - the temperature differences in a single
expansion were smaller, thus less cooling down of hot steam.

For turbines, a single spot is always at the same temperature.

Turbines were a failure for steam locomotives becaue of their
poor characteristics when starting, and their poor partial load
characteristics.

There's a book about "failed innovations" that I mislaid about
20 years ago which gives details on this particular failure,
among others. I may have to buy it again, if it is still available.

On 7/15/2021 11:18 PM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Thursday, July 15, 2021 at 12:57:10 PM UTC-5, Thomas Koenig wrote:
>>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>>>> On Thursday, July 15, 2021 at 9:28:30 AM UTC-6, Thomas Koenig wrote:
>>>>
>>>>> So, you could in principle use a boiling liquid for cooling
>>>>> compouter chips if you can solve the mechanical and other assorted
>>>>> problems,
>>>>
>>>> Isn't that what heat pipes use *already*?
>>> Yep, but I was thinking of direct contact of the chips with the
>>> boiling liquid (with a thin insulating laryer, presumably).
>>>
>>> _Much_ more efficient. The nice thing is that your temperature
>>> stays pretty much constant as long as there is enough liquid -
>>> no hot edges.
>> <
>> And a bit more dangerous. Boiling a liquid requires the liquid to
>> create bubbles (of the gas) and these bubbles invariably form at
>> the solid liquid interface. These microscopic bubbles can lift the
>> solid surface one atom at a time causing the surface to decompose
>> over time--limiting lifetime.
>
> Abrasion is not a big issue in pool boiling, especially with
> the right choice of materials and design.
>
> Like I said, I would be more concerned about vibrations, but
> that could also be reduced by mounting the chips on the
> back of, let's say, a thin metal plate with reasonably high
> conductivity, and have the boiling liquid on the other side.
>
> On the other hand, if your system havs high-velocity two-phase flow,
> that can be quite abrasive. The solution is simple, then: Just don't
> design the system that way.
>
>> Non-boiling temperature transfer has much longer actual lifetimes.
>
> For a misdesigned boiling heat transfer system vs. a well-designed
> single-phase system, this is certainly true.
>
> If you go to the turbulent regime, you also have vibrations.
> In the laminar regime, you have _much_ lower heat transfer
> coefficients unless you go micro heat exchanger, and then
> you have large pressure drops.
>
> And so on... there's a huge design space with heat exchangers,
> and people have been very busy the last 150 years or so.
>
> Question: Is there any actual experience with a cooling through
> boiling system, apart from the (apparently) short trials mentioned
> at Wikipedia?
>

Was the ETA systems CPU (liquid nitrogen coolant) boiling the nitrogen?

Thomas Koenig <tkoenig@netcologne.de> writes:
>Quadibloc <jsavard@ecn.ab.ca> schrieb:
>> On Thursday, July 15, 2021 at 9:28:30 AM UTC-6, Thomas Koenig wrote:
>>
>>> So, you could in principle use a boiling liquid for cooling
>>> compouter chips if you can solve the mechanical and other assorted
>>> problems,
>>
>> Isn't that what heat pipes use *already*?
>
>Yep, but I was thinking of direct contact of the chips with the
>boiling liquid (with a thin insulating laryer, presumably).
>
>_Much_ more efficient.

If you can avoid the Leidenfrost effect (where the gaseous phase
insulates the heat source from the cooling liquid (well known from
experiments with liquid nitrogen).

There are systems that use this idea (e.g.,
<https://www.computerbase.de/2017-08/der8auer-aqua-exhalare-zwei-phasen-kuehlung/>),
but for now it does not seem to offer enough advantages to justify the
effort.

>The nice thing is that your temperature
>stays pretty much constant as long as there is enough liquid -
>no hot edges.
>
>Another nice property is that, if your chips run at 70°C (let's
>say) and your vapor comes out the system at 60°C, the vapor is
>easy and cheap to condense - even cooling water at 45°C can do it.
>
>Water would be ideal because of its high enthalpy of vaporization
>and because you can realize the highest heat fluxes with it.
>It is also non-toxic.
>
>However, it has some unpleasant properties for electronics, such
>as being rather conductive with only trace amount of ions needed,
>so that is probably out. You would also have to run it in a slight
>vacuum to get below 100°C, which could be problematic.

All of that is not a problem with heat pipes (or more generally, vapor
chambers): The water is nicely enclosed in the heat pipe, lower
pressure is not a problem, and AFAIK they contain solid stuff that
helps avoid the gas bubble insulation effect. That's why we see heat
pipes used in practice, but not direct-contact systems.

One other interesting aspect is that one might expect heat sinks with
direct-touch heat pipes (direct contact between the heat pipe and the
heat spreader of the CPU) to work better than heat sinks with a base
plate with soldered-in heat pipes, but the better (and more expensive)
heat sinks use a base plate.

One might also expect that it's better if the heat sink touches the
die directly, but that's only done for (low-power) mobile CPUs and
(less power-dense) GPUs; desktop and server CPUs put a heat spreader
and solder (or some liquid interface material) between the die and the
heat sink.

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

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Quadibloc <jsavard@ecn.ab.ca> schrieb:
>>> On Thursday, July 15, 2021 at 9:28:30 AM UTC-6, Thomas Koenig wrote:
>>>
>>>> So, you could in principle use a boiling liquid for cooling
>>>> compouter chips if you can solve the mechanical and other assorted
>>>> problems,
>>>
>>> Isn't that what heat pipes use *already*?
>>
>>Yep, but I was thinking of direct contact of the chips with the
>>boiling liquid (with a thin insulating laryer, presumably).
>>
>>_Much_ more efficient.
>
> If you can avoid the Leidenfrost effect (where the gaseous phase
> insulates the heat source from the cooling liquid (well known from
> experiments with liquid nitrogen).

That's the critical heat flux I was writing about - you go above
that, you get the Leidenfrost effect (and usually a burnout of your
heating surface, which is one reason why it is called "critical"
heat flux).

>
> There are systems that use this idea (e.g.,
><https://www.computerbase.de/2017-08/der8auer-aqua-exhalare-zwei-phasen-kuehlung/>),
> but for now it does not seem to offer enough advantages to justify the
> effort.

Interesting, thanks!

This seems to be more of a traditional system with extra cooling.

I was thinking of a CPU wall, so to speak - think big :-)

George Neuner <gneuner2@comcast.net> writes:
>On Tue, 13 Jul 2021 14:58:48 -0700 (PDT), Quadibloc
><jsavard@ecn.ab.ca> wrote:
>
>>On Tuesday, July 13, 2021 at 6:13:13 AM UTC-6, David Brown wrote:
>>
>>> What seems to be missing here (at least, /I/ have missed it) is a
>>> discusion about what people actually want to do with computing power.
>>> Is it fair to suggest that most tasks that people currently want to run
>>> faster, are actually reasonably parallel? And that most tasks that
>>> people want to run a /lot/ faster are /very/ parallel?
>>
>>Unfortunately, no, it isn't.
>>
>>Many of the tasks that people want to run faster are parallel, but some of
>>them are not.
>>
>>Also, it's at least possible that *some* of the tasks people want to run
>>faster... are perhaps more parallel than people realize, and some new
>>programming paradigm might enable this parallelism to be brought to
>>light. At least that's the hope that fuels attempts to design compilers
>>that will bring out extra parallelism that's not obvious to human programmers.
>>
>>John Savard
>
>The problem - at least with current hardware - is that programmers are
>much better at identifying what CAN be done in parallel than what
>SHOULD be done in parallel.

You make it sound as if that's a problem with the programmers, not
with the hardware. But it's fundamental to programming (at least in
areas affected by the software crisis, i.e., not supercomputers), so
it has to be solved at the system level (i.e., hardware, compiler,
etc.).

Why is it fundamental? Because we build maintainable software by
splitting it into mostly-independent parts. Deciding how much to
parallelize on current hardware needs a global view of the program,
which programmers usually do not have; and even when they have it,
their decisions will probably be outdated after a while of maintaining
the program.

We have similar problems with explicitly managed fast memory, which is
why we don't see that in general-purpose computers; instead, we see
caches (a software-crisis-compatible variant of fast memory).

Yet another problem of this kind is fixed-point scaling. That's why
we have floating-point.

So what do we need of the system? Ideally having more parallel parts
than needed should not cause a slowdown. This has two aspects:

1) Thread creation and destruction should be cheap.

2) The harder part is memory locality: Sequential code often works
very well on caches because it has a lot of temporal and spatial
locality. If the code is split into more tasks than necessary, how do
we avoid losing locality and thus losing some of the benefits of
caching?

>I really like Mitch's VVM. I'm primarily a software guy, but from what
>I've understood of it, VVM seems to address a number of the problems
>that plague auto-vectorization. Waiting for actual hardware. 8-)

It certainly is better than compiler auto-vectorization (at least it
will be when we see it in hardware). But it also follows the (IMO
wrong-headed) auto-vectorization approach of trying to derive
vectorized code/execution from sequential code. When writing
sequential code, programmers tend to inadvertantly put in stuff that
prevents auto-vectorization; VVM may be able to vectorize parts of the
execution, but still: It does not make good use of the ability of
programmers to (as you wrote) identify what can be done in parallel.

Programmers can vectorize manually (just take a look at an APL
program), and reorganize programs into vectorized form that is far out
of reach of auto-vectorizing compilers, and, I think, also
out-of-reach for VVM. As an example, Bernd Paysan once claimed that
TeX's paragraph-formatting can be vectorized (but he did not do it).
And then you can think of what the compiler and hardware have to do to
make it run fast.

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

On Sunday, July 18, 2021 at 11:47:49 AM UTC-5, Anton Ertl wrote:
> George Neuner <gneu...@comcast.net> writes:
> >On Tue, 13 Jul 2021 14:58:48 -0700 (PDT), Quadibloc
> ><jsa...@ecn.ab.ca> wrote:
> >
> >>On Tuesday, July 13, 2021 at 6:13:13 AM UTC-6, David Brown wrote:
> >>
> >>> What seems to be missing here (at least, /I/ have missed it) is a
> >>> discusion about what people actually want to do with computing power.
> >>> Is it fair to suggest that most tasks that people currently want to run
> >>> faster, are actually reasonably parallel? And that most tasks that
> >>> people want to run a /lot/ faster are /very/ parallel?
> >>
> >>Unfortunately, no, it isn't.
> >>
> >>Many of the tasks that people want to run faster are parallel, but some of
> >>them are not.
> >>
> >>Also, it's at least possible that *some* of the tasks people want to run
> >>faster... are perhaps more parallel than people realize, and some new
> >>programming paradigm might enable this parallelism to be brought to
> >>light. At least that's the hope that fuels attempts to design compilers
> >>that will bring out extra parallelism that's not obvious to human programmers.
> >>
> >>John Savard
> >
> >The problem - at least with current hardware - is that programmers are
> >much better at identifying what CAN be done in parallel than what
> >SHOULD be done in parallel.
<
> You make it sound as if that's a problem with the programmers, not
> with the hardware. But it's fundamental to programming (at least in
> areas affected by the software crisis, i.e., not supercomputers), so
> it has to be solved at the system level (i.e., hardware, compiler,
> etc.).
>
> Why is it fundamental? Because we build maintainable software by
<
Where "we" is the 1% who are both good programmers and look at the
long term rather than the deadline of the day/week.
<
> splitting it into mostly-independent parts.
<
Which inlining compilers whack back into the calling function.
<
> Deciding how much to
> parallelize on current hardware needs a global view of the program,
> which programmers usually do not have; and even when they have it,
> their decisions will probably be outdated after a while of maintaining
> the program.
<
That global view changes over time, so any one programmer is not in a
position to make assumptions that will survive over time.
>
> We have similar problems with explicitly managed fast memory, which is
> why we don't see that in general-purpose computers; instead, we see
> caches (a software-crisis-compatible variant of fast memory).
>
> Yet another problem of this kind is fixed-point scaling. That's why
> we have floating-point.
>
> So what do we need of the system? Ideally having more parallel parts
> than needed should not cause a slowdown. This has two aspects:
>
> 1) Thread creation and destruction should be cheap.
<
Depends on what you mean by cheap:: 1-cycle cheap is vastly
different than 1,000 cycle cheap.
>
> 2) The harder part is memory locality: Sequential code often works
> very well on caches because it has a lot of temporal and spatial
> locality. If the code is split into more tasks than necessary, how do
> we avoid losing locality and thus losing some of the benefits of
> caching?
<
It is a delicate tradeoff that changes every generation. It would be
better if HW could make these decisions. But HW is currently lacking
a model under which it could rest control from the humans in the loop.
<
> >I really like Mitch's VVM. I'm primarily a software guy, but from what
> >I've understood of it, VVM seems to address a number of the problems
> >that plague auto-vectorization. Waiting for actual hardware. 8-)
<
> It certainly is better than compiler auto-vectorization (at least it
> will be when we see it in hardware). But it also follows the (IMO
> wrong-headed) auto-vectorization approach of trying to derive
> vectorized code/execution from sequential code.
<
At least the compiler makes the choice on vectorizing the loop (or not).
But unlike instructions vectorization, the compiler can make its choice
based on simple rules without exotic analysis. And the vectorized code
achieves the same results on non-vector capable HW as on GBOoO
multi-lane vector HW.
<
> When writing
> sequential code, programmers tend to inadvertantly put in stuff that
> prevents auto-vectorization; VVM may be able to vectorize parts of the
> execution, but still: It does not make good use of the ability of
> programmers to (as you wrote) identify what can be done in parallel.
<
The biggest VVM issue is that one cannot put calls inside a vectorized
loop. But to a large extent the calls to functions like SIN,COS,EXP,Ln are
all instructions in My 66000, so a large part of this is ameliorated.
>
> Programmers can vectorize manually (just take a look at an APL
> program), and reorganize programs into vectorized form that is far out
> of reach of auto-vectorizing compilers, and, I think, also
> out-of-reach for VVM.
<
By design VVM vectorizes inner loops--this is where the biggest bang for
the buck is found, and punts entirely on outer loops and whole programs.
<
> As an example, Bernd Paysan once claimed that
> TeX's paragraph-formatting can be vectorized (but he did not do it).
> And then you can think of what the compiler and hardware have to do to
> make it run fast.
<
I once heard that the CRAY 1 ASM symbol table lookup was vectorized.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Sun, 18 Jul 2021 15:55:24 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>George Neuner <gneuner2@comcast.net> writes:
>
>>The problem - at least with current hardware - is that programmers are
>>much better at identifying what CAN be done in parallel than what
>>SHOULD be done in parallel.
>
>You make it sound as if that's a problem with the programmers, not
>with the hardware. But it's fundamental to programming (at least in
>areas affected by the software crisis, i.e., not supercomputers), so
>it has to be solved at the system level (i.e., hardware, compiler,
>etc.).

It /IS/ a problem with the programmers. The average "developer" now
has no CS, engineering, or (advanced) mathematics education, and their
programming skills are pitiful - only slightly above "script kiddie".
This is an unfortunate fact of life that I think too often is lost on
some denizens of this group.

Given the ability to create "parallel" tasks, an /average/ programmer
is very likely to naively create large numbers of new tasks regardless
of resources being available to actually execute them.

Which maybe is fine if the number of tasks (relatively) is small, or
if many of them are I/O bound and the use is for /concurrency/. But
most programmers do not understand the difference between "parallel"
and "concurrent", and too many don't understand why spawning large
numbers of tasks can slow down the program.

Outside of DBMS and web servers most threads in most programs are
either compute or memory bound. So if a lot of threads get started, a
handful of them run, but most will sit idle for long periods waiting
for the CPU.

Go lurk in some of the language forums for a while. Far too often
there will be some question posed for which the ensuing discussion
reveals that the programmer is attempting to do something that is
(sometimes far) beyond their ability.

Even discounting newbie questions - which can be forgiven - the
numbers of "experienced" programmers who are ignorant about languages
or tools they are trying to use, or are lacking domain knowledge about
the problem they are expected/expecting to solve, is staggering.

To me anyway. YMMV.

>Why is it fundamental? Because we build maintainable software by
>splitting it into mostly-independent parts. Deciding how much to
>parallelize on current hardware needs a global view of the program,
>which programmers usually do not have; and even when they have it,
>their decisions will probably be outdated after a while of maintaining
>the program.
>
>We have similar problems with explicitly managed fast memory, which is
>why we don't see that in general-purpose computers; instead, we see
>caches (a software-crisis-compatible variant of fast memory).

We have similar problems with programmer managed dynamic allocation.
All the modern languages use GC /because/ repeated studies have shown
that average programmers largely are incapable of writing leak-proof
code without it.
[And they /still/ have problems with other unmanaged resources.]

>Yet another problem of this kind is fixed-point scaling. That's why
>we have floating-point.

And the same people who, in the past, would not have understood the
issues of using fixed-point now don't understand the issues of using
floating point.

Unless it is "software arbitrary precision decimal" floating point -
i.e. "Big Decimal" - then odds are good it is being used incorrectly
and the answers it yields probably should be suspect.

>So what do we need of the system? Ideally having more parallel parts
>than needed should not cause a slowdown. This has two aspects:
>
>1) Thread creation and destruction should be cheap.
>
>2) The harder part is memory locality: Sequential code often works
>very well on caches because it has a lot of temporal and spatial
>locality. If the code is split into more tasks than necessary, how do
>we avoid losing locality and thus losing some of the benefits of
>caching?

Agreed! But this has little to do with any of my points.

>- anton
George

On Sunday, July 18, 2021 at 2:09:47 PM UTC-5, George Neuner wrote:
> On Sun, 18 Jul 2021 15:55:24 GMT, an...@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
> >George Neuner <gneu...@comcast.net> writes:
>snip>
> >Why is it fundamental? Because we build maintainable software by
> >splitting it into mostly-independent parts. Deciding how much to
> >parallelize on current hardware needs a global view of the program,
> >which programmers usually do not have; and even when they have it,
> >their decisions will probably be outdated after a while of maintaining
> >the program.
> >
> >We have similar problems with explicitly managed fast memory, which is
> >why we don't see that in general-purpose computers; instead, we see
> >caches (a software-crisis-compatible variant of fast memory).
<
> We have similar problems with programmer managed dynamic allocation.
> All the modern languages use GC /because/ repeated studies have shown
> that average programmers largely are incapable of writing leak-proof
> code without it.
<
And this is AFTER programming languages created constructors and
destructors which the programmer is allowed to basically "forget" about
their workings and manage memory for them..........
<
> [And they /still/ have problems with other unmanaged resources.]
> >Yet another problem of this kind is fixed-point scaling. That's why
> >we have floating-point.
> And the same people who, in the past, would not have understood the
> issues of using fixed-point now don't understand the issues of using
> floating point.
>
> Unless it is "software arbitrary precision decimal" floating point -
> i.e. "Big Decimal" - then odds are good it is being used incorrectly
> and the answers it yields probably should be suspect.
<
> >So what do we need of the system? Ideally having more parallel parts
> >than needed should not cause a slowdown. This has two aspects:
> >
> >1) Thread creation and destruction should be cheap.
> >
> >2) The harder part is memory locality: Sequential code often works
> >very well on caches because it has a lot of temporal and spatial
> >locality. If the code is split into more tasks than necessary, how do
> >we avoid losing locality and thus losing some of the benefits of
> >caching?
> Agreed! But this has little to do with any of my points.
>
>
> >- anton
> George
<
I should relate a problem I advised a mid-level programmer about a
few years ago when debugging a memory leak problem. He had spent
a large amount of effort tracking down memory leaks in a data base.
After listening to the problem space, I advised him to fork off a (unix)
task, sharing memory, perform the work, and let the OS clean up the
memory leaks (terminate cleanup). Not only did this eliminate* the
memory leak, it ran 3× faster !! even with the task creation and tear
down overheads.
<
(*) It did not get rid of the memory leak, it isolated the memory leak
into a section of memory that was cleanup up in its entirety rather
than in piecemeal.
<
But I wholly agree with George--the problem is the programmers.

On Sunday, July 18, 2021 at 11:03:58 AM UTC-6, MitchAlsup wrote:
> On Sunday, July 18, 2021 at 11:47:49 AM UTC-5, Anton Ertl wrote:

> > 1) Thread creation and destruction should be cheap.

> Depends on what you mean by cheap:: 1-cycle cheap is vastly
> different than 1,000 cycle cheap.

Now that is just a totally unfair criticism. Why couldn't he have
meant by "cheap" the following: sufficiently cheap to actually be
usefully cheap in the context of the issue in question?

Leaving the detail of how many cycles that might be for later.

John Savard

On Sunday, July 18, 2021 at 4:10:03 PM UTC-5, Quadibloc wrote:
> On Sunday, July 18, 2021 at 11:03:58 AM UTC-6, MitchAlsup wrote:
> > On Sunday, July 18, 2021 at 11:47:49 AM UTC-5, Anton Ertl wrote:
>
> > > 1) Thread creation and destruction should be cheap.
>
> > Depends on what you mean by cheap:: 1-cycle cheap is vastly
> > different than 1,000 cycle cheap.
<
> Now that is just a totally unfair criticism. Why couldn't he have
> meant by "cheap" the following: sufficiently cheap to actually be
> usefully cheap in the context of the issue in question?
<
I did the HEP thread creation and deletion software.
<
I had a task sitting by collecting threads which died, and a thread
arranging a thread from a pool and getting it ready should anyone
need a new thread created. I could create a new thread for a given
task in 12 instructions. I considered this fast.
<
GPUs have a block of logic that allocate up to 32 threads to a WARP
and can perform this bundling operation every 4 cycles. I consider this
fast.
<
Your typical CPU performs excel() in a handful of thousands of cycles
(after you consider all of the copy on write semantics it may be even
worse.) I do not consider this fast. I have no idea as to how many cycles
are consumed tearing apart such a task.
<
Your typical CPU performs thread creations in on the order of 1,000
instructions. I do not consider these fast, either. I have no idea whether
this includes (or excludes) thread tear-down, either.
>
> Leaving the detail of how many cycles that might be for later.
>
> John Savard

MitchAlsup <MitchAlsup@aol.com> schrieb:

> By design VVM vectorizes inner loops--this is where the biggest bang for
> the buck is found, and punts entirely on outer loops and whole programs.

I know exactly one example of time-critical real-time code where
the inner loop is quite cold (well, it's quite a few examples,
but the pattern is always the same).

This occurs in array processing if the code in question has to
know a number of dimensions that is unknown at compile-time.
The library function is then given a list of exents along each
dimension.

The algorithm works like an old-style mechanical odometer, or a
ripple-carry incrementer (with a different base for each digit).
In C, it is (slighly shortened from gfortran's library). base is
the pointer for the next iteration of something to do, count the
array which shows how far progress has been made along one dimension,
and extent gives the number of elements along each dimension.

n = 0;
do
{
/* When we get to the end of a dimension, reset it and increment
the next dimension. */
count[n] = 0;
base -= sstride[n] * extent[n];
n++;
if (n >= rank)
return;
else
{
count[n]++;
base += sstride[n];
}
} while (count[n] == extent[n]);
}

This do while loop is executed only once for most cases, but once
it has reached the end of one dimension, it will be executed more
than once, leading to (probable) branch mispredicts.

It's time-critical because... well, almost all Fortran array
intrinsics run through this kind of code (matmul doesn't :-)

On 2021-07-18, MitchAlsup wrote:
> On Sunday, July 18, 2021 at 4:10:03 PM UTC-5, Quadibloc wrote:
>> On Sunday, July 18, 2021 at 11:03:58 AM UTC-6, MitchAlsup wrote:
>>> On Sunday, July 18, 2021 at 11:47:49 AM UTC-5, Anton Ertl wrote:
>>
>>>> 1) Thread creation and destruction should be cheap.
>>
>>> Depends on what you mean by cheap:: 1-cycle cheap is vastly
>>> different than 1,000 cycle cheap.
> <
>> Now that is just a totally unfair criticism. Why couldn't he have
>> meant by "cheap" the following: sufficiently cheap to actually be
>> usefully cheap in the context of the issue in question?
> <
> I did the HEP thread creation and deletion software.
> <
> I had a task sitting by collecting threads which died, and a thread
> arranging a thread from a pool and getting it ready should anyone
> need a new thread created. I could create a new thread for a given
> task in 12 instructions. I considered this fast.
> <
> GPUs have a block of logic that allocate up to 32 threads to a WARP
> and can perform this bundling operation every 4 cycles. I consider this
> fast.
> <
> Your typical CPU performs excel() in a handful of thousands of cycles
> (after you consider all of the copy on write semantics it may be even
> worse.) I do not consider this fast. I have no idea as to how many cycles
> are consumed tearing apart such a task.
> <
> Your typical CPU performs thread creations in on the order of 1,000
> instructions. I do not consider these fast, either. I have no idea whether
> this includes (or excludes) thread tear-down, either.

Some hard numbers on thread and process creation + tear-down on
different machines and OS:es:

https://www.bitsnbites.eu/benchmarking-os-primitives/

The fastest machines (Linux) do create + tear-down in just less than
10 us. On a 3 GHz CPU that corresponds to about 20,000 - 30,000
clock cycles. Please note that it includes all the layers of pthread and
OS thread initialization.

On Windows (same machine), the figure is 3-4 times worse.

This is the reason that when you need instant threads, you set up a
thread pool of dormant threads instead of spawning a new OS thread
every time you need one. I personally consider that an ugly work-around
for inefficient thread creation.

/Marcus

On 2021-07-18, George Neuner wrote:
> On Sun, 18 Jul 2021 15:55:24 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>> George Neuner <gneuner2@comcast.net> writes:
>>
>>> The problem - at least with current hardware - is that programmers are
>>> much better at identifying what CAN be done in parallel than what
>>> SHOULD be done in parallel.
>>
>> You make it sound as if that's a problem with the programmers, not
>> with the hardware. But it's fundamental to programming (at least in
>> areas affected by the software crisis, i.e., not supercomputers), so
>> it has to be solved at the system level (i.e., hardware, compiler,
>> etc.).
>
> It /IS/ a problem with the programmers. The average "developer" now
> has no CS, engineering, or (advanced) mathematics education, and their
> programming skills are pitiful - only slightly above "script kiddie".
> This is an unfortunate fact of life that I think too often is lost on
> some denizens of this group.
>

I would guess that the majority of programmers today do not even reflect
over the difference in computational effort (as in number of CPU cycles
required) for the following lines of code (Python):

1) foo = 39+3

2) foo = f'The answer is {39+3}'

3) foo = requests.get('https://en.wikipedia.org/wiki/42')

After all, it's just a single line of code...

I remember the first time I wrote a 6502 assembler language loop on my
C=64: The program changed the character value of the upper left
character of the screen a few hundred times (probably 255), and at first
I thought I had made an error because I only saw the final character,
not the other hundreds of characters, until it dawned on me:

"It's THAT fast!"

I doubt that many programmers these days have these moments when they
actually understand how fast a computer really is.

/Marcus

Marcus <m.delete@this.bitsnbites.eu> schrieb:

> I remember the first time I wrote a 6502 assembler language loop on my
> C=64: The program changed the character value of the upper left
> character of the screen a few hundred times (probably 255), and at first
> I thought I had made an error because I only saw the final character,
> not the other hundreds of characters, until it dawned on me:
>
> "It's THAT fast!"
>
> I doubt that many programmers these days have these moments when they
> actually understand how fast a computer really is.

I certainly had a moment when I understood how much faster computers
had become.

It was a little problem to find four prices (i.e. decimal numbers
with a maximum of two digits after the decimal separator) a,b,c,d
so that a*b*c*d = a+b+c+d = 7.47 .

On a C 64 using Basic, months to hours depending on the cleverness
of the algorithm.

On a modern computer using a compiled language, too fast to notice
even when choosing a rather stupid algorithm.

On Monday, July 19, 2021 at 12:39:46 AM UTC-6, Thomas Koenig wrote:

> It was a little problem to find four prices (i.e. decimal numbers
> with a maximum of two digits after the decimal separator) a,b,c,d
> so that a*b*c*d = a+b+c+d = 7.47 .

I see that seven hundred and forty-seven is divisible by nine.

Perhaps that leaves open the possibility of a solution.

I suppose the problem was phrased something like this:

A clerk at a grocery store, when adding up the prices of
four items, accidentally pressed the multiplication key
by mistake. But when he repeated the calculation correctly,
he got exactly the same answer. What were the prices of
the four items, which totalled to $7.47?

7.47 is 2.49 times 3, or 0.83 times 9.

2.49 * 1.50 * 2.00 * 1.00 doesn't add up to anything
with a 7 on the end.

0.83 * 2.25 * 4.00 * 1.00 when added up ends in an 8,
not in a 7.

Hmm. 7.47 minus 2.49 is 4.98. What could add to 4.98
and yet multiply to 3?

Or, 7.47 minus 0.83 is 6.64. What could add to 6.64, and
multiply to 9?

9 is 3 * 3, or 4.5 * 2, or 2.25 * 4. Or it is 1.8 * 5. Or 3.6 * 2.5.
Or 7.2 times 1.25. Or 1.44 times 6.25.

1.25 is 0.25 times 5. 6.25 is 1.25 times 5.

0.05 + 1.25 + 1.44 + 0.83 would end in a 7.

But it would add up to 3.57 and multiply to .0747, so
that's clearly not the answer.

Quite a puzzling problem.

John Savard

On Monday, July 19, 2021 at 2:08:03 AM UTC-6, Quadibloc wrote:
> On Monday, July 19, 2021 at 12:39:46 AM UTC-6, Thomas Koenig wrote:
>
> > It was a little problem to find four prices (i.e. decimal numbers
> > with a maximum of two digits after the decimal separator) a,b,c,d
> > so that a*b*c*d = a+b+c+d = 7.47 .
> I see that seven hundred and forty-seven is divisible by nine.
>
> Perhaps that leaves open the possibility of a solution.
>
> I suppose the problem was phrased something like this:
>
> A clerk at a grocery store, when adding up the prices of
> four items, accidentally pressed the multiplication key
> by mistake. But when he repeated the calculation correctly,
> he got exactly the same answer. What were the prices of
> the four items, which totalled to $7.47?
>
> 7.47 is 2.49 times 3, or 0.83 times 9.
>
> 2.49 * 1.50 * 2.00 * 1.00 doesn't add up to anything
> with a 7 on the end.
>
> 0.83 * 2.25 * 4.00 * 1.00 when added up ends in an 8,
> not in a 7.
>
> Hmm. 7.47 minus 2.49 is 4.98. What could add to 4.98
> and yet multiply to 3?
>
> Or, 7.47 minus 0.83 is 6.64. What could add to 6.64, and
> multiply to 9?
>
> 9 is 3 * 3, or 4.5 * 2, or 2.25 * 4. Or it is 1.8 * 5. Or 3.6 * 2.5.
> Or 7.2 times 1.25. Or 1.44 times 6.25.
>
> 1.25 is 0.25 times 5. 6.25 is 1.25 times 5.
>
> 0.05 + 1.25 + 1.44 + 0.83 would end in a 7.
>
> But it would add up to 3.57 and multiply to .0747, so
> that's clearly not the answer.
>
> Quite a puzzling problem.

Attempting to Google the problem and presumably its
solution, I found this:

https://math.stackexchange.com/questions/66302/4-items-add-up-to-and-multiply-to-7-11-what-are-the-value-of-the-items

Apparently the actual total was $7.11 rather than $7.47, which, of course,
fits with the name of a popular convenience store.

John Savard

Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>
>> I remember the first time I wrote a 6502 assembler language loop on my
>> C=64: The program changed the character value of the upper left
>> character of the screen a few hundred times (probably 255), and at first
>> I thought I had made an error because I only saw the final character,
>> not the other hundreds of characters, until it dawned on me:
>>
>> "It's THAT fast!"
>>
>> I doubt that many programmers these days have these moments when they
>> actually understand how fast a computer really is.
>
> I certainly had a moment when I understood how much faster computers
> had become.
>
> It was a little problem to find four prices (i.e. decimal numbers
> with a maximum of two digits after the decimal separator) a,b,c,d
> so that a*b*c*d = a+b+c+d = 7.47 .
>
> On a C 64 using Basic, months to hours depending on the cleverness
> of the algorithm.
>
> On a modern computer using a compiled language, too fast to notice
> even when choosing a rather stupid algorithm.
>
Hmmm.

None of them can be zero or negative, so by specifying that a,b,c,d is
in increasing order, a can be in the range 0.01 to 7.47/4=1.86.
b has a slightly larger possible range (0.01 to (7.47-a)/3), the same
for c (0.01 to (7.47-a-b)/2), while d is always (7.47-a-b-c).

(I would do this all in cents of course!)

This should be ~200^3 so 8M iterations, doable in a small fraction of a
second.

Next insight is the fact that the cents values must be such that 6 of
the 8 multiplication decimals end up as zero, i.e. the last digits of
each price must have a lot of '0', '2' or '5', I suspect this reduces
the search space by at least an order of magnitude?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 7/13/2021 6:31 AM, George Neuner wrote:
> On Mon, 12 Jul 2021 15:28:23 -0700 (PDT), "luke.l...@gmail.com"
> <luke.leighton@gmail.com> wrote:
>
>> On Monday, July 12, 2021 at 10:17:29 PM UTC+1, Quadibloc wrote:
>>
>>> about an attempt to design a processor that does away with instruction
>>> sets and all those instructions that just move data around.
>>
>> reminds me of Elixent's stuff. they did NSEW neighbour processing.
>> fascinating design: 4-bit ALUs. tens of thousands of them. programming
>> this style of processor is an absolute pig.
>>
>> l.
>
> Dunno. I programmed Connection Machines. Admittedly a problem had to
> be embarrassingly parallel to fit with the hardware ... but given
> that, the CM was quite easy to work with.

Has anybody here programmed for a sicortex?

https://en.wikipedia.org/wiki/SiCortex

Quadibloc <jsavard@ecn.ab.ca> schrieb:

> Attempting to Google the problem and presumably its
> solution, I found this:
>
> https://math.stackexchange.com/questions/66302/4-items-add-up-to-and-multiply-to-7-11-what-are-the-value-of-the-items
>
> Apparently the actual total was $7.11 rather than $7.47,

In the computer magazine I read this puzzle ("Chip"), it was
actually 7,47 DM. And the issue must have been around October or
November of that year.

7-11 was not a common number combination in Germany in 1986,
but the same puzzle can be set up with many different results.

> which, of course,
> fits with the name of a popular convenience store.

I suspect they chose it for recognition value of the airplane type
(and, of course, the uniqueness of the solution). I would post
it, but rot13 does not work for numbers :-)

Maybe the original was with 7-11. Source prior to 1986, anybody?

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:

>> It was a little problem to find four prices (i.e. decimal numbers
>> with a maximum of two digits after the decimal separator) a,b,c,d
>> so that a*b*c*d = a+b+c+d = 7.47 .
>>
>> On a C 64 using Basic, months to hours depending on the cleverness
>> of the algorithm.
>>
>> On a modern computer using a compiled language, too fast to notice
>> even when choosing a rather stupid algorithm.
>>
> Hmmm.
>
> None of them can be zero or negative, so by specifying that a,b,c,d is
> in increasing order, a can be in the range 0.01 to 7.47/4=1.86.
> b has a slightly larger possible range (0.01 to (7.47-a)/3), the same
> for c (0.01 to (7.47-a-b)/2), while d is always (7.47-a-b-c).
>
> (I would do this all in cents of course!)
>
> This should be ~200^3 so 8M iterations, doable in a small fraction of a
> second.

That's a pretty good guess, going through three variables i <=
j <= k and setting m = 7-i-j-k, while removing duplicates setting
the bounds so that k <= m, gives around 2.9e6 iterations.

> Next insight is the fact that the cents values must be such that 6 of
> the 8 multiplication decimals end up as zero, i.e. the last digits of
> each price must have a lot of '0', '2' or '5', I suspect this reduces
> the search space by at least an order of magnitude?

In the evening that we (myself, plus some people in the same
flat) solved this on a C-64, we spent a few hours making these
simplifications. Tt more tricky because, as soon as you start
making assumptions about the divisibility, you have to make sure
not to lose cases with one variable being smaller than another.

> This is the reason that when you need instant threads, you set up a
> thread pool of dormant threads instead of spawning a new OS thread
> every time you need one. I personally consider that an ugly work-around
> for inefficient thread creation.

Part of the problem is linked to the precise meaning of "thread" (as in
whether or not you care about all the different features offered for
threads by the OS) and the devil in the details.

Also "instant threads" is still a lie for thread created from a thread
pool of dormant threads, so it would be valuable to have benchmark
numbers to see whether those are closer to "0 cycles" or to "1000
cycle".

Stefan