vardump

Hmm... Copper, I guess it must be great for representing lists. :-)

This reminds me a bit of Amiga HAM. Similar horizontal fringing.

I guess you could also call Amiga's HAM graphics mode a compression method. Getting 12-bit (4096 colors) with just 6 input bits, with the original Amiga chipset, often called as "OCS".

Or later 262144 colors with 8 input bits, with the AGA chipset.

Heresy! 6502/6510 was the only true CPU back then!

(In other words, my daddy bought me a C64 in the eighties. ;-))

The average scalar (=integer) instructions per cycle is pretty comparable between Pentium III and Xtensa LX6, the original ESP32 CPU representing the worst case.

While P3 is superscalar, it could only execute about 0.9 instructions per cycle on average. Of course you can optimize for it and get better results in certain cases.

Most Xtensa scalar instructions take just 1 clock, branches 3 for taken, 1 for not taken. So 0.7-0.8 instructions per clock is a reasonable estimate. Assuming of course code is executing from SRAM.

Xtensa's FPU is slow, and it lacks divide and square root instructions. Clock for clock, P3 probably outperforms it by 3-4x. It also lacks 64-bit floats.

The compiler does not generate SIMD instructions on this platform. So they're not "normal" instructions in that sense.

Or perhaps you want to argue that everything is running "normal" instructions. Be it a hardware video decoder or a GPU.

That was reality in the eighties! You could open some cars using a popsicle stick as a key. Fun times!

Well, there's just one dictator involved, Putin. Trump is supporting him right now.

Ah, I could have sworn it's Copeland. Thanks for the correction.

Copeland... (That was the actual name of supposed future Apple's OS 30 years ago, sounds kinda different with 2026 perspective.)

That sounds right.

Although so far I'm mostly happy with Apple products. Happier than with any Windows laptops.

(But damn if I encounter a bug or an issue. Just reporting those have made hordes of Apple fans attack me, in response to a standard technical bug report.)

0-60 mph 0.81s.

According to Musk, 0.5 mach max speed.

He also said it can corner better than any car in the world due to massive downforce. And that it'll be in production in 2028.

We'll see.

The Musk we wish we had all the time: tech Musk.

If only he just stuck to tech.

Didn’t check agy or AI studio, but at least Argon is available in Gemini page/app.

Zero censorship? Who do you think you are kidding?

Fair enough. I agree there are many kinds of 4k demos.

The first thing a 4k demo is going to do is to decompress executable. The second thing is to procedurally generate assets. Perhaps also do some code generation. So the cache footprint is going to be larger.

At this point you can be talking about 600 kB on a DOS machine. Sky is the limit on modern systems.

That said, typical inner loops of that era demos were pretty small, usually 20-200 byte range, IIRC.

Pre-cache era demos often had huge unrolled self-modifying speedcode inner loops, but that's another matter.

Cycle accurate compared to what?

Even with a cycle accurate CPU you'd still have a lot of variation caused by the motherboard chipsets, DRAM speeds, cache chips and graphics cards.

Tseng ET4000 was on a completely different level than something like Cirrus Logic CL-GD510 or heaven forbid, Oak Technologies card.

If the era appropriate PCs had huge variations, what extra does cycle accuracy really bring at this point? The same PC demo could perform very differently on two 486DX2 66 MHz PCs.

Cycle accurate emulation helps little with this era PC demos, because back in 1993 PC hardware performance variation was already massive. From 386SX-16 to Pentium 66 MHz, that's over 20x difference in performance.

I did warm-up rounds, to prime caches and so on. I fiddled with statistics: IIRC simple average seemed to give the best results overall. I thought keeping the lowest n results would be the best, but that turned out to be wrong.

The results were indeed multimodal.

All I wanted was to have a reproducible benchmark to see how the code changes affected performance over time.

Did all of those trying to reduce the jitter. I think it was about the CPU clock not being stable.

Additionally I avoided core 0, because it was the noisiest and did some cgroups core pinning for the test workload.

There were zero page faults during the test runs and the CPU core was uncontested by other threads.

I think in 2008 CPUs were not so crazy about power and heat management.

Benchmarking like that is often broken because of continuous CPU core clock speed adjustments, system interrupts, SMIs, etc.

I tried to fix it by switching hyperthreading off, playing with the scaling governor, boost, setting a CPU frequency to no avail. The jitter was too much and the results were not reproducible, so I just gave up.

Of course your mileage may vary; this was on an AMD Zen 3 CPU.

You might be able to fix those "weird street-name issues" yourself in Google Maps.

I hope that was sarcasm.

This is not elitism, it's about historical accuracy. This is how many remember the games of their youth.

I wonder if same could be done to games. How much unnecessary work are modern games submitting to the GPU?

I wonder if our universe is the experiment to resolve this.

I just twisted my mouth sides upwards with my fingers to form a smile in agreement.

Thanks!

Can you share the prompt?

You certainly did not, as Win95 requires 32-bit, 80386 or better. 286 was a 16-bit CPU.