why operations with dtype np.int64 are much slower compared to same operations with np.int16?

Viewed 180

Here is what i mean - a is a vector of 1.000.000 np.int64 elements, b is a vector of 1.000.000 np.int16 elements:

In [19]: a = np.random.randint(100, size=(10**6), dtype="int64")

In [20]: b = np.random.randint(100, size=(10**6), dtype="int16")

timings for different operations:

In [23]: %timeit a + 1
4.48 ms ± 253 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [24]: %timeit b + 1
1.37 ms ± 14.3 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [25]: %timeit a / 10
5.77 ms ± 31.6 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [26]: %timeit b / 10
6.09 ms ± 70.9 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [27]: %timeit a * 10
4.52 ms ± 198 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [28]: %timeit b * 10
1.52 ms ± 12.6 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

I can understand such a difference when Numpy will have to create a new temporary result in memory - the underlying C code will have to copy / fill much more data in memory.

But I can't understand such difference for assigning values in place like the following:

In [21]: %timeit a[::2] = 111
409 µs ± 19 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [22]: %timeit b[::2] = 111
203 µs ± 112 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)

Do you have an idea why is it that slower even for those operations where Numpy doesn't have to create a copy / view?

1 Answers

Reading from memory costs something. Writing to memory costs something. You're reading four times as much data in, and writing four times as much data out, and the work is so much faster than the reads/writes to memory that it's effectively I/O bound. CPUs are just faster than memory (and the speed ratio has been getting more and more extreme over time); if you're doing memory-intensive work, smaller variables will go faster.

Related