Of course that doesn't apply to games anymore but to high performance computing. Systems for gaming vary too much for that to be of any importance. Maybe if you are doing it for the consoles, but then you have to optimize each individually.
I was curious about this as I have never done any such testing, so I wrote a simple c program.
The object was a struct with a size of a typical game object( 100B ),
then I trashed the memory by doing a lot of malloc/free using the size of the object. The two tests were one with an array of objects( contiguous array ) and the other an array of pointers to objects which were allocated separately. Then I iterated over the object doing some very simple operation( just enough to access it, and identical for each object ) and timed this. And of course I trashed the memory some more for each time.
The time taken ratio is:
array of objects : array of pointers to objects
1 : 1.189
The second test is identical except I made some extra effort to make sure that every object in array of pointers was not adjacent to any previous one in memory:
array of objects : array of pointers to objects
1 : 2.483
The difference got much smaller once the operation on each object became more time consuming.
Frames per seconds is better in almost every way. When you use it to watch movies it is better since a normal human understands seconds but not what a frame is. In gaming, frame times usually vary quite a lot, and the average, which is fps, is the important part.
HN got really trigger happy in the last few weeks.
That part of the comment only is partially correct, and not was even the main point of my comment; what I really meant was that it doesn't belong in windows, and the main point was that the code is not portable.
This is why I don't like April F. Everything has to be rechecked/researched x times. The 60 minutes article is definitely not AF and I doubt my link is also.
Seriously, what are they waiting for. I'm not a teenager anymore, but If this was a serious app I would totally go catch a few, granted as a joke. And kids would go crazy over this, every single one already has the pokedex( smartphone ), that basically has all required capabilities.
I did a similar test in C and have gotten very similar results. When N is around 4000 the trashing version starts to differ substantially. A 3x difference can already be seen when N is 1000.
This means if your program is running on two threads over different parts of the matrix, every single iteration requires a request to RAM.
I'm skeptical over this part, I have tried to replicate this behavior but was unsuccessful. Even though cores are sharing L3, I doubt that a thread will overwrite the entire cache on every iteration.
This is exactly the reason they responded. By changing the code quietly, they would implicate themselves. An official PR statement like this is obligatory.
What is more probable, that they a lying, or that the random generator generated not a single code that matched, which is very(!) improbable by itself, but two codes that belong to the same account, generated at the same iteration.
According to this chart it really works: https://xkcd.com/678/