> On Wed, 16 Jun 2021 13:15:40 -0400, you wrote:
>
>>The answer given, and I'm
>>not making this up, is that AMD listens to their users and gives the
>>users what they want, and right now they're not hearing any demand for
>>AVX512.
>>
>>Personally, I call BS on that one. I can't imagine anyone
Hi all,
This is, in my humble opinion, also the big problem CPUs are facing. They
> are
> build to tackle all possible scenarios, from simple integer to floating
> point,
> from in-memory to disc I/O. In some respect it would have been better to
> stick
> with a separate math unit which then
Dear all
> System architecture has been a problem ... making a processing unit
> 10-100x as fast as its support components means you have to code with
> that in mind. A simple `gfortran -O3 mycode.f` won't necessarily
> generate optimal code for the system ( but I swear ... -O3 ... it says
> it
AVX-512 is SIMD and in that respect compiled Intel routines will run almost
automatically on Intel processors.
It's not like I was answering the question. I realize or under realize the
implementation problems. You need to do a side by side comparison of the
die.
On Mon, Jun 21, 2021, 7:47 AM
On Mon, Jun 21, 2021 at 09:46:30AM -0400, Joe Landman wrote:
> On 6/21/21 9:20 AM, Jonathan Engwall wrote:
> > I have followed this thinking "square peg, round hole."
> > You have got it again, Joe. Compilers are your problem.
>
>
> Erp ... did I mess up again?
>
> Here's where awesome compiler
On 6/21/21 9:20 AM, Jonathan Engwall wrote:
I have followed this thinking "square peg, round hole."
You have got it again, Joe. Compilers are your problem.
Erp ... did I mess up again?
System architecture has been a problem ... making a processing unit
10-100x as fast as its support
I have followed this thinking "square peg, round hole."
You have got it again, Joe. Compilers are your problem.
On Sun, Jun 20, 2021, 10:21 AM Joe Landman wrote:
> (Note: not disagreeing at all with Gerald, actually agreeing strongly ...
> also, correct address this time! Thanks Gerald!)
>
>
Dear all,
same here, I should have joined the discussion earlier but currently I am
recovering from a trapped ulnaris nerve OP, so long typing is something I need
to avoid.
As it is quite apt I think, I would like to inform you about this upcoming
talk (copy):
**
*Performance
I apologize - I should have written earlier, but I don't always work
with my broken right hand. It seems to me that a reasonable basis for
discussing AMD EPYC performance could be the specified performance
data in the Daresburg University benchmark from M.Guest. Yes, newer
versions of AMD EPYC
On Sun, 20 Jun 2021 06:51:58 +0100, you wrote:
>That is a very interesting point! I never thought of that.
>Also mobile drives ARM development - yes I know the CPUs in Isambard and
>Fugaku will not be seen in your mobile phone but the ecosystem is propped
>up by having a diverse market and also
we should be upto about EV12 by now...
On Sun, Jun 20, 2021 at 1:38 PM John Hearns wrote:
> Regarding benchmarking real world codes on AMD , every year Martyn Guest
> presents a comprehensive set of benchmark studies to the UK Computing
> Insights Conference.
> I suggest a Sunday afternoon with
That is a very interesting point! I never thought of that.
Also mobile drives ARM development - yes I know the CPUs in Isambard and
Fugaku will not be seen in your mobile phone but the ecosystem is propped
up by having a diverse market and also the power saving priorities of
mobile will influence
Regarding benchmarking real world codes on AMD , every year Martyn Guest
presents a comprehensive set of benchmark studies to the UK Computing
Insights Conference.
I suggest a Sunday afternoon with the beverage of your choice is a good
time to settle down and take time to read these or watch the
I think that’s a major important point. Even if the whole of the HPC market
were clamouring for it (which they’re not, judging by this discussion) that’s
still a very small proportion of the worldwide CPU market. We have to remember
that we in the HPC community are a niche market. I recall
On Wed, 16 Jun 2021 13:15:40 -0400, you wrote:
>The answer given, and I'm
>not making this up, is that AMD listens to their users and gives the
>users what they want, and right now they're not hearing any demand for
>AVX512.
>
>Personally, I call BS on that one. I can't imagine anyone in the
I've told AMD brass that we need AVX512 many many times.
I've also told them that we need more memory bandwidth and that adding
dimms is not the answer. We don't need more capacity - just more bandwidth.
We have a stack load of KNL systems and have invested heavily in AVX512
(writing with
On Wed, Jun 16, 2021 at 1:15 PM Prentice Bisbal via Beowulf <
beowulf@beowulf.org> wrote:
> Did anyone else attend this webinar panel discussion with AMD hosted by
> HPCWire yesterday? It was titled "AMD HPC Solutions: Enabling Your
> Success in HPC"
>
>
AMD's argument is a little unsalesmen like, but i'd buy it as an
explanation. avx512 uptake isn't a profound as intel would lead you
to believe and the push to GPU's for vectors will probably remove the
need for most of these high end vectors sooner or later (but that's my
opinion, some chip
On Wed, Jun 16, 2021 at 2:16 PM Prentice Bisbal via Beowulf <
beowulf@beowulf.org> wrote:
> Last fall I evaluated potential new cluster nodes for a large cluster
> purchase using the HPL benchmark. I compared a server with dual AMD EPYC
> 7H12 processors (128) cores to a server with quad Intel
19 matches
Mail list logo
