Memory bandwidth

[James Harris]

I don't know about you but I never cease to be amazed by the hardware we
have available. I was looking for some figures on memory bandwidth and
came across this:

https://www.forrestthewoods.com/blog/memory-bandwidth-napkin-math/

There's a bunch of stuff there that's worth a read but perhaps the
headline is that the author says RAM can be accessed at tens of
gigabytes per second!

Such figures are backed up by

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

so they seem to be correct.

Mind blowing, isn't it!


--
James Harris

[Scott Lurndal]

100Gb ethernet will do 10 gigabytes a second - memory needs to
keep up.

I work with systems that have multiple 100Gb NICs, and 400Gb/sec
is common on high-end fiber backbones.

[wolfgang kern]

yes, but still a bit too expensive for a normal desktop PC.
I'm happy with my 64GB DDR3 RAM and the 8GB DDR5 VRAM. it
would need very short lines to achieve the mentioned speed.
__
wolfgang

[anti...@math.uni.wroc.pl]

That may look fast, but actually frequently RAM has too small
bandwidth. Consider 3GHz quad core machine using SSE. Each
core can perform 16-byte fetch per cycle (and there is enough
computing power to do something useful with this data). That
sums up to

3*10^9*4*16 = 192*19^9
^^^^ ^ ^
clock | \ bytes per access
core

that is 192 gigabytes per second. With AVX fetch width
double, some cores can do two accesses per cycle, 3GHz
is not the fastest clock and you may have more cores.
So if you use data from RAM your CPU can operate only
at fraction of its top speed...

--

Waldek Hebisch

[Rod Pemberton]

That computer memory bandwidth has to be substantially faster than the
human mind's effective bandwidth. Yes?

At what point will a computer have capabilities comparable to the human
mind?


<off-topic OT, sentient AI Sci-fi rant ...>

When a machine's intellectual capabilities matches ours, that's the
point where you/we need to seriously worry. Actually, you/we need to
start worrying sufficiently prior to that event, in order to help
prevent it from occurring. Sentient machines are very likely to be an
exceptionally grave threat to humanity. Our dystopian future could be
straight out of the Terminator movies. There will be no way for us to
control "them" once they're sentient. I.e., given a fractured
artificial mind, such one with multiple personalities, Asimov's three
laws become totally worthless. Unfortunately, there will always be
optimists and liberal technologist who fail to recognize the threats
until it's too late. They only recognize the good, the benefits to
humanity, and will push the boundaries too far, breaking them. They'll
"play God" in the name of profits or some utopian delusion, believing
that humanity has the power, knowledge, and science to control
everything within it's grasp. Of the dozen or so potential world enders
on my list, sentient A.I. is at the very top.


--
What is hidden in the ground, when found, is hidden there again?

[Branimir Maksimovic]

impossible on digital computer...
>
>

[James Harris]

On 25/06/2021 13:17, Kerr-Mudd, John wrote:
> On Fri, 25 Jun 2021 11:59:42 +0100
> James Harris <james.h...@gmail.com> wrote:
>

> I was waiting for the graph. Disappointed now. I remember Norton? speedcheck?; shows how your PC compares with an AT.

Such a comparison would probably be a bit too extreme!

>
>>
>> Mind blowing, isn't it!
>>
>>

> Yup.

Curiously, your post shows up on Eternal September and AIOE but not
(yet) on Google Groups. Is that something you've chosen, e.g. with a
header setting?


--
James Harris

[James Harris]

All such numbers are reasonably familiar but it's trying to get one's
head around how they relate to reality which is so impressive. Even if
we acknowledge the bus width, 32GB/s would require something like four
billion separate memory transactions to be carried out in a second,
wouldn't it? Four billion carefully controlled bus transactions. In just
one second.

I would suggest that such numbers are not really graspable. It has
become a bit like astronomy: one can accept large numbers and use
notation to work with them but it's not really possible to internalise
them.



--
James Harris

[James Harris]

Curiously, I remember someone here (his initials were WK, IIRC) telling
me that it was not feasible to test memory before handing it out as that
would take too long. That is, in fact, why I went looking for figures on
memory performance.

