Not that I know of. Hopefully someone else will chime in and prove me wrong.

Yes. Type the markings (S-Spec) in Google and usually the 1st link will tell you all about the chip.

Like this Intel 486DX4-100 SK096:
http://www.cpu-world.com/sspec/SK/SK096.html

Notes on sSpec SK096 […]
Show full quote

Notes on sSpec SK096

Core voltage range 3.3V - 3.6V
SL enhanced version.
Processor support write-back.
The processor requires 1x external clock.

kixs wrote:

Yes. Type the markings (S-Spec) in Google and usually the 1st link will tell you all about the chip. […]
Show full quote

Yes. Type the markings (S-Spec) in Google and usually the 1st link will tell you all about the chip.

Like this Intel 486DX4-100 SK096:
http://www.cpu-world.com/sspec/SK/SK096.html

Notes on sSpec SK096 […]
Show full quote

Notes on sSpec SK096

Core voltage range 3.3V - 3.6V
SL enhanced version.
Processor support write-back.
The processor requires 1x external clock.

Cool. Thanks. I have two DX2-66's. The first was easy. SX645. Write through and something called S-Spec, wich I have no clue on to what is.

The second chip, has a heatsink glued onto it, and I can not see the number because of that.
The gold-cap underneath is of same size as the write through. Hence I think it is a write through too.

If you can install it, there are programs that can identify s-spec (aida, chkcpu,...).

Ahh yes. I see. Thanks.
What about that "-S" in the cpu spec.
What is that?

You can try getting the heatsink off, however that usually rips off the label, but most of the time you can still see the text.

brostenen wrote:

Ahh yes. I see. Thanks.
What about that "-S" in the cpu spec.
What is that?

i believe that the "-S" means enhanced power management features.

If it is 486DX2-66 then only the P24D revision supports WB as well as CPU ID. So if it detects a generic 486 it is WT only.
Another way to see it is looking at the memory move vs read performance curve in speedsys:
Write Through:

Write Back:

As you see in WT mode the difference between L2 read to move (yellow/green) is identical to the difference for main memory.
In WB the L2 speed of move to read is closer while being farther apart in the main memory region.
In WB this difference is due to cache hits for write in the L2 region vs. Cache misses in the main memory region. Cache misses introduce additional latency compared to WT. In WT mode the latency for writes is the same for L2 and main memory.

Why this is not visible in the Write performance curve directly seems to be a secret of speedsys. Still this behavior gives you direct evidence of the caching strategy.

Nice, that's very helpful Elinda!

elianda wrote:

Why this is not visible in the Write performance curve directly seems to be a secret of speedsys. Still this behavior gives you direct evidence of the caching strategy.

Probably because writing is a fire-and-forget operation:
The CPU stores the data in the appropriate cacheline, and then it carries on with the next instruction. The cache will flush entire cachelines to memory in bursts in its own time in the background. So the CPU doesn't really notice the caching strategy here.
(In fact, with MMX there were special instructions to write data to memory immediately, and not store them in the cache. These were interesting for blitting operations for example, where you were not interested in caching the data you wrote. It didn't slow down the speed of writing, but it boosted cache hits for reading, since your cache didn't get polluted by data you weren't interested in).

With reads you can't do that, the CPU actually needs to wait for the data to become available from the cache. This is where different strategies may show: in certain situations, one strategy will have certain data already cached, while another won't. So an extra fetch is required.

Of course and I think it also depends a bit on what the graph should show. I can imagine that getting scores that show the difference in Cache hit/miss for writing are difficult to implement. It might be noticeable if you write consecutively in a situation where the cache writes slower than the CPU pushes data for cache hits and compare this to writes of cache misses.

For other CPUs, such as the Cyrix 486DLC or the NexGen Speedsys shows performance differences on write in the cache areas.

elianda wrote:

Of course and I think it also depends a bit on what the graph should show. I can imagine that getting scores that show the difference in Cache hit/miss for writing are difficult to implement. It might be noticeable if you write consecutively in a situation where the cache writes slower than the CPU pushes data for cache hits and compare this to writes of cache misses.

A write is always a cache-hit 😀
A cached CPU will write to cache first. Then the cache will decide when and how to write to memory.
That's the difference between write-through and write-back: Write-through will write to memory immediately. A very naive way of making sure cache and memory are synchronized.
Write-back will not write to memory until the cache line is evicted (least-recently-used). This means that if you repeatedly write to the same area of memory, and some/most of it fits into the cache, it will reduce the amount of memory that is actually written, since it eliminates redundant updates.
This is of course a more difficult strategy to implement, which is why it wasn't introduced until later versions of the 486.

If the benchmark just does linear patterns, then the caching strategies don't make a difference (probably what happens here). The only difference is that write-back will have more 'latency', as it won't start writing to memory until you've used up all your cache first.
If the benchmark does more complex patterns, where redundant writes could be eliminated by a write-back strategy, you might see differences.