EricP wrote:
> Michael S wrote:
>> On Thursday, October 28, 2021 at 7:19:19 PM UTC+3, EricP wrote:
>>> There are two other ways to do this kind of stuff which I quite like
>>> so I'll mention them (but I don't know if or how this could fit with
>>> your approaches).
>>> (1) First method is for threads to support what I call Thread
>>> Interrupt Procedures (TIP's), VMS calls them Asynchronous System
>>> Traps (AST's) and WinNT calls them Asynchronous Procedure Calls
>>> (APC's). It is all the same basic concept - a software interrupt to a
>>> thread.
>>> A TIP is a kernel packet that contains a pointer to a routine to call
>>> and 3 or 4 arguments to pass to that routine, and links for a list.
>>> Each thread has a list of pending TIPs. When a TIP is posted to a
>>> thread, if that thread is in a Wait state it wakes up to a Ready
>>> state. When the thread next runs, the first pending TIP is delivered
>>> in kernel mode and its routine is called passing the args,
>>> interrupting whatever the thread was doing, and blocking TIP delivery
>>> until it returns.
>>
>> I heard that AST on VMS works as you described. But APC on WNT does not.
>> Despite the name, WNT ASP is asynchronous only in a sense that
>> QueueUserAPC() call is non-blocking. But execution at destination
>> tread is synchronous and happens only after the target thread entered
>> an alertable state by SleepEx(), WaitForSingleObjectEx(),
>> WaitForMultipleObjectsEx() and couple of other similar syscalls.
>
> WinNT kernel mode APCs do work that way, as thread interrupts.
> Yes, the the _documented_ user mode "APCs" are actually synchronous,
> delivered only at certain points and only on request.
>
> There are undocumented user mode APCs that are asynchronous and delivered
> at the next user-kernel transition (which you can force so they behave
> like interrupts) but these are only available from within kernel mode
> and have been intentionally lobotomized so they can only deliver
> a program counter on MS approved list.

On a related note, I just noticed that Intel has added new instructions
for Adler Lake, a big-little architecture, some of which support
_user mode interrupts_.

Intel Architecture Instruction Set Extensions and Future Features May 2021
https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf

They also add Advanced Matrix Extensions (AMX) that can do 2048 8-bit
multiply-adds per clock per core.

There is a video about Adler Lake microArch, first for Gracemont,
the little efficient one, and then for Golden Cove, the big
performance one. 2 hours 16 min
https://www.youtube.com/watch?v=3jU_YhZ1NQA&t=422s

On 10/28/21 6:33 PM, Bill Findlay wrote:
> On 28 Oct 2021, George Neuner wrote
> (in article<tanknght82p32476bocsneeaa985mgersh@4ax.com>):
>
>> On Mon, 25 Oct 2021 08:53:31 +0200, Bernd Linsel
>> <bl1-removethis@gmx.com> wrote:
>>
>>> On 24.10.2021 19:38, MitchAlsup wrote:
>>>> On Sunday, October 24, 2021 at 11:31:59 AM UTC-5, Stefan Monnier wrote:
>>>> <
>>>> PL/1 had areas. If you deallocated an area, everything you allocated in
>>>> the area
>>>> "went away".
>>>
>>> Original Pascal: Mark(b); ... New(p); ... Dispose(b);
>>
>> Umm. My (perhaps faulty) recollection was that it was mark/release,
>> and that it was not in Wirth's Pascal originally, but rather was an
>> extension introduced by UCSD and then copied by others ... notably
>> Turbo.
>
> Correct.
>
> But truly original Pascal had "class" types, which were locally
> declarable areas within which new allocated storage on demand.
> Pointers were bound to classes, not to the types pointed-to.
> A class was completely deallocated on exit from its scope.

FYI: This was removed in about two years. According to Wirth's
recollections[1]:
Thereafter, the bootstrapping process could begin [Wirth, 1971b].
This compiler was completed by mid 1970, and at this time the
language definition was published. With the exception of some
slight revisions in 1972, it remained stable thereafter.

The revised report[2] came out in 1972 and mentions this:
The class structure is eliminated: pointer variables are bound
to a data type instead of a class variable.

I don't have a copy of Wirth's 1970 paper on Pascal so I don't quite
understand their semantics. I have a scanned listing of the original
CDC6000 pascal compiler but don't feel like wading through it to
figure out how class structures were implemented!

[1]
http://pascal.hansotten.com/niklaus-wirth/recollections-about-the-development-of-pascal/
[2] http://bernd-oppolzer.de/PascalReport.pdf

On Saturday, October 30, 2021 at 11:52:47 AM UTC-6, EricP wrote:

> They also add Advanced Matrix Extensions (AMX) that can do 2048 8-bit
> multiply-adds per clock per core.

This sounds exciting.

John Savard

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Intel Architecture Instruction Set Extensions and Future Features May 2021
>https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf

A 214-page document describing various architectural features
(although lot all relevant for user-level code), some of them
additions that are designed to play with earlier extensions.

One problem is that with a base architecture and optional extensions
using the extensions means that you should write a base version and a
version with the extensions (and given that Intel disables extensions
for market segmentation reasons, yes, you really have to do that).
ARM is somewhat better here by defining architecture levels (ARM v8-A,
8.1 ..., ARM v9-A, ...), although the benefit is somewhat lessened by
having so many levels and so confusingly named (e.g., the headline
feature of ARM v8 seemed to be the Aarch64 or A64 instruction set, but
ARM v8-M does not include this instruction set).

Another problem is getting an overview. So you have these piecewise
documents and you have the big tome that lists the instructions
albhabetically, but no good overview of specific groups of
instructions (at least not for all); in particular, I recently wanted
to learn about AVX-512, because the Tiger Lake in my laptop has that.
I found some application notes from Intel that give an example of the
AVX-512 stuff in the Xeon Phi CPUs, but little else. My guess is that
AVX-512 in mainstream CPUs is mostly AVX2, plus the predicate stuff
(for which I did not find an overview), plus the instructions
discussed in the application note.

>There is a video about Adler Lake microArch, first for Gracemont,
>the little efficient one, and then for Golden Cove, the big
>performance one. 2 hours 16 min
>https://www.youtube.com/watch?v=3jU_YhZ1NQA&t=422s

I wonder if such a video is cheaper to produce than a written
document. I certainly find a written document much preferable, so
much that I will probably not watch this video, while I would read a
paper.

- 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:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>Intel Architecture Instruction Set Extensions and Future Features May 2021
>>https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf
>
> A 214-page document describing various architectural features
> (although lot all relevant for user-level code), some of them
> additions that are designed to play with earlier extensions.
>
> One problem is that with a base architecture and optional extensions
> using the extensions means that you should write a base version and a
> version with the extensions (and given that Intel disables extensions
> for market segmentation reasons, yes, you really have to do that).

Which is a PITA for everybody involved. This sort of thing only
makes some sense for people who compile their own code, which very
few people do.

But even so, compilers then have to offer a host of options,
both for "tune for this architecture, but make sure it runs
everywhere" and for "you can assume you can use any feature of
this architecture". It is not surprising that this is a continuous
source of (performance) bugs.

Finally, for people who distribute binaries - they may decide
to do as you described above, but that they can hardly expect to
have a system with every microarchitecture around, and generating
x binaries from a single source and checking them for performance
is a bit of a nightmare.

I guess Intel is hoping for vendor lock here, but so far it does
not appear to have worked.

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>
>> There is a video about Adler Lake microArch, first for Gracemont,
>> the little efficient one, and then for Golden Cove, the big
>> performance one. 2 hours 16 min
>> https://www.youtube.com/watch?v=3jU_YhZ1NQA&t=422s
>
> I wonder if such a video is cheaper to produce than a written
> document. I certainly find a written document much preferable, so
> much that I will probably not watch this video, while I would read a
> paper.
>
> - anton

I agree, I would prefer a document too but I stumbled on it
so just passing it along.

The above look like a collection of talks they would have given
if we were still having conferences and covered more topics than
just the processor cores.

Web page version:

Intel Architecture Day 2021:
Alder Lake, Golden Cove, and Gracemont Detailed, 19-Aug-2021
https://www.anandtech.com/show/16881/a-deep-dive-into-intels-alder-lake-microarchitectures

On Saturday, October 30, 2021 at 9:39:23 PM UTC-6, Quadibloc wrote:
> On Saturday, October 30, 2021 at 11:52:47 AM UTC-6, EricP wrote:

> > They also add Advanced Matrix Extensions (AMX) that can do 2048 8-bit
> > multiply-adds per clock per core.

> This sounds exciting.

It's not as exciting as I hoped. Apparently, it only supports operations on
either bytes or short floating-point numbers in BF16 format.

Of course, I was hoping for FP64.

John Savard

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Intel Architecture Instruction Set Extensions and Future Features May 2021
>> https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf
>
> A 214-page document describing various architectural features
> (although lot all relevant for user-level code), some of them
> additions that are designed to play with earlier extensions.
>
> One problem is that with a base architecture and optional extensions
> using the extensions means that you should write a base version and a
> version with the extensions (and given that Intel disables extensions
> for market segmentation reasons, yes, you really have to do that).
> ARM is somewhat better here by defining architecture levels (ARM v8-A,
> 8.1 ..., ARM v9-A, ...), although the benefit is somewhat lessened by
> having so many levels and so confusingly named (e.g., the headline
> feature of ARM v8 seemed to be the Aarch64 or A64 instruction set, but
> ARM v8-M does not include this instruction set).
>
> Another problem is getting an overview. So you have these piecewise
> documents and you have the big tome that lists the instructions
> albhabetically, but no good overview of specific groups of
> instructions (at least not for all); in particular, I recently wanted
> to learn about AVX-512, because the Tiger Lake in my laptop has that.
> I found some application notes from Intel that give an example of the
> AVX-512 stuff in the Xeon Phi CPUs, but little else. My guess is that
> AVX-512 in mainstream CPUs is mostly AVX2, plus the predicate stuff
> (for which I did not find an overview), plus the instructions
> discussed in the application note.

Adler Lake apparently disables AVX-512 for both desktop and mobile.
It's not clear why. It remains for "data centers", presumably Xeon.

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

> Adler Lake apparently disables AVX-512 for both desktop and mobile.
> It's not clear why. It remains for "data centers", presumably Xeon.

I assume they disable it because it has rather turned out to be
a fiasco because they had to clock down the whole CPU to use
it or risk overheating.

Maybe they assume better cooling on CPUs for data centers.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Adler Lake apparently disables AVX-512 for both desktop and mobile.
>It's not clear why.

The speculation I have read is that Gracemont (the efficiency core)
does not have AVX-512, so they also disabled it for Golden Cove (the
performance core).

>It remains for "data centers", presumably Xeon.

Either they disable Gracemont there (or, for those CPUs that don't use
the same die, don't have Gracemont), or the idea is that data center
OSs have schedulers that can deal with heterogeneous instruction sets.

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

Thomas Koenig <tkoenig@netcologne.de> writes:
>EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>
>> Adler Lake apparently disables AVX-512 for both desktop and mobile.
>> It's not clear why. It remains for "data centers", presumably Xeon.
>
>I assume they disable it because it has rather turned out to be
>a fiasco because they had to clock down the whole CPU to use
>it or risk overheating.

Looking at the Ice Lake results on
<https://travisdowns.github.io/blog/2020/08/19/icl-avx512-freq.html>,
the downclocking seems to be not very pronounced on Ice Lake even for
low-power CPUs. I have to measure it on my Tiger Lake at some point.

>Maybe they assume better cooling on CPUs for data centers.

Certainly on Skylake things were the other way round: desktop CPUs
that used AVX2 did not downclock while server CPUs did. My guess is
that this is because server customers are more power-conscious than
desktop customers. E.g., you can see how AVX2 affects the Xeon Gold
5120 (a Skylake-server CPU) at
<https://stackoverflow.com/questions/56852812/simd-instructions-lowering-cpu-frequency/56861355#56861355>.
So if you have load on 4 cores, the Core i7-6700K client CPU runs it
at 4200MHz Turbo whether the code uses AVX2 or not, while the Xeon
Gold 5120 server CPU runs it at 3000MHz without AVX2, and at 2900MHz
if the code contains AVX2 instructions (in the last ms or so). The
AVX-512 slowdown is bigger, but the client CPU does not have AVX-512.

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

jgd@cix.co.uk (John Dallman) writes:
>In article <slltnv$ed1$1@newsreader4.netcologne.de>,
>tkoenig@netcologne.de (Thomas Koenig) wrote:
>> I guess Intel is hoping for vendor lock here, but so far it does
>> not appear to have worked.

Of course it does not work, because Intel fails to provide these
extensions on Intel CPUs. Buy a Pentium or Celeron, and AVX is
disabled, even if the die has it.

So I don't think that Intel is hoping for vendor lock-in, they are
trying to do market segmentation. But my impression is that it is not
working. Nobody buys a more expensive Core i3 over a Pentium because
the Core i3 has AVX and the Pentium does not. They buy the Core i3
because

1) Intel was very successful at marketing the names. Even people who
should be in the know act as if a Core i7 was better than a Core i5
even when comparing between generations (where it is definitely not
the case).

2) it offers more cores or a higher clock rate or
hyperthreading (or several of those).

3) they can afford it (this is actually reason 1 in dusguise).

>Intel seems to operate under some hardware-centric assumptions. These
>make good sense for firmware, but much less for application software:

I don't what they are doing makes any sense for PC firmware, either.
The firmware is on the mainboard, and you can put in anything from a
Celeron (without AVX) to a Core i9 (with AVX-512 on Rocket Lake), so
the firmware will not use AVX.

By contrast, AMD has had AVX support in all CPUs since Bulldozer
(2011) and Jaguar (2013) and AVX2 support since Excavator (2015). If
everybody had acted like AMD, AVX and AVX2 could become base features
at some point.

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

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>
>>> There is a video about Adler Lake microArch, first for Gracemont,
>>> the little efficient one, and then for Golden Cove, the big
>>> performance one. 2 hours 16 min
>>> https://www.youtube.com/watch?v=3jU_YhZ1NQA&t=422s
>>
>> I wonder if such a video is cheaper to produce than a written
>> document. I certainly find a written document much preferable, so
>> much that I will probably not watch this video, while I would read a
>> paper.
>>
>> - anton
>
>I agree, I would prefer a document too but I stumbled on it
>so just passing it along.

Thank you.

>Web page version:
>
>Intel Architecture Day 2021:
>Alder Lake, Golden Cove, and Gracemont Detailed, 19-Aug-2021
>https://www.anandtech.com/show/16881/a-deep-dive-into-intels-alder-lake-microarchitectures

And the video-averse people like me have to thank Anandtech for
putting it in writing.

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

On Sunday, October 31, 2021 at 1:44:10 PM UTC-5, Anton Ertl wrote:
> j...@cix.co.uk (John Dallman) writes:
> >In article <slltnv$ed1$1...@newsreader4.netcologne.de>,
> >tko...@netcologne.de (Thomas Koenig) wrote:
> >> I guess Intel is hoping for vendor lock here, but so far it does
> >> not appear to have worked.
> Of course it does not work, because Intel fails to provide these
> extensions on Intel CPUs. Buy a Pentium or Celeron, and AVX is
> disabled, even if the die has it.
>
> So I don't think that Intel is hoping for vendor lock-in, they are
> trying to do market segmentation. But my impression is that it is not
> working. Nobody buys a more expensive Core i3 over a Pentium because
> the Core i3 has AVX and the Pentium does not. They buy the Core i3
> because
>
> 1) Intel was very successful at marketing the names. Even people who
> should be in the know act as if a Core i7 was better than a Core i5
> even when comparing between generations (where it is definitely not
> the case).
>
> 2) it offers more cores or a higher clock rate or
> hyperthreading (or several of those).
>
> 3) they can afford it (this is actually reason 1 in dusguise).
> >Intel seems to operate under some hardware-centric assumptions. These
> >make good sense for firmware, but much less for application software:
<
> I don't what they are doing makes any sense for PC firmware, either.
> The firmware is on the mainboard, and you can put in anything from a
> Celeron (without AVX) to a Core i9 (with AVX-512 on Rocket Lake), so
> the firmware will not use AVX.
<
Firmware would simply::
a) ignore the extra instructions
b) use CPUID to figure out which instructions it can use.
More likely a than b.
>
> By contrast, AMD has had AVX support in all CPUs since Bulldozer
> (2011) and Jaguar (2013) and AVX2 support since Excavator (2015). If
> everybody had acted like AMD, AVX and AVX2 could become base features
> at some point.
<
This is like pointing out that every car-radio has the same electronics inside
(since about 1995) and they "customize" or "downgrade" based on (essentially
fuses inside the radio) what the model number is.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