Have to say that whether it's with DDR5 or DDR3 ISTM quite feasible to
do the test on memory before handing it out. That's especially so as the
kernel would only need a small amount of memory to start with. All the
rest could be tested in the background, later. And even that would be
finished maybe 5 or 6 seconds. Testing of memory looks feasible. :-)


--
James Harris

[James Harris]

On 25/06/2021 20:24, anti...@math.uni.wroc.pl wrote:
> James Harris <james.h...@gmail.com> wrote:
>> I don't know about you but I never cease to be amazed by the hardware we
>> have available. I was looking for some figures on memory bandwidth and
>> came across this:
>>
>> https://www.forrestthewoods.com/blog/memory-bandwidth-napkin-math/

...

>> Mind blowing, isn't it!
>
> That may look fast, but actually frequently RAM has too small
> bandwidth. Consider 3GHz quad core machine using SSE. Each
> core can perform 16-byte fetch per cycle (and there is enough
> computing power to do something useful with this data). That
> sums up to
>
> 3*10^9*4*16 = 192*19^9
> ^^^^ ^ ^
> clock | \ bytes per access
> core
>
> that is 192 gigabytes per second. With AVX fetch width
> double, some cores can do two accesses per cycle, 3GHz
> is not the fastest clock and you may have more cores.
> So if you use data from RAM your CPU can operate only
> at fraction of its top speed...

I know CPUs are even faster. (The aforementioned article may even
include the familiar graph of how CPU and RAM performance diverged over
time.) But it's surely unreasonable to call RAM slow! I would suggest
that RAM and CPU speeds are both so impressive that while we might be
able to acknowledge them we cannot really internalise them.


--
James Harris

[James Harris]

On 26/06/2021 07:44, Rod Pemberton wrote:
> On Fri, 25 Jun 2021 11:59:42 +0100
> James Harris <james.h...@gmail.com> wrote:

...

>> Mind blowing, isn't it!
>>
>
> That computer memory bandwidth has to be substantially faster than the
> human mind's effective bandwidth. Yes?

But nothing like as parallel.

>
> At what point will a computer have capabilities comparable to the human
> mind?

They are very different beasts. A computer has precision and
repeatability. The human mind has judgement, breadth, emotion and,
curiously, the ability to be unselfish, to act according to principle
rather than gain.

A computer can only do what it's programmed to do (perhaps including
learning, yes, but that, again, is directed by a program) so perhaps a
better question for you to ask is whether /a program/ will have
capabilities comparable to the human brain.


--
James Harris

[wolfgang kern]

On 26.06.2021 11:23, James Harris wrote:
> On 25/06/2021 17:27, wolfgang kern wrote:
>> On 25.06.2021 12:59, James Harris wrote:
>>> I don't know about you but I never cease to be amazed by the hardware
>>> we have available. I was looking for some figures on memory bandwidth
>>> and came across this:
>>>
>>>    https://www.forrestthewoods.com/blog/memory-bandwidth-napkin-math/
>>>
>>> There's a bunch of stuff there that's worth a read but perhaps the
>>> headline is that the author says RAM can be accessed at tens of
>>> gigabytes per second!
>>>
>>> Such figures are backed up by
>>>
>>>    https://en.wikipedia.org/wiki/List_of_interface_bit_rates
>>>
>>> so they seem to be correct.
>>>
>>> Mind blowing, isn't it!
>>
>> yes, but still a bit too expensive for a normal desktop PC.
>> I'm happy with my 64GB DDR3 RAM and the 8GB DDR5 VRAM. it
>> would need very short lines to achieve the mentioned speed.

> Curiously, I remember someone here (his initials were WK, IIRC) telling
> me that it was not feasible to test memory before handing it out as that
> would take too long. That is, in fact, why I went looking for figures on
> memory performance.

yeah :) I tested already mounted RAM in a PC before delivery, but a full
walking bit test would have taken several weeks or even more. So my test
was restricted to R-M-W on random chosen blocks and took about 8 hours.

> Have to say that whether it's with DDR5 or DDR3 ISTM quite feasible to
> do the test on memory before handing it out. That's especially so as the
> kernel would only need a small amount of memory to start with. All the
> rest could be tested in the background, later. And even that would be
> finished maybe 5 or 6 seconds. Testing of memory looks feasible. :-)

