Allocations (again...)

General Usage Performance
,
1

When I run

using BenchmarkTools

function test(x, Y)
    sum!(x, Y')
    return nothing
end

x = rand(Float64, 100)
Y = rand(Float64, 1, 100)
@btime(test(x, Y))

I get the following:

367.952 ns (2 allocations: 96 bytes)

I don’t think I should get any allocations. Can someone please explain what’s going on? And how can I avoid such allocations? (In my real application I have to do a similar computation millions of times.)

Thank you in advance.

1 Like
2

that’s quite nothing

julia> @btime test($x,$Y);
  372.976 ns (2 allocations: 96 bytes)
1 Like
3

Where and how is test() defined? We would need to know to tell where the allocations are coming from.

4

The code I have shown was fully typed on a .jl file

5

It’s a lot if you cycle it through tens of thousands of times

6

If you restart Julia and run that code you’ll see it error out. In the shown snippet you only define a two argument method, and then run one with zero arguments. Possibly you’ve defined that one before, and it contains something that allocates.

7

Sorry, I’ve pasted the wrong code. I’ll update it.

8

I have updated it and I still get 2 allocations

9

I think that Y' allocates (write a loop instead, for example).

3 Likes
10

What? When did that start? Adjoints have never allocated as far as I know.

Anyway:

julia> @btime test($x, $Y)
  124.499 ns (0 allocations: 0 bytes)

No allocations here, @aaraujo71

11

I do see the reported allocations in v1.8.2 under macos (arm)

julia> @btime(test($x, $Y))
  358.333 ns (2 allocations: 96 bytes)

EDIT: the issue is the adjoint. Without it, we’re back to zero allocations. I think it is indeed a bug.
EDIT2: no allocations on v1.8.1 on linux! 2 allocations in macos v1.9.0.alpha1

12

Zero allocations on 1.8.0 on Windows, that is with the adjoint.

13

And again 2 allocation in 1.8.3 under linux. It seems there is a regression that was introduced in 1.8.2 or 1.8.3

14

Opened an issue

1 Like
15

Thank you all. I am reprogramming may whole functions using loops.

16

It shouldn’t really be necessary. I mean, loops are fine, but it’s too bad to have to use them over clean simple function calls like sum!. This here seems like a spurious allocation, which will possibly be fixed in a patch release in not too long.