jgd@cix.co.uk (John Dallman) writes:
>In article <2021Oct31.184628@mips.complang.tuwien.ac.at>,
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> >It remains for "data centers", presumably Xeon.
>>
>> Either they disable Gracemont there (or, for those CPUs that don't
>> use the same die, don't have Gracemont), or the idea is that data
>> center OSs have schedulers that can deal with heterogeneous
>> instruction sets.
>
>The scheduler approach sets a very high bar for the scheduler in never,
>ever, letting a process that uses AVX-512 onto a Gracemont core, because
>SIGIL spoils your whole day.

Does not sound so difficult to me. I can tell Linux with taskset to
never, ever use core 3 or 4 for a certain process.

The more difficult thing in practice is to know whether a program uses
AVX-512. Either these programs are marked as requiring a separate
architecture, or the OS runs it until the CPU traps on an unsupported
instruction; then the OS sets the CPU affinity of the thread to Golden
Cove cores only, migrates the thread to an appropriate core, and lets
it continue.

Another problem is that AVX-512 state has more and longer registers,
so if you want to support Golden Cove -> Gracemont migrations, you
would need to know whether any of the additional state is in use (then
you probably don't want such a migration anyway)

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

On Sunday, October 31, 2021 at 10:18:36 AM UTC-6, EricP wrote:

> Adler Lake apparently disables AVX-512 for both desktop and mobile.
> It's not clear why. It remains for "data centers", presumably Xeon.

The problem with Alder Lake is that only the performance cores, and not
the efficiency cores, support AVX-512.
Thus, it is necessary to either disable the efficiency cores, or disable
AVX-512, for the computer to run properly, until the operating system is
updated to distinguish between programs that use AVX-512 and programs
that don't, restricting the former to the performance cores only.
I'm very disappointed in this, as I consider AVX-512 a very important
feature, as under the right circumstances it can almost double a program's
performance.
Since the Atom-based cores in the Xeon Phi were where AVX-512
originated, it should have been possible to include AVX-512 support
on the E-cores of Aldler Lake to avoid this horrendous compromise.

John Savard

On Sunday, October 31, 2021 at 1:59:06 PM UTC-6, John Dallman wrote:

> The scheduler approach sets a very high bar for the scheduler in never,
> ever, letting a process that uses AVX-512 onto a Gracemont core, because
> SIGIL spoils your whole day.

Calling working properly a "very high bar" may well be borne out
by practical experience with the quality of certain operating
systems and their updates, but, really, it is not. It is a minimum
acceptable standard.

Since the efficiency cores avoid wasted electricity and excess heat,
and AVX-512 can almost double the performance of some programs,
they're both features that are too important to do without. The
scheduler approach is the one that allows one to have both of them,
so it is incumbent on operating system writers to define an alternate
format for executables using AVX-512 to give the scheduler the information
it needs.

John Savard

Anton Ertl wrote:
> jgd@cix.co.uk (John Dallman) writes:
>> In article <2021Oct31.184628@mips.complang.tuwien.ac.at>,
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>
>>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>>> It remains for "data centers", presumably Xeon.
>>> Either they disable Gracemont there (or, for those CPUs that don't
>>> use the same die, don't have Gracemont), or the idea is that data
>>> center OSs have schedulers that can deal with heterogeneous
>>> instruction sets.
>> The scheduler approach sets a very high bar for the scheduler in never,
>> ever, letting a process that uses AVX-512 onto a Gracemont core, because
>> SIGIL spoils your whole day.
>
> Does not sound so difficult to me. I can tell Linux with taskset to
> never, ever use core 3 or 4 for a certain process.
>
> The more difficult thing in practice is to know whether a program uses
> AVX-512. Either these programs are marked as requiring a separate
> architecture, or the OS runs it until the CPU traps on an unsupported
> instruction; then the OS sets the CPU affinity of the thread to Golden
> Cove cores only, migrates the thread to an appropriate core, and lets
> it continue.
>
> Another problem is that AVX-512 state has more and longer registers,
> so if you want to support Golden Cove -> Gracemont migrations, you
> would need to know whether any of the additional state is in use (then
> you probably don't want such a migration anyway)
>
> - anton

An OS exception handler could easily diagnose an AVX-512
instruction and re-route the thread to the big core.
Cpus have been doing this kind of stuff for a very long time.

Also this sounds similar to what the Thread Director technology does.
It dynamically measures performance and instruction set usage,
and works with the OS to move threads to the appropriate cores
for the work load.

See time index 36min 50sec

https://www.youtube.com/watch?v=3jU_YhZ1NQA&t=422s

So they appear to have multiple the tools necessary
to support asymmetric instruction sets.

Quadibloc <jsavard@ecn.ab.ca> writes:
>Since the Atom-based cores in the Xeon Phi were where AVX-512
>originated, it should have been possible to include AVX-512 support
>on the E-cores of Aldler Lake to avoid this horrendous compromise.

The most recent Xeon Phi is Silvermont-based and supports a different
AVX-512 than Golden Cove. Silvermont is several generations behind
Gracemont: Silvermont, Goldmont, Goldmont+, Tremont, Gracemont. It's
probably non-trivial to adapt Xeon Phi AVX-512 to Gracemont and extend
it to the full extent of present-day AVX-512. This was also in a
larger process, and was not designed in a way that makes shrinking
easy. And the main idea of Gracemont is to be small and consume
little power, and Xeon Phi AVX-512 units were probably designed more
for performance.

An alternative would be to implement AVX-512 with narrower units (like
AMD implemented AVX-256 before Zen 2, including on its small and
efficient cores). But for some reason Intel did not go there.

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

EricP <ThatWouldBeTelling@thevillage.com> writes:
>An OS exception handler could easily diagnose an AVX-512
>instruction and re-route the thread to the big core.

Yes. This is an interesting difference between the Intel way of
adding instruction set extensions for the additional width and
capability, and ARM's SVE approach (as far as I understand it). While
SVE allows to run the program on a CPU with arbitrary width (and make
use of the width without recompilation), it does not allow to migrate
a running thread to a core with different width, because the thread
can have the SVE width in many places in its state; foremost the
vector registers. This will be interesting when people want to
migrate virtual machines between ARM CPUs with different SVE widths.

By contrast, you can at least migrate an AVX program from a core that
has AVX to one that has AVX and AVX-512.

So, much as SVE is an advance in width independence, there is still
something missing. Maybe a special-purpose register that indicates
the currently-used width and lets wider cores work as if they were
narrower. This would allow at least migration to wider cores.

Making use of the full width soon after could be facilitated by
letting the software read the real width at points with empty vector
state, and propagating the possibly new width to all the places where
it matters (including the "currently-used width" register). However,
given that migration to wider cores is a rare event, such an approach
might lead to bugs popping up in the field, and I am skeptical that
the additional utilization is worth the risk.

I am sure that Mitch Alsup will point out that his VVM does not have
these migration problems, because the architectural state does not
include vectors or some kind of width.

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

On Monday, November 1, 2021 at 9:01:52 AM UTC-5, Anton Ertl wrote:
> EricP <ThatWould...@thevillage.com> writes:
> >An OS exception handler could easily diagnose an AVX-512
> >instruction and re-route the thread to the big core.
> Yes. This is an interesting difference between the Intel way of
> adding instruction set extensions for the additional width and
> capability, and ARM's SVE approach (as far as I understand it). While
> SVE allows to run the program on a CPU with arbitrary width (and make
> use of the width without recompilation), it does not allow to migrate
> a running thread to a core with different width, because the thread
> can have the SVE width in many places in its state; foremost the
> vector registers. This will be interesting when people want to
> migrate virtual machines between ARM CPUs with different SVE widths.
>
> By contrast, you can at least migrate an AVX program from a core that
> has AVX to one that has AVX and AVX-512.
>
> So, much as SVE is an advance in width independence, there is still
> something missing. Maybe a special-purpose register that indicates
> the currently-used width and lets wider cores work as if they were
> narrower. This would allow at least migration to wider cores.
>
> Making use of the full width soon after could be facilitated by
> letting the software read the real width at points with empty vector
> state, and propagating the possibly new width to all the places where
> it matters (including the "currently-used width" register). However,
> given that migration to wider cores is a rare event, such an approach
> might lead to bugs popping up in the field, and I am skeptical that
> the additional utilization is worth the risk.
>
> I am sure that Mitch Alsup will point out that his VVM does not have
> these migration problems, because the architectural state does not
> include vectors or some kind of width.
<
Yes, but that would be too obvious...........
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> An OS exception handler could easily diagnose an AVX-512
>> instruction and re-route the thread to the big core.
>
> Yes. This is an interesting difference between the Intel way of
> adding instruction set extensions for the additional width and
> capability, and ARM's SVE approach (as far as I understand it). While
> SVE allows to run the program on a CPU with arbitrary width (and make
> use of the width without recompilation), it does not allow to migrate
> a running thread to a core with different width, because the thread
> can have the SVE width in many places in its state; foremost the
> vector registers. This will be interesting when people want to
> migrate virtual machines between ARM CPUs with different SVE widths.

On ARM SVE couldn't the OS thread management routines patch the
thread context? In which case this issue would mostly be one of
documentation of where in the save state SVE width is stored.

Or is there more to it than that? For example, if the thread was
interrupted part way through a vector or multiple vectors then
I can see that switching the width on the fly could be problematic.

Hardware might provide the OS with a sync mechanism which if the
core was executing any vector ops would finish the current vectors
and then trap to the OS, kinda like a single step.

> By contrast, you can at least migrate an AVX program from a core that
> has AVX to one that has AVX and AVX-512.

IIUC, with SVE it is still safe to migrate from a CPU with vector length
N to a CPU with vector length ≥N (but once that process has run there it's
not safe to move it back).

I'm not sure what happens in SVE if you request a vector length higher
than the CPU supports (which is akin to the case of running AVX-512 code
on a CPU that doesn't support it), but I expect it would signal an
exception, which the OS could then catch to move the process to a CPU
with a longer vector length.

So it doesn't look much worse than the situation with AVX.

Stefan

David Brown <david.brown@hesbynett.no> writes:
>On 28/10/2021 11:41, David Brown wrote:
>> On 27/10/2021 19:34, Anton Ertl wrote:
>>> Read all about it in Section 4.2 of
>>> <https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf>.
....
>How about presenting
>some facts and data?
[Later you write:]
>Eventually, I gave up reading the rest of the paper too.

If you really are interested in facts and data, maybe you should not
have skipped them.

>The paper has references taken out of context or designed to give the
>incorrect impression. For example, on page 4 we have:
>
>"""
>The GCC maintainers subsequently disabled this optimization for the case
>occuring in SPEC, demonstrating that, inofficially, GCC supports Cbench,
>not “C”.
>"""
>
>The associated footnote refers to a gcc bug report which you presumably
>hope readers of your paper will not bother checking. If they do, they
>will see that the reporter of the "bug" thanks the gcc developers for
>helping him find the error in his code, and that report is marked as
>"invalid" - not a bug in the compiler.

If the gcc developers mark a bug report as "invalid", that means that
they don't consider it to be a bug. It does not mean that it is not a
bug.

In the case at hand, the bug report is
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875>. Here gcc finds
out that it can prove that there will be an out-of-bounds access if
execution reaches the loop. What does gcc do? Does it warn about the
out-of-bounds access? No. There would not have been a bug report if
it did. Which reminds me of the first specification for FORTRAN,
which states: "no special provisions havebeen included in the FORTRAN
system for locating errors in formulas".

So what does gcc do instead? It quietly deletes the loop.

I checked with gcc-10.2 -Wall -O3 and it still does not warn about the
out-of-bounds access and it still deletes the loop.

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

On Monday, November 1, 2021 at 3:29:00 PM UTC+2, Anton Ertl wrote:
> Quadibloc <jsa...@ecn.ab.ca> writes:
> >Since the Atom-based cores in the Xeon Phi were where AVX-512
> >originated, it should have been possible to include AVX-512 support
> >on the E-cores of Aldler Lake to avoid this horrendous compromise.
> The most recent Xeon Phi is Silvermont-based and supports a different
> AVX-512 than Golden Cove. Silvermont is several generations behind
> Gracemont: Silvermont, Goldmont, Goldmont+, Tremont, Gracemont. It's
> probably non-trivial to adapt Xeon Phi AVX-512 to Gracemont and extend
> it to the full extent of present-day AVX-512. This was also in a
> larger process, and was not designed in a way that makes shrinking
> easy. And the main idea of Gracemont is to be small

It would surprise me if Gracemont is smaller than Broadwell, process-adjusted.

> and consume
> little power, and Xeon Phi AVX-512 units were probably designed more
> for performance.

For high issue rate (up to two 512-bit FMA/clock) and low frequency.
I don't know if it could be called "for performance", because in practice high issue rate was unattainable due to other bottlenecks, esp. decode.
IMHO, KNL was stupidly bad design that should have never been allowed to ship.

>
> An alternative would be to implement AVX-512 with narrower units (like
> AMD implemented AVX-256 before Zen 2, including on its small and
> efficient cores). But for some reason Intel did not go there.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>