now I'd had problems if a fail were detected after delivery.

the problem is how to connect RAM to the CPU, best for sure is to have
all memory inside the CPU. Over a Bus would cause a massive bottleneck.
__
wolfgang

[Scott Lurndal]

James Harris <james.h...@gmail.com> writes:
>On 25/06/2021 15:20, Scott Lurndal wrote:
>> James Harris <james.h...@gmail.com> writes:
>>> I don't know about you but I never cease to be amazed by the hardware we
>>> have available. I was looking for some figures on memory bandwidth and
>>> came across this:
>>>
>>> https://www.forrestthewoods.com/blog/memory-bandwidth-napkin-math/
>>>
>>> There's a bunch of stuff there that's worth a read but perhaps the
>>> headline is that the author says RAM can be accessed at tens of
>>> gigabytes per second!
>>>
>>> Such figures are backed up by
>>>
>>> https://en.wikipedia.org/wiki/List_of_interface_bit_rates
>>>
>>> so they seem to be correct.
>>>
>>> Mind blowing, isn't it!
>>
>> 100Gb ethernet will do 10 gigabytes a second - memory needs to
>> keep up.
>>
>> I work with systems that have multiple 100Gb NICs, and 400Gb/sec
>> is common on high-end fiber backbones.
>>
>
>All such numbers are reasonably familiar but it's trying to get one's
>head around how they relate to reality which is so impressive. Even if
>we acknowledge the bus width, 32GB/s would require something like four
>billion separate memory transactions to be carried out in a second,
>wouldn't it? Four billion carefully controlled bus transactions. In just
>one second.

You seem to be assuming a single memory controller. Most of these
systems have multiple memory controllers (often one per dimm, or pair
of dimms).

The higher end designs have six or eight DDR5 memory controllers.

[Rod Pemberton]

On Sat, 26 Jun 2021 10:23:51 +0100
James Harris <james.h...@gmail.com> wrote:

> On 25/06/2021 17:27, wolfgang kern wrote:
> > On 25.06.2021 12:59, James Harris wrote:

> >> I don't know about you but I never cease to be amazed by the
> >> hardware we have available. I was looking for some figures on
> >> memory bandwidth and came across this:
> >>
> >>    https://www.forrestthewoods.com/blog/memory-bandwidth-napkin-math/
> >>
> >> There's a bunch of stuff there that's worth a read but perhaps the
> >> headline is that the author says RAM can be accessed at tens of
> >> gigabytes per second!
> >>
> >> Such figures are backed up by
> >>
> >>    https://en.wikipedia.org/wiki/List_of_interface_bit_rates
> >>
> >> so they seem to be correct.
> >>
> >> Mind blowing, isn't it!
> >
> > yes, but still a bit too expensive for a normal desktop PC.
> > I'm happy with my 64GB DDR3 RAM and the 8GB DDR5 VRAM. it
> > would need very short lines to achieve the mentioned speed.
>
> Curiously, I remember someone here (his initials were WK, IIRC)
> telling me that it was not feasible to test memory before handing it
> out as that would take too long. That is, in fact, why I went looking
> for figures on memory performance.

Unfortunately, I think his initials were RP ...

I recall telling someone - likely you - that I wasn't about to test my
memory chips for errors because of the time it takes. I.e., defective
memory chips are usually fairly noticeable with some type of glitch or
error or page fault or crash or corrupted data or corrupted screen,
etc. E.g., I always know when it's time to blow the dust off of one of
my memory chips here because of random app crashes.

> Have to say that whether it's with DDR5 or DDR3 ISTM quite feasible
> to do the test on memory before handing it out. That's especially so
> as the kernel would only need a small amount of memory to start with.
> All the rest could be tested in the background, later. And even that
> would be finished maybe 5 or 6 seconds. Testing of memory looks
> feasible. :-)
>

Well, the memory testing via the BIOS tester on a 2007 Dell PC takes
"forever". I don't recall if the machine has 1GB or 4GB etc. The BIOS
code which tests memory goes through numerous test repetitions on the
same memory locations and ranges, and has about a dozen different
memory tests. I think the code is all 16-bit. That PC was randomly
rebooting or locking up. It needed lots of fuzz and dust removed.

