Thermals are thermals, and die area is die area.
So I can't blame AMD too much for the fact that the new generation of Ryzen chips, although they include AVX-512, are, at leaslt to me, a disappointment.

However, single-thread performance is often crucial for many applications. Of course, only *newer* applications will be written to make use of the relatively new AVX-512 feature, and those applications are also new enough to be properly thread-aware.

So I don't suppose that pairing up the cores into core complexes, where they can link their 256-bit vector units into a single shared 512-bit unit, is necessarily that urgently needed. (It would be odd if vectorized code wasn't parallizable...)

But still, it's a pity that the lawsuit may be preventing AMD from re-using this potentially useful idea from Bulldozer.

John Savard

Quadibloc <jsavard@ecn.ab.ca> wrote:
> Thermals are thermals, and die area is die area.
> So I can't blame AMD too much for the fact that the new generation of
> Ryzen chips, although they include AVX-512, are, at leaslt to me, a disappointment.

The new Ryzen chips clock at 5.7 GHz, what is not to like.

> However, single-thread performance is often crucial for many
> applications. Of course, only *newer* applications will be written to
> make use of the relatively new AVX-512 feature, and those applications
> are also new enough to be properly thread-aware.

No point in doubling the actual vector unit if you do not double the
load/store bus width to all levels of cache.

But if you double all those busses that is going to cost you power and
clocks.

I am on record that Apple will never copy AVX-512 for its ARM chip.
Heavy lifting is better done on more efficient custom math units and the
Apple chips use the AI or graphics engines library’s for bulk data
transform. Which nets you far higher performance at far lower power.

The age of the CPU as God is OVER.

Look at Apple silicon, the CPU’s are a tiny block in a corner with half the
die graphics an most of the rest dedicated compute engines for different
tasks like real time video encoding at a tenth the power of the CPU and a
tenth the die space and four times the performance. There are dozens of
these units with different levels of programmability. The more they are
programmable the more they cost in power and die size with the CPU’s being
the worst.

