Rdm

Joined 24 August 2022
A note on Special:RecentChanges
(A note on Special:RecentChanges)
 
(5 intermediate revisions by the same user not shown)
Line 2:
 
<hr />
 
== Recent Changes ==
 
The reports on tasks not implemented in each language no longer function, after the miraheze migration. A crude workaround is to frequently poll the RecentChanges page and look there for task pages which have not been implemented in a language. But the [[Special:RecentChanges]] link from the site nave on the left has also gone missing. You can still find it with an extra hop into [[Special:SpecialPages]].
 
== big O ==
Line 15 ⟶ 19:
In the context of cache management and a relatively modern cpu design, the likelihood of a cache miss and the cost of a cache miss depends on the size of the data set.
 
LookingFor atestimates on a spec sheet for a relatively modern cpu architecture ([https://www.7-cpu.com/cpu/Haswell.html 2014-ish intel]), this looks like:<pre> Size Latency Increase Description
 
32 K 4
Line 38 ⟶ 42:
In other words, when working with a gigabyte of memory on that machine, a single instruction with a cache miss might cost the time of almost 1100 instructions to (in extreme cases) almost 8800 instructions.
 
Of course, the above simplifications focused purely on a single cpu architecture, and ignoringignored variations in memory architecture.
 
And there are other issues -- for example, when two different cores are accessing the same memory, that tends to introduce cache management conflicts which slow things down.
Line 44 ⟶ 48:
And then there's OS issues.
 
To simplify this further, though: code which accesses memory sequentially tends to have an order of magnitude speed advantage over code which accesses memory randomly. A rule of thumb here, <ulu>if you're not prepared to spend a lot of time benchmarking</ulu>, is that aan algorithmic performance advantage which is not at least a factor of 2 is probably a waste of time. (And, in some contexts -- especially where the underlying system was designed to solve a different problem -- factor of 1000 or greater performance improvements might be practical, for reasons independent of cache management.)
 
Meanwhile, the stuff we do here on rosettacode is pretty much just "dipping our toes in the water". Because of our focus on problems which can be solved by a variety of programmers in a variety of languages, we tend to favor problems which shy away from these performance extremes.
6,951

edits