IIRC, memtest86+ loads from DOS. So, it's likely 16-bit code too, or
possibly 32-bit if was compiled for DPMI. 32-bit might not be too bad.

[Kerr-Mudd, John]

On Sun, 27 Jun 2021 11:41:24 +0100
"Kerr-Mudd, John" <ad...@127.0.0.1> wrote:

> On Sat, 26 Jun 2021 10:08:24 +0100
> James Harris <james.h...@gmail.com> wrote:
>
[]

> > Curiously, your post shows up on Eternal September and AIOE but not
> > (yet) on Google Groups. Is that something you've chosen, e.g. with a
> > header setting?
> >

> Could be; I'm nor a fan of GG, but I'm a bit vague on headers. Have I set X-No-Archive?
> I'll post this then check.
>

Better?

--
Bah, and indeed Humbug.

[muta...@gmail.com]

On Sunday, June 27, 2021 at 9:21:28 PM UTC+10, Kerr-Mudd, John wrote:

> > Could be; I'm nor a fan of GG, but I'm a bit vague on headers. Have I set X-No-Archive?
> > I'll post this then check.
>
> Better?

Welcome back after 500 years.

BFN. Paul.

[Branimir Maksimovic]

On 2021-06-27, Rod Pemberton <noe...@basdxcqvbe.com> wrote:
> IIRC, memtest86+ loads from DOS. So, it's likely 16-bit code too, or
> possibly 32-bit if was compiled for DPMI. 32-bit might not be too bad.

memtest86 can test more then megabyte so I guess it is not 16 bit...
>

[Scott Lurndal]

And then there is High Bandwidth Memory (HBM):

https://en.wikipedia.org/wiki/High_Bandwidth_Memory, up to 256GByte/sec BW
per package with HBM2.

HBM3 is to provide 665GByte/second BW.

[Rod Pemberton]

Aren't you familiar with "unreal" mode? ...
https://en.wikipedia.org/wiki/Unreal_mode

I.e., it can be 16 bit, if they adjusted the RM segment limits.

"Unreal" mode - available on later model 386's or thereafter - is used
by BIOS for Int 15h AH=87h, by various DPMI and XMS hosts such as M$
HIMEM.SYS, FASM assembler, and some games, etc to access more than 1MB.

Interestingly, you can't get out of PM by clearing CR0.PE on early
386's, just like on 286's (2nd link below), which means you can't set
up unreal mode for them either ...


Tomasz Grysztar of FASM on 16-bit/32-bit unreal modes:
https://board.flatassembler.net/topic.php?t=11940

Michal Necasek on the processor history of unreal mode:
http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/

Robert Collins article describing aspects of unreal mode:
http://www.rcollins.org/Productivity/DescriptorCache.html

BIOS Int 15h AH=87h - Copy extended memory
http://www.delorie.com/djgpp/doc/rbinter/id/35/15.html

BIOS Int 15h AH=89h - Switch to PM
http://www.delorie.com/djgpp/doc/rbinter/id/39/15.html

[Branimir Maksimovic]

On 2021-06-28, Rod Pemberton <noe...@basdxcqvbe.com> wrote:
> On Sun, 27 Jun 2021 15:17:43 GMT
> Branimir Maksimovic <branimir....@gmail.com> wrote:
>
>> On 2021-06-27, Rod Pemberton <noe...@basdxcqvbe.com> wrote:
>
>> > IIRC, memtest86+ loads from DOS. So, it's likely 16-bit code too,
>> > or possibly 32-bit if was compiled for DPMI. 32-bit might not be
>> > too bad.
>>
>> memtest86 can test more then megabyte so I guess it is not 16 bit...
>
> Aren't you familiar with "unreal" mode? ...

Yes, but that is 32 bit, not 16 bit programs...
Also I see metest can test more then 4GB so it
is 64 bit program...

[Rod Pemberton]

On Tue, 29 Jun 2021 23:05:49 GMT

Branimir Maksimovic <branimir....@gmail.com> wrote:

> On 2021-06-28, Rod Pemberton <noe...@basdxcqvbe.com> wrote:
> > On Sun, 27 Jun 2021 15:17:43 GMT
> > Branimir Maksimovic <branimir....@gmail.com> wrote:
> >> On 2021-06-27, Rod Pemberton <noe...@basdxcqvbe.com> wrote:

> >> > IIRC, memtest86+ loads from DOS. So, it's likely 16-bit code
> >> > too, or possibly 32-bit if was compiled for DPMI. 32-bit might
> >> > not be too bad.
> >>
> >> memtest86 can test more then megabyte so I guess it is not 16
> >> bit...
> >
> > Aren't you familiar with "unreal" mode? ...
>
> Yes, but that is 32 bit, not 16 bit programs...

No, unreal mode is generally 16-bit real-mode code. It's called unreal
mode because you have access to the entire memory range in real-mode.

As I understand it, 32-bit unreal mode is exceptionally difficult to
use due to an issue with interrupts. The only 32-bit unreal mode
example that I'm aware of is/was FASM.

[Branimir Maksimovic]

Look, you cannot reach more than megabyte with 16 bit program, you need
32 bit instrucion...
But as I said you cannot reach more then 4GB that way, and memtest
heapilly tests more then 4GB...
>
>

[James Harris]

No, worse. Your posts now appear on GG, too.

;-)


--
James Harris

[Rod Pemberton]

On Thu, 01 Jul 2021 00:51:39 GMT

Branimir Maksimovic <branimir....@gmail.com> wrote:

> On 2021-06-30, Rod Pemberton <noe...@basdxcqvbe.com> wrote:
> > On Tue, 29 Jun 2021 23:05:49 GMT
> > Branimir Maksimovic <branimir....@gmail.com> wrote:
> >> On 2021-06-28, Rod Pemberton <noe...@basdxcqvbe.com> wrote:
> >> > On Sun, 27 Jun 2021 15:17:43 GMT
> >> > Branimir Maksimovic <branimir....@gmail.com> wrote:
> >> >> On 2021-06-27, Rod Pemberton <noe...@basdxcqvbe.com> wrote:

> >> >> > IIRC, memtest86+ loads from DOS. So, it's likely 16-bit code
> >> >> > too, or possibly 32-bit if was compiled for DPMI. 32-bit
> >> >> > might not be too bad.
> >> >>
> >> >> memtest86 can test more then megabyte so I guess it is not 16
> >> >> bit...
> >> >
> >> > Aren't you familiar with "unreal" mode? ...
> >>
> >> Yes, but that is 32 bit, not 16 bit programs...
> >
> > No, unreal mode is generally 16-bit real-mode code. It's called
> > unreal mode because you have access to the entire memory range in
> > real-mode.
> >
> > As I understand it, 32-bit unreal mode is exceptionally difficult to
> > use due to an issue with interrupts. The only 32-bit unreal mode
> > example that I'm aware of is/was FASM.
>
> Look, you cannot reach more than megabyte with 16 bit program, you
> need 32 bit instrucion...

Sure you can. You'd only need a 16-bit mixed-mode x86 instructions
(386 or later). You can do that without use of unreal mode. I.e.
address-size (67h) override used within 16-bit code in a 16-bit code
segment, to allow for 32-bit addresses.

Please, read this section here, which describes both unreal and
mixed-mode addressing up to 4GB in 16-bit real-mode:
https://en.wikipedia.org/wiki/Unreal_mode#Enabling_unreal_mode

Please, look at the "address size" and "operand size" tables here near
the bottom, as this should help you understand what can and can't be
addressed in each processor mode both with and without overrides:
https://www.sandpile.org/x86/mode.htm

[Branimir Maksimovic]

Look I programmed DOS like that in early 90es.

>

[wolfgang kern]

On 01.07.2021 08:59, James Harris wrote:
[]
>>>> Curiously, your post shows up on Eternal September and AIOE but not
>>>> (yet) on Google Groups. Is that something you've chosen, e.g. with a
>>>> header setting?

>>> Could be; I'm nor a fan of GG, but I'm a bit vague on headers. Have I
>>> set X-No-Archive?
>>> I'll post this then check.

>> Better?

> No, worse. Your posts now appear on GG, too.
>
> ;-)

LMFAO
__
wolfgang