> So I don't suppose that pairing up the cores into core complexes, where
> they can link their 256-bit vector units into a single shared 512-bit
> unit, is necessarily that urgently needed. (It would be odd if vectorized
> code wasn't parallizable...)
>
> But still, it's a pity that the lawsuit may be preventing AMD from
> re-using this potentially useful idea from Bulldozer.
>
> John Savard
>

On Wednesday, August 31, 2022 at 2:49:03 AM UTC-6, gg...@yahoo.com wrote:

> Look at Apple silicon, the CPU’s are a tiny block in a corner with half the
> die graphics an most of the rest dedicated compute engines for different
> tasks like real time video encoding at a tenth the power of the CPU and a
> tenth the die space and four times the performance.

And just how do you use a video encoding engine for computational fluid
dynamics?

I don't want a computer that only lets me be a passive consumer of media.

I want a _supercomputer_ on my desktop.

So I want something which is highly programmable, highly flexible, suitable
for any application, and yet gives me as many TFLOPS as a GPU. Of course
that will take power, die size, and memory bandwidth. Fine. I'm OK with a
single-core CPU with Cray-style vectors packaged in a Threadripper/EPYC
style package. Since I still want it subsidized by being a mass-market
consumer item, it's okay for it to only be _half_ as powerful as a (14nm!)
NEC SX-Aurora TSUBASA computer.

John Savard

Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Wednesday, August 31, 2022 at 2:49:03 AM UTC-6, gg...@yahoo.com wrote:
>
>> Look at Apple silicon, the CPU’s are a tiny block in a corner with half the
>> die graphics an most of the rest dedicated compute engines for different
>> tasks like real time video encoding at a tenth the power of the CPU and a
>> tenth the die space and four times the performance.
>
> And just how do you use a video encoding engine for computational fluid
> dynamics?

Write your code in Metal and Apple will schedule that code on the fastest
hardware capable of running that code, be it CPU or GPU, or AI or one of
the other dedicated blocks.

Metal is designed for bulk transform of data.

> I don't want a computer that only lets me be a passive consumer of media.
>
> I want a _supercomputer_ on my desktop.
>
> So I want something which is highly programmable, highly flexible, suitable
> for any application, and yet gives me as many TFLOPS as a GPU. Of course
> that will take power, die size, and memory bandwidth. Fine. I'm OK with a
> single-core CPU with Cray-style vectors packaged in a Threadripper/EPYC
> style package. Since I still want it subsidized by being a mass-market
> consumer item, it's okay for it to only be _half_ as powerful as a (14nm!)
> NEC SX-Aurora TSUBASA computer.
>
> John Savard
>

Brett <ggtgp@yahoo.com> schrieb:
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Wednesday, August 31, 2022 at 2:49:03 AM UTC-6, gg...@yahoo.com wrote:
>>
>>> Look at Apple silicon, the CPU’s are a tiny block in a corner with half the
>>> die graphics an most of the rest dedicated compute engines for different
>>> tasks like real time video encoding at a tenth the power of the CPU and a
>>> tenth the die space and four times the performance.
>>
>> And just how do you use a video encoding engine for computational fluid
>> dynamics?
>
> Write your code in Metal and Apple will schedule that code on the fastest
> hardware capable of running that code, be it CPU or GPU, or AI or one of
> the other dedicated blocks.
>
> Metal is designed for bulk transform of data.

I tried reading some of the introductions by Apple, but my bullshit
meter went off-scale high.

On 9/1/2022 12:02 AM, Thomas Koenig wrote:
> Brett <ggtgp@yahoo.com> schrieb:
>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>> On Wednesday, August 31, 2022 at 2:49:03 AM UTC-6, gg...@yahoo.com wrote:
>>>
>>>> Look at Apple silicon, the CPU’s are a tiny block in a corner with half the
>>>> die graphics an most of the rest dedicated compute engines for different
>>>> tasks like real time video encoding at a tenth the power of the CPU and a
>>>> tenth the die space and four times the performance.
>>>
>>> And just how do you use a video encoding engine for computational fluid
>>> dynamics?
>>
>> Write your code in Metal and Apple will schedule that code on the fastest
>> hardware capable of running that code, be it CPU or GPU, or AI or one of
>> the other dedicated blocks.
>>
>> Metal is designed for bulk transform of data.
>
> I tried reading some of the introductions by Apple, but my bullshit
> meter went off-scale high.

Yeah, it seems like much outside of specific high-level APIs or general
categories of workload, making something like this work in the general
case would be difficult.

Though, if one has several class of hardware which can all run a given
piece of code (CPU, GPU, DSP cores, etc) it does seem like it would be
possible to compile code for all of them and then see which type of core
could run the faster.

There are likely to be limits though, for example, if one has dedicated
video decoder hardware features, it is rather unlikely one can
efficiently pattern match these from generic C or C++ source of a video
codec or similar (as opposed to code written specifically to use these
features).

So, ultimately, there are limits, and one would need either specialized
APIs or language extensions to make it work.

Even in my own ISA efforts, I am running into this issue:
* I don't have auto vectorization, or fancy pattern recognition;
* So, some stuff depends on language extensions
** Which in turn only works with code which uses these extensions.
** Which creates issues with keeping the code portable and efficient.
** ...

Some level of portability can be maintained by falling back to
structures and function calls in the generic case, but then cases where
things diverge are harder to fake efficiently (some amount of code
optimized for BJX2 is worse off on x86 due to divergence).

Similarly, Intel/MSVC and GCC using two different ways of approaching
SIMD support doesn't really help either.

One could argue that maybe it would be nice if the C standard could
support (explicit) SIMD operations, but alas this implicitly assumes
that the targets roughly agree as to SIMD hardware capabilities and/or
there is a defined way to deal with this (say, the compiler has to fake
it if the actual ISA can't do it).

While one could argue that needing to fall back to runtime support to
fake SIMD operations that don't exist in hardware, it is not exactly
like things like: "for(i=0; i<4; i++) vc[i]=va[i]+vb[i];" is necessarily
a high performance option either (and then leaves it up to the C
compiler to try to figure out that a "float *" pointer is really meant
to be understood as a 4 element vector).

Granted, "How about we start gluing stuff inspired by GLSL onto C?" (and
maybe start combining this with async/join semantics, *, etc) isn't
really a popular solution either...

*: where async can allow a sub-task to run asynchronously (either fully
independent or with a "promise") and "join" allows blocking until an
async sub-task is complete (and potentially fetching its final result),
and implicitly using these as a compiler optimization hint (we don't
care about the relative order of these sub-tasks, only that maybe we
care that they finish before the program "joins" on the promise handle).

But, then one can then debate between finer grained / lighter weight
solutions (compiler optimization hint, but otherwise mostly implemented
in terms of conventional linear execution semantics), and a more
powerful but heavyweight solution (the async/promise effectively
schedules a sub-task as a green-thread or similar). Or, if both are
possible, how exactly the compiler should know when to choose which is
better (eg: you wouldn't want to green-thread a 4x4 matrix multiply, the
performance overhead on this would *suck*; but a 128x128 matrix multiply
is a different beast entirely).

Though, some of this could be inferred based on how the feature is used
(if used on a "clean" expression or a "sufficiently pure" function (*2),
assume it is a hint unless the expression is doing something
particularly crazy; else assume the more heavyweight "use green-threads
or something" option). Well, or alternately provide additional keywords
to allow the programmer to further specify what sort of semantics they
expect from the async/promise (well, or infer it based on whether the
async and its corresponding join exist within the same control-path, or
assume green-threads if no immediately visible join exists, etc).

*2: Actually, what mostly matters for this is if there is some way the
called function can potentially block on IO or lock a mutex or similar,
which would lead to visibly different behaviors between "schedule this
as a sub-task" and "allow lazy reordering but otherwise still execute
the code sequentially".

....

BGB <cr88192@gmail.com> wrote:
> On 9/1/2022 12:02 AM, Thomas Koenig wrote:
>> Brett <ggtgp@yahoo.com> schrieb:
>>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>> On Wednesday, August 31, 2022 at 2:49:03 AM UTC-6, gg...@yahoo.com wrote:
>>>>
>>>>> Look at Apple silicon, the CPU’s are a tiny block in a corner with half the
>>>>> die graphics an most of the rest dedicated compute engines for different
>>>>> tasks like real time video encoding at a tenth the power of the CPU and a
>>>>> tenth the die space and four times the performance.
>>>>
>>>> And just how do you use a video encoding engine for computational fluid
>>>> dynamics?
>>>
>>> Write your code in Metal and Apple will schedule that code on the fastest
>>> hardware capable of running that code, be it CPU or GPU, or AI or one of
>>> the other dedicated blocks.
>>>
>>> Metal is designed for bulk transform of data.
>>
>> I tried reading some of the introductions by Apple, but my bullshit
>> meter went off-scale high.
>
> Yeah, it seems like much outside of specific high-level APIs or general
> categories of workload, making something like this work in the general
> case would be difficult.
>
> Though, if one has several class of hardware which can all run a given
> piece of code (CPU, GPU, DSP cores, etc) it does seem like it would be
> possible to compile code for all of them and then see which type of core
> could run the faster.
>
> There are likely to be limits though, for example, if one has dedicated
> video decoder hardware features, it is rather unlikely one can
> efficiently pattern match these from generic C or C++ source of a video
> codec or similar (as opposed to code written specifically to use these
> features).

The video decoder is a source, though half of decode is shifting data from
a previous frame for motion compensation and may be done on the GPU.
Then you may add an overlay like TV News in Metal, and output to video
encoder hardware, which again may be using the GPU (or DSP or AI) to detect
motion in the frames.

For extra bonus points use the source stream to hint the output stream on
what to try first for huge power savings. But that would be custom Apple
code. ;)

What is important is having a huge L3 so all these tasks can fit and all
sources and destinations have equal fast access to the data, be it CPU,
GPU, DSP, AI, and all the different encode and decode engines. All at the
same time, in sync.

For video you need to fit three 16 pixel tall stripes for the source and
another three stripes for the output, times the number of frames you can
borrow from.

The old way was the CPU did all of this, which was slow and hot.
The new way is an orchestra of musicians hardware efficiently producing
excellence.

Metal is the conductor of the orchestra and provides the play sheets.

> So, ultimately, there are limits, and one would need either specialized
> APIs or language extensions to make it work.
>
> Even in my own ISA efforts, I am running into this issue:
> * I don't have auto vectorization, or fancy pattern recognition;
> * So, some stuff depends on language extensions
> ** Which in turn only works with code which uses these extensions.
> ** Which creates issues with keeping the code portable and efficient.
> ** ...
>
> Some level of portability can be maintained by falling back to
> structures and function calls in the generic case, but then cases where
> things diverge are harder to fake efficiently (some amount of code
> optimized for BJX2 is worse off on x86 due to divergence).
>
> Similarly, Intel/MSVC and GCC using two different ways of approaching
> SIMD support doesn't really help either.
>
> One could argue that maybe it would be nice if the C standard could
> support (explicit) SIMD operations, but alas this implicitly assumes
> that the targets roughly agree as to SIMD hardware capabilities and/or
> there is a defined way to deal with this (say, the compiler has to fake
> it if the actual ISA can't do it).
>
> While one could argue that needing to fall back to runtime support to
> fake SIMD operations that don't exist in hardware, it is not exactly
> like things like: "for(i=0; i<4; i++) vc[i]=va[i]+vb[i];" is necessarily
> a high performance option either (and then leaves it up to the C
> compiler to try to figure out that a "float *" pointer is really meant
> to be understood as a 4 element vector).
>
> Granted, "How about we start gluing stuff inspired by GLSL onto C?" (and
> maybe start combining this with async/join semantics, *, etc) isn't
> really a popular solution either...
>
> *: where async can allow a sub-task to run asynchronously (either fully
> independent or with a "promise") and "join" allows blocking until an
> async sub-task is complete (and potentially fetching its final result),
> and implicitly using these as a compiler optimization hint (we don't
> care about the relative order of these sub-tasks, only that maybe we
> care that they finish before the program "joins" on the promise handle).
>
> But, then one can then debate between finer grained / lighter weight
> solutions (compiler optimization hint, but otherwise mostly implemented
> in terms of conventional linear execution semantics), and a more
> powerful but heavyweight solution (the async/promise effectively
> schedules a sub-task as a green-thread or similar). Or, if both are
> possible, how exactly the compiler should know when to choose which is
> better (eg: you wouldn't want to green-thread a 4x4 matrix multiply, the
> performance overhead on this would *suck*; but a 128x128 matrix multiply
> is a different beast entirely).
>
> Though, some of this could be inferred based on how the feature is used
> (if used on a "clean" expression or a "sufficiently pure" function (*2),
> assume it is a hint unless the expression is doing something
> particularly crazy; else assume the more heavyweight "use green-threads
> or something" option). Well, or alternately provide additional keywords
> to allow the programmer to further specify what sort of semantics they
> expect from the async/promise (well, or infer it based on whether the
> async and its corresponding join exist within the same control-path, or
> assume green-threads if no immediately visible join exists, etc).
>
> *2: Actually, what mostly matters for this is if there is some way the
> called function can potentially block on IO or lock a mutex or similar,
> which would lead to visibly different behaviors between "schedule this
> as a sub-task" and "allow lazy reordering but otherwise still execute
> the code sequentially".

On Wednesday, August 31, 2022 at 5:12:24 PM UTC-6, gg...@yahoo.com wrote:

> Write your code in Metal

I think I'd rather write it in Fortran if at all possible. That has been what
the serious people doing this kind of stuff have used, and therefore
Fortran compilers continue to be designed to produce highlty efficient
object code, continuing the tradition set by the very first FORTRAN
compiler.

John Savard

On Thursday, September 1, 2022 at 8:09:33 PM UTC-5, Quadibloc wrote:
> On Wednesday, August 31, 2022 at 5:12:24 PM UTC-6, gg...@yahoo.com wrote:
>
> > Write your code in Metal
> I think I'd rather write it in Fortran if at all possible. That has been what
> the serious people doing this kind of stuff have used, and therefore
> Fortran compilers continue to be designed to produce highlty efficient
> object code, continuing the tradition set by the very first FORTRAN
> compiler.
>
> John Savard

Fortran is burned into my head. Julia is its worthy successor (IMHO).
Relied on Fortran's subscript optimization to make my code readable.

On 31/08/22 20:49, Brett wrote:

>
> The new Ryzen chips clock at 5.7 GHz, what is not to like.
>

If the reports of Ryzen CPUs containing Microsoft's PLUTON 'security'
feature are true and it is indeed impossible to install any other
operating system rather than Windows 11 on the things, then I for one
would say there is quite a lot not to like about them.

Is AMD expecting Linux users to run out and buy a Zen4 based server
board to use as a home PC? is that even possible let alone affordable?

Andy <nospam@nowhere.com> wrote:
> On 31/08/22 20:49, Brett wrote:
>
>>
>> The new Ryzen chips clock at 5.7 GHz, what is not to like.
>>
>
> If the reports of Ryzen CPUs containing Microsoft's PLUTON 'security'
> feature are true and it is indeed impossible to install any other
> operating system rather than Windows 11 on the things, then I for one
> would say there is quite a lot not to like about them.
>
> Is AMD expecting Linux users to run out and buy a Zen4 based server
> board to use as a home PC? is that even possible let alone affordable?

Fake news.
You can turn off Pluton and install Linux, assuming you have your password.

https://www.kitguru.net/components/cpu/joao-silva/amd-ryzen-pro-chips-with-microsoft-pluton-wont-boot-linux/

The reason for Pluton is to stop resale of stolen laptops, like iPhones
today.

Even worse using a stolen laptop to steal and empty your bank account and
max out you credit cards used on the laptop. Steal your identity and get
credit cards in your name, etc. Pluton encrypts your data making this
non-government impossible. Same as iPhone.

On 4/09/22 10:47, Brett wrote:
> Andy <nospam@nowhere.com> wrote:
>> On 31/08/22 20:49, Brett wrote:
>>
>>>
>>> The new Ryzen chips clock at 5.7 GHz, what is not to like.
>>>
>>
>> If the reports of Ryzen CPUs containing Microsoft's PLUTON 'security'
>> feature are true and it is indeed impossible to install any other
>> operating system rather than Windows 11 on the things, then I for one
>> would say there is quite a lot not to like about them.
>>
>> Is AMD expecting Linux users to run out and buy a Zen4 based server
>> board to use as a home PC? is that even possible let alone affordable?
>
> Fake news.

You have an odd definition of 'fake news' when the article you point to
essentially backs up what I heard, the only saving grace being the last
line which points out you can turn Pluton off in the UEFI in order to
install other operating systems, so yay! I guess.

Why is this Microsoft toxic sludge on any CPU again?

> You can turn off Pluton and install Linux, assuming you have your password.

Wait you need a password to do so?
So forget/misplace your Pluton password and your otherwise fully
functional computer becomes little more than useless e-waste?

> https://www.kitguru.net/components/cpu/joao-silva/amd-ryzen-pro-chips-with-microsoft-pluton-wont-boot-linux/
>
> The reason for Pluton is to stop resale of stolen laptops, like iPhones
> today.

Which if you're not running Windows 11 you had to turn off in order to
install your preferred operating system.

> Even worse using a stolen laptop to steal and empty your bank account and
> max out you credit cards used on the laptop. Steal your identity and get
> credit cards in your name, etc. Pluton encrypts your data making this
> non-government impossible. Same as iPhone.

Given that can be accomplished by criminals over the internet already I
have little faith MS is going to fix the problem, I just hope the Pluton
'cure' doesn't end up being worse than the disease!

Andy <nospam@nowhere.com> schrieb:
> On 4/09/22 10:47, Brett wrote:
>> Andy <nospam@nowhere.com> wrote:
>>> On 31/08/22 20:49, Brett wrote:
>>>
>>>>
>>>> The new Ryzen chips clock at 5.7 GHz, what is not to like.
>>>>
>>>
>>> If the reports of Ryzen CPUs containing Microsoft's PLUTON 'security'
>>> feature are true and it is indeed impossible to install any other
>>> operating system rather than Windows 11 on the things, then I for one
>>> would say there is quite a lot not to like about them.
>>>
>>> Is AMD expecting Linux users to run out and buy a Zen4 based server
>>> board to use as a home PC? is that even possible let alone affordable?
>>
>> Fake news.
>
> You have an odd definition of 'fake news' when the article you point to
> essentially backs up what I heard, the only saving grace being the last
> line which points out you can turn Pluton off in the UEFI in order to
> install other operating systems, so yay! I guess.
>
> Why is this Microsoft toxic sludge on any CPU again?

Microsoft appears to have blocked Linux some Linux boot loaders
with a "security" update, among them Ubuntu 20.04 LTS, according to
https://www.heise.de/hintergrund/Bootloader-Signaturen-per-Update-zurueckgezogen-Microsoft-bootet-Linux-aus-7250544.html
(German, unfortunately behind a paywall).

Hmm...