Why is Vector{Float64} much faster than Vector{Float32}?

General Usage Performance
1

I have two programs that are almost identical except that in one program I used Float32 vectors or arrays while in the other one I used Float64. The Float64 program (named prog_f64.jl) is about 5x faster than the Float32 one (named proj_f32.jl). Does anybody know why such problem happens? You can see my programs here:
https://gist.github.com/jinliangwei/74d3871bebc1251b651cc6fd511fed08

Here is an input data file if you’d like to run the programs yourself: http://www.cs.cmu.edu/~jinlianw/data/ratings.csv

BTW, my Julia version is 0.6.2.

2

Sorry about the spam. Now I see why the problem happens. It’s basically caused by line 86 and line 87:
https://gist.github.com/jinliangwei/74d3871bebc1251b651cc6fd511fed08#file-proj_f32-jl-L86

alpha and 0.5 are of type Float64, so there were lots of type conversion.

3

Also, sqrt should be faster than ^0.5, and is generic with respect to Float types.

That being said, constants are always a pain for me when writing generic code that is supposed to work for Int16 / Int32 / Int64 or Float32 / Float64. I tend to get the needed type somewhere, e.g. using typeof, eltype or where or an explicit float_t parameter, and then have convert all over the place. This looks somewhat ugly and I am not sure how well this plays with autodiff, but I know no better way. Anyone else has better tips?

4

It would be possible to have a @literal_type T begin ... end macro that would rewrite an expression, converting all numeric literals to type, T. That would allow you to write your code with natural literal syntax and have them converted to the type of some type parameter.

1 Like
5

But not sure it can currently be used be runtime types. At least extending it to putting in the converts should be possible.

6

Converting only literals from x to T(x) is much easier than what ChangePrecision.jl currently does, so it should probably be a separate macro (but could be in the same package; PRs welcome).

1 Like