On Mi, 2016-06-29 at 02:03 -0700, Nathaniel Smith wrote:
> As a general rule I wouldn't worry too much about test speed. Speed
> is
> extremely dependent on exact workloads. And this is doubly so for
> test
> suites -- production workloads tend to do a small number of normal
> things over and over,
As a general rule I wouldn't worry too much about test speed. Speed is
extremely dependent on exact workloads. And this is doubly so for test
suites -- production workloads tend to do a small number of normal
things over and over, while a good test suite never does the same
thing twice and spends m
On Wed, Jun 29, 2016 at 3:27 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
>
>
>> Now the user is writing back to say, "my test code is fast now, but
>> numpy.test() is still about three times slower than > don't manage>". When I watch htop as numpy.test() executes, sure enough,
> Now the user is writing back to say, "my test code is fast now, but
> numpy.test() is still about three times slower than don't manage>". When I watch htop as numpy.test() executes, sure enough,
> it's using one core
>
* if numpy.test() is supposed to be using multiple cores, why isn't it,
> w
On Tue, Jun 28, 2016 at 10:36 PM, Michael Ward wrote:
> Heya, I'm not a numbers guy, but I maintain servers for scientists and
> researchers who are. Someone pointed out that our numpy installation on a
> particular server was only using one core. I'm unaware of the who/how the
> previous versi
Heya, I'm not a numbers guy, but I maintain servers for scientists and
researchers who are. Someone pointed out that our numpy installation on
a particular server was only using one core. I'm unaware of the who/how
the previous version of numpy/OpenBLAS were installed, so I installed
them fro