(FWIW, the performance of the float32(i) call was essentially identical to
the performance of the hand code for loop equivalent in both Julia and
C++/clang. Stepping out to Intel SPMD (ispc) compiler to ensure maximum
vectorization only made it 20% faster. Nicely done!)
On Tuesday, October 21, 2014 10:36:42 PM UTC-4, Sebastian Good wrote:
>
> I created an array `i` of 500M 32-bit ints, then converted the whole array
> (into a new array) to float32s. The naive call to `float32(i)` ran at one
> speed, but map at quite another!
>
> julia> i = Int32[1:500000000];
>
> julia> @time float32(i);
> elapsed time: 1.669573141 seconds (2000000128 bytes allocated)
>
> julia> @time map(float32, i);
> elapsed time: 27.546797783 seconds (17999991952 bytes allocated, 25.93% gc
> time)
>
> From looking at the code in AbstractArray.jl it was executing, it would
> appear that it spends a lot of time doing type checking that it doesn't
> need to be doing, and presumably allocating memory as well. I'm not sure if
> this is a general problem that can be fixed with a more specialized method
> in AbstractArray, since we can't prove the map function has the right type
> as far as I understand Julia's type system.
>
> The guts of the map seem to call map_to!, which takes a "Callable" as its
> first argument.
>
> function map_to!{T}(f::Callable, offs, dest::AbstractArray{T}, A::
> AbstractArray)
>
> In an ideal world, it would take something more like the following, which
> would allow elimination of the run-time checks
>
> function map_to!{T,U}(f::Func{T,U}, offs, dest::AbstractArray{U}, A::
> AbstractArray{T})
>
> But this doesn't seem like something the type system is set up to prove.
> Am I on the wrong track? Is this something that is queued for development
> at a later stage?
>
>
