[rasz]

>In a PC or in other Quake ports, all the data is available from RAM (if not even from the CPU data cache), which had a relatively high bandwidth and low latency even back to 1996. In fact, the bandwidth for sequential reads varied a lot but with a 40 MHz EDO 64-bit DRAM (already available on 1996) one could get a maximum throughput of 320 MB/s.

The youth, so sweet and naive :) EDO ram on average Pentium motherboard does around 50-70MB/s. 256-1024KB of L2 cache bumps that to 70-120MB/s depending on chipset and cache type (and obviously usage pattern, Quake wasnt optimized on that aspect at all). Tiny 8KB of L1 below 200MB/s.

[smirutrandola]

I think that figure is of course referring to the peak bandwidth in burst mode, where you are sequentially access data (tacc = 25 ns), in the ideal case. In that sense, also the figure given for the Cortex M33 are to be taken as absolute maximum as well. 50-70 MB/s sounds representative of random read of 8 bytes blocks, where you have the full access time. This will go even lower if you just make byte-access.

Quake was indeed optimized to work on such 1996 Pentium PCs. Look for instance how the edge/surface/span arrays are allocated in the stack: they allocate extra size, to be sure that the data will be aligned to the cache line size.

[rasz]

50-70 MB/s is burst best case scenario linear read into nothing on contemporary 1996 chipsets/CPUs. Moving more or less halves that, writing is slightly faster than reading due to cache lookups.

320MB/s is even faster than theoretical maximum of EDO on Pentium platform. 8 bytes x 66MHz / 5-2-2-2 timings = <260MB/s burst.

Quake optimized for prefilling caches, but not for contemporary cache sizes. https://dependency-injection.com/2mb-cache-benchmarks/ Doom gains tiny amount when going from 256KB to 512KB, Quake linearly gains all the way to mindbogglingly absurd 2MB of L2. Could really benefit from data-oriented design, but there was no tooling for that at the time not to mention time crunch, Abrash did all he could under circumstances.

[smirutrandola]

I don't think the initial access time (latency) shall be included when speaking about peak bandwidth, otherwise it is not the peak bandwidth.

Peak bandwidth shall be considered with ideally infinite (large enough) payload to make latency negligible. When you have these two values, latency and peak bandwidth, you can estimate your (still theoretical, of course) performance given the transfer size.

The article uses the 240-320 MB/s peak bandwidth, and 110-130 ns latency for a comparison with the used external flash, which has latency in the us range and a peak bandwidth of 17 MB/s (arguably assuming using infinite payload, as 136.5/8 is about 17, i.e. without taking the initial setup time).

Still, even if you compare the actual speeds of a 1996 Pentium with the theoretical external flash speed values cited in the article, the consideration does not change: the external flash is much slower than what you could get even in 1996.

[rasz]

>I don't think the initial access time (latency) shall be included

Its not about the RAS. Bandwidth is bandwidth. When someone says

> In fact, the bandwidth for sequential reads varied a lot but with a 40 MHz EDO 64-bit DRAM (already available on 1996) one could get a maximum throughput of 320 MB/s

it tells me they multiplied 40MHz by 8 bytes and called it good. Thats not how EDO works. EDO still needs a CAS cycle for every new access, even linear. Its BEDO (Burst EDO) that has a 5-1-1-1 pattern.

https://www.electronics-notes.com/articles/electronic_compon...

https://dosdays.co.uk/topics/chipsets.php#VP1

    BEDO DRAM Read Timings (66MHz) 5-1-1-1
    EDO DRAM Read Timings (66MHz) 5-2-2-2
    FPM DRAM Read Timings (66MHz) 5-3-3-3
    SDRAM Read Timings (66MHz) 5-1-1-1

Absolute maximum _purely theoretical_ EDO burst bandwidth at 66MHz is <260MB/s. That doesnt take into account reality of 1996 hardware. Processors (Intel still hasnt acknowledged 'rep movsb' should be optimized), Chipsets and their Cache subsystems (cache on same bus as ram so no parallel accesses, lookup slows down reads). On real hardware 50-70 MB/s is all you get.

>The article uses the 240-320 MB/s

Article states "1996) one could get a maximum throughput of 320 MB/s" which is ~5x higher than reality. Im not arguing the achievement realized here is somehow lesser because of this mistake. Im pointing out assumptions about vintage hardware were incorrectly inflated. In fact those assumptions might have led to lower expectations and worse outcome. Usually learning something is possible with less is a strong catalyst to try until you get there. Great example of this effect while still staying on topic, Video7 FIFO story told by Abrash https://www.bluesnews.com/abrash/chap64.shtml

Abrash: "push past the limits he had unconsciously set in coming up with his original design. And, in the end, I think that the single most important element of great design, whether it be hardware or software or any creative endeavor, is precisely what the Paradise news triggered in Tom: The ability to detect the limits you have built into the way you think about your design, and transcend those limits."

[smirutrandola]

Upvoted as you have convinced me with your solid refs.

I don't see possibility of commenting on the link I posted (silabs community), but on the detailed blog one can leave comments. I will post a there a link to this conversation, asking to address the issue and we'll see what they say.