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.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
