It's the same as a flour sieve - a tool for seperating things of interest from other things.
Lumps from flour, primes from a collection of integers.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Mac plus, with a surprise:)
- Thread starter imactheknife
- Start date
Lumps from flour, primes from a collection of integers.
Oh yes, or a gold sieve as well for gold prospecting. Just wondered why something spelled “sieve” is pronounced “civ” and not “s-eye-e-vee” or something.
Anyway, I think that makes sense. The difference in the two scores between the two machines is probably due to some bottleneck somewhere, I’d surmise.
Anyway, I think that makes sense. The difference in the two scores between the two machines is probably due to some bottleneck somewhere, I’d surmise.
Don't we usually pan for gold rather than sieve?
Yeah, vague memories that the one most used for benchmarks is a variant on Erastosthenes but I may be wrong.
Think about it: asusme that the memory is running at the same speed as a stock Plus (which it is). If the calculations for the sieve can happen a lot in registers and don't involve many memory writes, it will be much faster than the dhrystone benchmark, which spends a lot of its time copying things back and forth from memory. That's a wild guess, but don't underestimate how importance memory bandwidth is.
It's a very old word, same root as 'to sift'. Looked it up in my eytmological dictionary here. In Middle English it's spelt 'sive' - so it's not the pronunciation that's weird, but more the spelling. Cognate words seem to appear in a lot of other Germanic languages, probably inherited from Proto-Indo-European - but the PIE root my dictionary gives here is impossible with modern accounts of PIE phonology, so I am guessing it's very out of date (unsurprising, the editor is known to rant about young people today, and I suspect has ignored the last twenty years or so of scholarship on this front).
Think about it: asusme that the memory is running at the same speed as a stock Plus (which it is). If the calculations for the sieve can happen a lot in registers and don't involve many memory writes, it will be much faster than the dhrystone benchmark, which spends a lot of its time copying things back and forth from memory. That's a wild guess, but don't underestimate how importance memory bandwidth is.
It's a very old word, same root as 'to sift'. Looked it up in my eytmological dictionary here. In Middle English it's spelt 'sive' - so it's not the pronunciation that's weird, but more the spelling. Cognate words seem to appear in a lot of other Germanic languages, probably inherited from Proto-Indo-European - but the PIE root my dictionary gives here is impossible with modern accounts of PIE phonology, so I am guessing it's very out of date (unsurprising, the editor is known to rant about young people today, and I suspect has ignored the last twenty years or so of scholarship on this front).
Remember how letters and syllables are said has changed a lot with time, especially the vowels.
I haven't googled the etymology of the word,
See above - it is Germanic, it's the spelling is weird rather than the pronunciation.
Yeah, I was just guessing badly.
Love how @Phipli and @cheesestraws are incredibly helpful in so many areas other than technology.
I can advise on waterwheel restoration and train fuel consumption if you ever need it
If anything, the Dhrystones is the anomaly. I think on my LCII I get just under 2000. Dhrystones copies text, but not much text as it runs quite happily on MCUs. Sieve scans through its entire array every time in steps of the next number, clearing each element: thus at the end, only elements containing '1's are primes. So, I would have thought that Sieve causes more cache invalidation.
But that might not be quite true. In the early Sieve iterations the step size might be smaller than the cache line size, so there will be more cache hits, but in later iterations there's lots of cache misses, but there are correspondingly far fewer loops, so that would dominate.
It's certainly to do with caches, because as we look down the Sieve list, there's a big 5x jump from 68000 to 680x0 machines, but there's only a 3x jump for Dhrystones. Then for the Iici it's only 65% faster for Sieve, but 94% faster for Dhrystones. Then with the IIfx it's about 3x faster for Sieve and 4x faster for Dhrystones.
So, conclusion: this Plus has slow 16-bit wide RAM. Dhrystones jumps about a lot, so the 68030 instruction cache gets invalidated a lot and when that happens it's a slow fetch. Hence Dhrystones isn't much faster. However, Sieve fits entirely within the instruction cache, so there's no speed penalty for the code. Also, there's not much of a data cache hit for Sieve either, because of the way iterations work as described in a previous paragraph.
I think this explains it.
The 32bit fast RAM makes a big difference. This isn't the same card, but is a 25MHz upgrade with RAM called "Current System".
On the other hand, "Upgraded Macintosh SE" is a 16MHz 030 upgrade (not a Bolle one) that doesn't have onboard RAM.
Applying some crude scaling, my 16MHz card is about 2.33 times faster than stock and my 25MHz card is 7 times faster than a stock SE. Scaling the 16MHz card to 25MHz, assuming it was that simple, the card with RAM is 1.92 times faster than an imaginary 25MHz card without RAM. It's not fully valid to compare like that, and in reality, the faster you go, the more you absolutely need the fast RAM or a big cache. Sort of interesting though.
This might be a somewhat relevant comparison. This is my Performer clone (On the left - 68030, 16mhz, w/ FPU, no SANE, 4mb ram on SE board) compared to my Total Systems Gemini (On the right - 68020, 16mhz, w/ FPU, no SANE, 4mb ram on accelerator). Ignore the benchmark names, I think I was really tired and typed "Mercury" instead of "Performer" thinking of another card, and my Quesse card is the same as the TS Gemini.
This isn't apples-to-apples since it's '020 vs '030, but you can see the '020 with ram on the accelerator is quite a bit faster at most of the individual math tests than the '030 using main board RAM. I am not sure why a couple of the math tests are so much faster with the '030, maybe there is something different about how the '020 and '030 handle those tests.
This isn't apples-to-apples since it's '020 vs '030, but you can see the '020 with ram on the accelerator is quite a bit faster at most of the individual math tests than the '030 using main board RAM. I am not sure why a couple of the math tests are so much faster with the '030, maybe there is something different about how the '020 and '030 handle those tests.
For interest - the 16MHz card I tested in my post was a Mercury (without the optional RAM card).
Which is in that state without the RAM is 100% identical to the Performer. Same schematics, same code in the GALs.
Interesting - so the RAM expansion is like the Performer with RAM?
Correct. I've got the schematics for the RAM board so 4MB of RAM could potentially be added to the Performer.
