Norbert Hartl wrote:
Guido has a point on one front: slow machines can sometimes expose problems that might not otherwise be apparent. It could be as simple as highlighting inefficiency or as involved as changing the fraction of time the machine spends doing various things. Testing under extreme loads has value, and one way to create "load" is to (if only artificially) hobble a machine.
So you are doing it right, Bill. You say it "can" expose problems. That's true because you change the environmental parameters of the running program which has the potential to destabilize it. So you might identify a problem in that scale. What you don't get is an easy conclusion how this applies to your modern hardware. Assuming that all machines are equal and just move on the scale slow-fast is a bit naive. Only if you are like that you can compare an old computer with high load. Architectures change and the odds are high that you identified a problem which will never happen if you try it on a different hardware. There are optimizations that make things just faster. But a lot of optimizations are based on resource shortage. As much as these optimizations make a system more usable/reliable on a certain hardware generation as much they might destabilize the overall system. And some only bring you the gain in a single hardware generation.
As Igor pointed out above, a testbed is needed. It seems to me that similar situation to hobbling up a machine can appear if there is a lot of concurrent high-load applications running in parallel with Pharo (like 'node -e "for(;;){}"' run on each core). So maybe the question is how is Pharo behaving in such scenarios. On intel Core Duo+ / AMD Athlon 64 X2+. -- View this message in context: http://forum.world.st/Pharo-suffers-internal-Traffic-Jams-tp3995791p3998327.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.