Re: [julia-users] Re: Design patterns for an API

[Mike Innes]

Although it's worth pointing out the overhead is only present when using 
the scope workaround; if you're in an inner loop and the <1μs overhead is 
non-negligible (it seems unlikely that this would actually be a bottleneck, 
but who knows) you could just use my original macro. Overall I'm not 
convinced that the macro solution is worse unless you specifically want to 
simulate higher-order functions (which you do, of course, so fair enough).

On Sunday, 18 May 2014 07:24:38 UTC+1, Mike Innes wrote:
>
> Fair point. I timed this in a loop and it seems to be about an order of 
> magnitude slower, which (considering that you're redefining the function 
> every time it runs) is actually surprisingly good – it seems that doing so 
> only takes a microsecond.
>
> On Saturday, 17 May 2014 21:20:34 UTC+1, Tim Holy wrote:
>>
>> Right, but there are still issues with this approach. Are you planning on 
>> always executing this "function" as a macro? If so, then you'll have to 
>> pay 
>> the compilation price each time you use it. You might not care if xs is 
>> huge, 
>> but if xs has 10 items then you won't be very happy. 
>>
>> The performance of the dict-based method cache is not ideal in such 
>> circumstances either, but it's about three orders of magnitude faster: 
>>
>> julia> y = rand(10); 
>>
>> julia> @time @sumf exp y 
>> elapsed time: 0.01007613 seconds (131500 bytes allocated) 
>> 19.427283165919906 
>>
>> julia> @time @sumf exp y 
>> elapsed time: 0.011217276 seconds (131500 bytes allocated) 
>> 19.427283165919906 
>>
>> In contrast, 
>>
>> julia> @time sumf(:exp, y) 
>> elapsed time: 0.014134811 seconds (94888 bytes allocated) 
>> 19.427283165919906 
>>
>> julia> @time sumf(:exp, y) 
>> elapsed time: 1.0356e-5 seconds (64 bytes allocated) 
>> 19.427283165919906 
>>
>> Three orders of magnitude is enough of a speed difference to notice :). 
>>
>> --Tim 
>>
>>
>> On Saturday, May 17, 2014 09:31:29 AM Mike Innes wrote: 
>> > That macro being slow at the top level isn't really a strike against 
>> the 
>> > macro technique, because it's easily resolved: 
>> > 
>> > (Although oddly enough, a let binding doesn't really help here – anyone 
>> > know why?) 
>> > 
>> > macro sumf(f, xs) 
>> >   quote 
>> > function inner(s = 0.0, x = $(esc(xs))) 
>> >   for i = 1:length(x) 
>> > s += $(esc(f))(x[i]) 
>> >   end 
>> >   s 
>> > end 
>> > inner() 
>> >   end 
>> > end 
>> > 
>> > Although you're right that if you call this from a function which 
>> itself 
>> > takes f as a parameter, you'll lose the speed boost again (technically 
>> you 
>> > could resolve this by making the calling function a macro in the same 
>> way, 
>> > but that's equally awful). 
>> > 
>> > Hopefully this kind of inlining will be automatic soon, so we won't 
>> have to 
>> > resort to ugly language hacks to make things fast; on the other hand, 
>> it's 
>> > kinda cool that we *can* resort to ugly language hacks to make things 
>> fast 
>> > 
>> > :) 
>> > 
>> > On Saturday, 17 May 2014 16:18:15 UTC+1, Tim Holy wrote: 
>> > > If you want to make that fast, you need to wrap that inside a 
>> function, 
>> > > using 
>> > > a separate name for each user-supplied f. Example: 
>> > > 
>> > > function sumf_with_sinc_plus_x(xs) 
>> > > 
>> > > @sumf(sinc_plus_x, xs) 
>> > > 
>> > > end 
>> > > 
>> > > function sumf_with_exp(xs) 
>> > > 
>> > > @sumf(exp, xs) 
>> > > 
>> > > end 
>> > > 
>> > > If you don't wrap it in a function, then it runs in global scope, and 
>> > > that's 
>> > > horribly slow. 
>> > > 
>> > > My version allows you to pass a function as an argument, and mimics 
>> what 
>> > > it 
>> > > would be like if we could pass functions-as-arguments without a 
>> > > performance 
>> > > penalty. 
>> > > 
>> > > --Tim 
>> > > 
>> > > On Saturday, May 17, 2014 05:03:07 AM Mike Innes wrote: 
>> > > > I may be missing the point here, but wouldn't it be easier to 
>> define 
>> > > 
>> > > sumf 
>> > > 
>> > > > as a macro? 
>> > > > 
>> > > > macro sumf(f, xs) 
>> > > > 
>> > > >   quote 
>> > > >   
>> > > > s = 0.0 
>> > > > x = $(esc(xs)) 
>> > > > for i = 1:length(x) 
>> > > > 
>> > > >   s += $(esc(f))(x[i]) 
>> > > > 
>> > > > end 
>> > > > s 
>> > > >   
>> > > >   end 
>> > > > 
>> > > > end 
>> > > > 
>> > > > @sumf(sinc_plus_x, x) 
>> > > > 
>> > > > This is just as fast and has the advantage that it will work when f 
>> is 
>> > > 
>> > > only 
>> > > 
>> > > > in the local scope. 
>> > > > 
>> > > > On Saturday, 17 May 2014 11:50:56 UTC+1, Tim Holy wrote: 
>> > > > > On Friday, May 16, 2014 02:36:03 PM francoi...@gmail.com 
>> > > 
>> > > wrote: 
>> > > > > > - The solver need to be fast and for that, inlining is of 
>> paramount 
>> > > > > > importance. I know that there is no way to inline F for the 
>> time 
>> > > 
>> > > being. 
>> > > 
>> > > > > Do 
>> > > > > 
>> > > > > > we expect inlining on function argument in the near future of 
>> Jul

Re: [julia-users] fill! with copies

[Carlos Becker]

Thanks all, those look like neat solutions.


--
Carlos


On Fri, May 16, 2014 at 11:36 PM, Stefan Karpinski wrote:

> When you write fill!(arr, ChannVals()) you are asking to fill arr with
> the one value that is the result of evaluating ChannVals() once. Doing
> anything else would be bizarre. We could have a version of fill! that takes
> a thunk so you could write
>
> fill!(arr) do
>   ChannVals()
> end
>
>
> That would have the desired effect as well, but it seems to me that using
> a comprehension is just as easy in that case.
>
>
> On Fri, May 16, 2014 at 4:21 PM, Ivar Nesje  wrote:
>
>> @Jameson They are immutable, but they contain references to mutable
>> arrays, and all the immutable types will reference the same arrays. That
>> way you would not just need a copy but a deepcopy. That will probably be
>> too much overhead for fill!(), and will be problematic if someone decided
>> to fill! an array with some large structure.
>>
>> On the other hand, I think it would be reasonable for fill! to take a
>> shallow copy of mutable types. Not sure what others think on that subject
>> though.
>>
>> Ivar
>>
>> kl. 17:01:56 UTC+2 fredag 16. mai 2014 skrev Jameson følgende:
>>>
>>> Since they are immutable, fill! did exactly what you wanted
>>>
>>> On Friday, May 16, 2014, Tim Holy  wrote:
>>>
 Try

 arr = [ChannVals() for i = 1:10]

 On Friday, May 16, 2014 01:27:18 AM Carlos Becker wrote:
 > Hello all,
 >
 > I wanted to create an array of an immutable type and initialize an
 empty
 > copy in each (with the default constructor).
 > I am wondering which is the best way to do it, so far:
 >
 >immutable ChannVals
 > taus::Vector{Float64}
 > alphas::Vector{Float64}
 >
 > ChannVals() = new( Float64[], Float64[] )
 >end
 >
 ># create 10 new instances
 >arr = ChannVals[ChannVals() for i=1:10]
 >
 >
 > Now, a neat but incorrect way is to do
 >
 >arr = Array( ChannVals, 10 )
 >fill!(allVals, ChannVals())
 >
 > because it will fill them with the same instance.
 > Is there a neat way, such as a fillwithcopies!() ?
 >
 >
 > Cheers.

>>>
>

[julia-users] tanh() speed / multi-threading

[Carlos Becker]

This is probably related to openblas, but it seems to be that tanh() is not 
multi-threaded, which hinders a considerable speed improvement.
For example, MATLAB does multi-thread it and gets something around 3x 
speed-up over the single-threaded version.

For example,

  x = rand(10,200);
  @time y = tanh(x);

yields:
  - 0.71 sec in Julia
  - 0.76 sec in matlab with -singleCompThread
  - and 0.09 sec in Matlab (this one uses multi-threading by default)

Good news is that julia (w/openblas) is competitive with matlab 
single-threaded version,
though setting the env variable OPENBLAS_NUM_THREADS doesn't have any 
effect on the timings, nor I see higher CPU usage with 'top'.

Is there an override for OPENBLAS_NUM_THREADS in julia? what am I missing?

[julia-users] Re: tanh() speed / multi-threading

[Carlos Becker]

forgot to add versioninfo():

julia> versioninfo()
Julia Version 0.3.0-prerelease+2921
Commit ea70e4d* (2014-05-07 17:56 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm


El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker escribió:
>
> This is probably related to openblas, but it seems to be that tanh() is 
> not multi-threaded, which hinders a considerable speed improvement.
> For example, MATLAB does multi-thread it and gets something around 3x 
> speed-up over the single-threaded version.
>
> For example,
>
>   x = rand(10,200);
>   @time y = tanh(x);
>
> yields:
>   - 0.71 sec in Julia
>   - 0.76 sec in matlab with -singleCompThread
>   - and 0.09 sec in Matlab (this one uses multi-threading by default)
>
> Good news is that julia (w/openblas) is competitive with matlab 
> single-threaded version,
> though setting the env variable OPENBLAS_NUM_THREADS doesn't have any 
> effect on the timings, nor I see higher CPU usage with 'top'.
>
> Is there an override for OPENBLAS_NUM_THREADS in julia? what am I missing?
>

[julia-users] Re: tanh() speed / multi-threading

[Carlos Becker]

now that I think about it, maybe openblas has nothing to do here, since 
@which tanh(y) leads to a call to vectorize_1arg().

If that's the case, wouldn't it be advantageous to have a 
vectorize_1arg_openmp() function (defined in C/C++) that works for 
element-wise operations on scalar arrays,
multi-threading with OpenMP?


El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:
>
> forgot to add versioninfo():
>
> julia> versioninfo()
> Julia Version 0.3.0-prerelease+2921
> Commit ea70e4d* (2014-05-07 17:56 UTC)
> Platform Info:
>   System: Linux (x86_64-linux-gnu)
>   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>
>
> El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker escribió:
>>
>> This is probably related to openblas, but it seems to be that tanh() is 
>> not multi-threaded, which hinders a considerable speed improvement.
>> For example, MATLAB does multi-thread it and gets something around 3x 
>> speed-up over the single-threaded version.
>>
>> For example,
>>
>>   x = rand(10,200);
>>   @time y = tanh(x);
>>
>> yields:
>>   - 0.71 sec in Julia
>>   - 0.76 sec in matlab with -singleCompThread
>>   - and 0.09 sec in Matlab (this one uses multi-threading by default)
>>
>> Good news is that julia (w/openblas) is competitive with matlab 
>> single-threaded version,
>> though setting the env variable OPENBLAS_NUM_THREADS doesn't have any 
>> effect on the timings, nor I see higher CPU usage with 'top'.
>>
>> Is there an override for OPENBLAS_NUM_THREADS in julia? what am I missing?
>>
>

Re: [julia-users] Help Understanding an InexactError() in Code Sample

[Milan Bouchet-Valat]

Le samedi 17 mai 2014 à 20:56 -0700, z...@rescale.com a écrit :
> Sorry  I missed a line when transcribing the code snippet in my
> message.  The while loop should read:
> 
Please provide the complete code and check it's working before posting.
After replacing the loop in the rest of the code, I got an error about
REARTH not being defined.

That said, the problem is simply that in htab[k], k is not a integer
value. Julia tries to convert k to an integer, and fails. I'm not sure
what you intended to do, but a non-integer index doesn't make sense to
me. :-)


Regards

[julia-users] Re: tanh() speed / multi-threading

[Tobias Knopp]

Hi Carlos,

I am working on something that will allow to do multithreading on Julia 
functions (https://github.com/JuliaLang/julia/pull/6741). Implementing 
vectorize_1arg_openmp is actually a lot less trivial as the Julia runtime 
is not thread safe (yet)

Your example is great. I first got a slowdown of 10 because the example 
revealed a locking issue. With a little trick I now get a speedup of 1.75 
on a 2 core machine. Not to bad taking into account that memory allocation 
cannot be parallelized.

The tweaked code looks like

function tanh_core(x,y,i)

N=length(x)

for l=1:N/2

  y[l+i*N/2] = tanh(x[l+i*N/2])

end

end


function ptanh(x;numthreads=2)

y = similar(x)

N = length(x)

parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)

y

end


I actually want this to be also fast for


function tanh_core(x,y,i)

y[i] = tanh(x[i])

end


function ptanh(x;numthreads=2)

y = similar(x)

N = length(x)

parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)

y

end

Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>
> now that I think about it, maybe openblas has nothing to do here, since 
> @which tanh(y) leads to a call to vectorize_1arg().
>
> If that's the case, wouldn't it be advantageous to have a 
> vectorize_1arg_openmp() function (defined in C/C++) that works for 
> element-wise operations on scalar arrays,
> multi-threading with OpenMP?
>
>
> El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:
>>
>> forgot to add versioninfo():
>>
>> julia> versioninfo()
>> Julia Version 0.3.0-prerelease+2921
>> Commit ea70e4d* (2014-05-07 17:56 UTC)
>> Platform Info:
>>   System: Linux (x86_64-linux-gnu)
>>   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>   LAPACK: libopenblas
>>   LIBM: libopenlibm
>>
>>
>> El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker escribió:
>>>
>>> This is probably related to openblas, but it seems to be that tanh() is 
>>> not multi-threaded, which hinders a considerable speed improvement.
>>> For example, MATLAB does multi-thread it and gets something around 3x 
>>> speed-up over the single-threaded version.
>>>
>>> For example,
>>>
>>>   x = rand(10,200);
>>>   @time y = tanh(x);
>>>
>>> yields:
>>>   - 0.71 sec in Julia
>>>   - 0.76 sec in matlab with -singleCompThread
>>>   - and 0.09 sec in Matlab (this one uses multi-threading by default)
>>>
>>> Good news is that julia (w/openblas) is competitive with matlab 
>>> single-threaded version,
>>> though setting the env variable OPENBLAS_NUM_THREADS doesn't have any 
>>> effect on the timings, nor I see higher CPU usage with 'top'.
>>>
>>> Is there an override for OPENBLAS_NUM_THREADS in julia? what am I 
>>> missing?
>>>
>>

Re: [julia-users] Re: tanh() speed / multi-threading

[Carlos Becker]

HI Tobias, I saw your pull request and have been following it closely, nice
work ;)

Though, in the case of element-wise matrix operations, like tanh, there is
no need for extra allocations, since the buffer should be allocated only
once.

>From your first code snippet, is julia smart enough to pre-compute i*N/2 ?
In such cases, creating a kind of array view on the original data would
probably be faster, right? (though I don't know how allocations work here).

For vectorize_1arg_openmp, I was thinking of "hard-coding" it for known
operations such as trigonometric ones, that benefit a lot from
multi-threading.
I know this is a hack, but it is quick to implement and brings an amazing
speed up (8x in the case of the code I posted above).




--
Carlos


On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp
wrote:

> Hi Carlos,
>
> I am working on something that will allow to do multithreading on Julia
> functions (https://github.com/JuliaLang/julia/pull/6741). Implementing
> vectorize_1arg_openmp is actually a lot less trivial as the Julia runtime
> is not thread safe (yet)
>
> Your example is great. I first got a slowdown of 10 because the example
> revealed a locking issue. With a little trick I now get a speedup of 1.75
> on a 2 core machine. Not to bad taking into account that memory allocation
> cannot be parallelized.
>
> The tweaked code looks like
>
> function tanh_core(x,y,i)
>
> N=length(x)
>
> for l=1:N/2
>
>   y[l+i*N/2] = tanh(x[l+i*N/2])
>
> end
>
> end
>
>
> function ptanh(x;numthreads=2)
>
> y = similar(x)
>
> N = length(x)
>
> parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)
>
> y
>
> end
>
>
> I actually want this to be also fast for
>
>
> function tanh_core(x,y,i)
>
> y[i] = tanh(x[i])
>
> end
>
>
> function ptanh(x;numthreads=2)
>
> y = similar(x)
>
> N = length(x)
>
> parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)
>
> y
>
> end
>
> Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>
>> now that I think about it, maybe openblas has nothing to do here, since
>> @which tanh(y) leads to a call to vectorize_1arg().
>>
>> If that's the case, wouldn't it be advantageous to have a
>> vectorize_1arg_openmp() function (defined in C/C++) that works for
>> element-wise operations on scalar arrays,
>> multi-threading with OpenMP?
>>
>>
>> El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:
>>>
>>> forgot to add versioninfo():
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.0-prerelease+2921
>>> Commit ea70e4d* (2014-05-07 17:56 UTC)
>>> Platform Info:
>>>   System: Linux (x86_64-linux-gnu)
>>>   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>>   LAPACK: libopenblas
>>>   LIBM: libopenlibm
>>>
>>>
>>> El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker escribió:

 This is probably related to openblas, but it seems to be that tanh() is
 not multi-threaded, which hinders a considerable speed improvement.
 For example, MATLAB does multi-thread it and gets something around 3x
 speed-up over the single-threaded version.

 For example,

   x = rand(10,200);
   @time y = tanh(x);

 yields:
   - 0.71 sec in Julia
   - 0.76 sec in matlab with -singleCompThread
   - and 0.09 sec in Matlab (this one uses multi-threading by default)

 Good news is that julia (w/openblas) is competitive with matlab
 single-threaded version,
 though setting the env variable OPENBLAS_NUM_THREADS doesn't have any
 effect on the timings, nor I see higher CPU usage with 'top'.

 Is there an override for OPENBLAS_NUM_THREADS in julia? what am I
 missing?

>>>

Re: [julia-users] sizehint for new array

[Tim Holy]

On Saturday, May 17, 2014 02:04:49 PM Andrew Dabrowski wrote:
> But is it wrong to use it the way I suggested?

Not wrong, but whether it buys you anything depends on what comes next. The 
sizehint takes effect after the call to f(oldarray) returns, and it doesn't 
affect f at all. However, if the next thing you do with newarray is to grow it, 
then the sizehint might be useful.

Best,
--Tim


> On Saturday, May 17, 2014 4:27:19 PM UTC-4, Tim Holy wrote:
> > I use it right after creating an array that I'm going to be modifying with
> > push!:
> > 
> > a = Array(Int, 0)
> > sizehint(a, 10^5)
> > 
> > Now I'll be able to push! at least 10^5 elements without it having to re-
> > allocate and copy the data I've already added.
> > 
> > --Tim
> > 
> > On Saturday, May 17, 2014 09:29:49 AM Andrew Dabrowski wrote:
> > > What's the proper way to use sizehint when defining a new array?  Is it
> > > 
> > > newarray = sizehint( f( oldarray ), n ),
> > > 
> > > or do you have to already have the new variable defined before using
> > > sizehint?

[julia-users] Proof of concept: hydrodynamics in julia!

[Joonas Nättilä]

Hi all,

After some twiddling and debugging I can finally announce the first alpha 
version of (what I suspect to be the first) hydrodynamics code written in 
julia:

http://github.com/natj/hydro 

There are still quite a lot of things to do like parallelization but even 
currently it is capable of running a 100x100 grid with reasonable speed 
live. The original python code I based this on, was able to maintain 
approximately the same speed in 1 dimension but we are already doing 
computations in 2d!

One of my design goals was to make this as modular and flexible as possible 
so that it could be used a as basis for more complex calculations. Due to 
this it should be relatively straightforward to upgrade it to for example 
to magnetohydrodynamics or to shallow water equations. Also, now that I 
have the initial frame done, I plan to begin a heavy testing and 
optimization period so all comments, tips and improvements are welcome! 

I also computed some eye-candy for you that you can amaze here 
https://vimeo.com/95607699


Cheers,
Joonas

[julia-users] Re: Proof of concept: hydrodynamics in julia!

[Mike Innes]

This is really cool! Thanks for sharing it, especially with the video.

You might be interested in packaging this 
up– 
it doesn't have to be officially registered or anything, but just putting 
everything into a module would mean that people can download it and try out 
some fluid dynamics really easily.

On Sunday, 18 May 2014 12:41:43 UTC+1, Joonas Nättilä wrote:
>
> Hi all,
>
> After some twiddling and debugging I can finally announce the first alpha 
> version of (what I suspect to be the first) hydrodynamics code written in 
> julia:
>
> http://github.com/natj/hydro 
>
> There are still quite a lot of things to do like parallelization but even 
> currently it is capable of running a 100x100 grid with reasonable speed 
> live. The original python code I based this on, was able to maintain 
> approximately the same speed in 1 dimension but we are already doing 
> computations in 2d!
>
> One of my design goals was to make this as modular and flexible as 
> possible so that it could be used a as basis for more complex calculations. 
> Due to this it should be relatively straightforward to upgrade it to for 
> example to magnetohydrodynamics or to shallow water equations. Also, now 
> that I have the initial frame done, I plan to begin a heavy testing and 
> optimization period so all comments, tips and improvements are welcome! 
>
> I also computed some eye-candy for you that you can amaze here 
> https://vimeo.com/95607699
>
>
> Cheers,
> Joonas
>

Re: [julia-users] Re: tanh() speed / multi-threading

[Carlos Becker]

btw, the code you just sent works as is with your pull request branch?


--
Carlos


On Sun, May 18, 2014 at 1:04 PM, Carlos Becker wrote:

> HI Tobias, I saw your pull request and have been following it closely,
> nice work ;)
>
> Though, in the case of element-wise matrix operations, like tanh, there is
> no need for extra allocations, since the buffer should be allocated only
> once.
>
> From your first code snippet, is julia smart enough to pre-compute i*N/2 ?
> In such cases, creating a kind of array view on the original data would
> probably be faster, right? (though I don't know how allocations work here).
>
> For vectorize_1arg_openmp, I was thinking of "hard-coding" it for known
> operations such as trigonometric ones, that benefit a lot from
> multi-threading.
> I know this is a hack, but it is quick to implement and brings an amazing
> speed up (8x in the case of the code I posted above).
>
>
>
>
> --
> Carlos
>
>
> On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp <
> tobias.kn...@googlemail.com> wrote:
>
>> Hi Carlos,
>>
>> I am working on something that will allow to do multithreading on Julia
>> functions (https://github.com/JuliaLang/julia/pull/6741). Implementing
>> vectorize_1arg_openmp is actually a lot less trivial as the Julia runtime
>> is not thread safe (yet)
>>
>> Your example is great. I first got a slowdown of 10 because the example
>> revealed a locking issue. With a little trick I now get a speedup of 1.75
>> on a 2 core machine. Not to bad taking into account that memory allocation
>> cannot be parallelized.
>>
>> The tweaked code looks like
>>
>> function tanh_core(x,y,i)
>>
>> N=length(x)
>>
>> for l=1:N/2
>>
>>   y[l+i*N/2] = tanh(x[l+i*N/2])
>>
>> end
>>
>> end
>>
>>
>> function ptanh(x;numthreads=2)
>>
>> y = similar(x)
>>
>> N = length(x)
>>
>> parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)
>>
>> y
>>
>> end
>>
>>
>> I actually want this to be also fast for
>>
>>
>> function tanh_core(x,y,i)
>>
>> y[i] = tanh(x[i])
>>
>> end
>>
>>
>> function ptanh(x;numthreads=2)
>>
>> y = similar(x)
>>
>> N = length(x)
>>
>> parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)
>>
>> y
>>
>> end
>>
>> Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>>
>>> now that I think about it, maybe openblas has nothing to do here, since
>>> @which tanh(y) leads to a call to vectorize_1arg().
>>>
>>> If that's the case, wouldn't it be advantageous to have a
>>> vectorize_1arg_openmp() function (defined in C/C++) that works for
>>> element-wise operations on scalar arrays,
>>> multi-threading with OpenMP?
>>>
>>>
>>> El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:

 forgot to add versioninfo():

 julia> versioninfo()
 Julia Version 0.3.0-prerelease+2921
 Commit ea70e4d* (2014-05-07 17:56 UTC)
 Platform Info:
   System: Linux (x86_64-linux-gnu)
   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
   WORD_SIZE: 64
   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
   LAPACK: libopenblas
   LIBM: libopenlibm


 El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker escribió:
>
> This is probably related to openblas, but it seems to be that tanh()
> is not multi-threaded, which hinders a considerable speed improvement.
> For example, MATLAB does multi-thread it and gets something around 3x
> speed-up over the single-threaded version.
>
> For example,
>
>   x = rand(10,200);
>   @time y = tanh(x);
>
> yields:
>   - 0.71 sec in Julia
>   - 0.76 sec in matlab with -singleCompThread
>   - and 0.09 sec in Matlab (this one uses multi-threading by default)
>
> Good news is that julia (w/openblas) is competitive with matlab
> single-threaded version,
> though setting the env variable OPENBLAS_NUM_THREADS doesn't have any
> effect on the timings, nor I see higher CPU usage with 'top'.
>
> Is there an override for OPENBLAS_NUM_THREADS in julia? what am I
> missing?
>

>

Re: [julia-users] GSOC 3D Visualizations plotting API - Make a wish!

[Andreas Lobinger]

Hello colleague,

just as i read it

On Saturday, May 17, 2014 10:23:49 PM UTC+2, Tim Holy wrote:
>
> Also, really fast 2d plotting of large datasets would not be a bad thing. 
> Cairo + Gtk is not bad (and Gtk is quite a lot better than Tk in terms of 
> speed), but it's also not all that impressive either. 
>

Could you quantify? afaics my times for (from Cairo/test/shape_functions) 
lines1-4 on a 1024x1024 bitmap are roughly

julia> @time(lines1(c,1024.0,1024.0,1.0,10))
elapsed time: 36.95827684 seconds (4000368 bytes allocated)

julia> @time(lines2(c,1024.0,1024.0,1.0,10))
elapsed time: 3.365150476 seconds (4126836 bytes allocated)

julia> @time(lines3(c,1024.0,1024.0,1.0,10))
elapsed time: 1.091252869 seconds (4000368 bytes allocated)

julia> @time(lines4(c,1024.0,1024.0,1.0,10))
elapsed time: 5.748033081 seconds (4185816 bytes allocated)

and drawing 10 lines antialiased in around 1s is not so bad.

And i do not see a good reason, why Winston e.g should be slower.

Re: [julia-users] Re: tanh() speed / multi-threading

[Tobias Knopp]

sure, the function is Base.parapply though. I had explicitly imported it.

In the case of vectorize_1arg it would be great to automatically 
parallelize comprehensions. If someone could tell me where the actual 
looping happens, this would be great. I have not found that yet. Seems to 
be somewhere in the parser.

Am Sonntag, 18. Mai 2014 14:30:49 UTC+2 schrieb Carlos Becker:
>
> btw, the code you just sent works as is with your pull request branch?
>
>
> --
> Carlos
>  
>
> On Sun, May 18, 2014 at 1:04 PM, Carlos Becker 
> 
> > wrote:
>
>> HI Tobias, I saw your pull request and have been following it closely, 
>> nice work ;)
>>
>> Though, in the case of element-wise matrix operations, like tanh, there 
>> is no need for extra allocations, since the buffer should be allocated only 
>> once.
>>
>> From your first code snippet, is julia smart enough to pre-compute i*N/2 ?
>> In such cases, creating a kind of array view on the original data would 
>> probably be faster, right? (though I don't know how allocations work here).
>>
>> For vectorize_1arg_openmp, I was thinking of "hard-coding" it for known 
>> operations such as trigonometric ones, that benefit a lot from 
>> multi-threading.
>> I know this is a hack, but it is quick to implement and brings an amazing 
>> speed up (8x in the case of the code I posted above).
>>
>>
>>
>>
>> --
>> Carlos
>>  
>>
>> On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp 
>> 
>> > wrote:
>>
>>> Hi Carlos,
>>>
>>> I am working on something that will allow to do multithreading on Julia 
>>> functions (https://github.com/JuliaLang/julia/pull/6741). Implementing 
>>> vectorize_1arg_openmp is actually a lot less trivial as the Julia runtime 
>>> is not thread safe (yet)
>>>
>>> Your example is great. I first got a slowdown of 10 because the example 
>>> revealed a locking issue. With a little trick I now get a speedup of 1.75 
>>> on a 2 core machine. Not to bad taking into account that memory allocation 
>>> cannot be parallelized.
>>>
>>> The tweaked code looks like
>>>
>>> function tanh_core(x,y,i)
>>>
>>> N=length(x)
>>>
>>> for l=1:N/2
>>>
>>>   y[l+i*N/2] = tanh(x[l+i*N/2])
>>>
>>> end
>>>
>>> end
>>>
>>>
>>> function ptanh(x;numthreads=2)
>>>
>>> y = similar(x)
>>>
>>> N = length(x)
>>>
>>> parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)
>>>
>>> y
>>>
>>> end
>>>
>>>
>>> I actually want this to be also fast for
>>>
>>>
>>> function tanh_core(x,y,i)
>>>
>>> y[i] = tanh(x[i])
>>>
>>> end
>>>
>>>
>>> function ptanh(x;numthreads=2)
>>>
>>> y = similar(x)
>>>
>>> N = length(x)
>>>
>>> parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)
>>>
>>> y
>>>
>>> end
>>>
>>> Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>>>
 now that I think about it, maybe openblas has nothing to do here, since 
 @which tanh(y) leads to a call to vectorize_1arg().

 If that's the case, wouldn't it be advantageous to have a 
 vectorize_1arg_openmp() function (defined in C/C++) that works for 
 element-wise operations on scalar arrays,
 multi-threading with OpenMP?


 El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:
>
> forgot to add versioninfo():
>
> julia> versioninfo()
> Julia Version 0.3.0-prerelease+2921
> Commit ea70e4d* (2014-05-07 17:56 UTC)
> Platform Info:
>   System: Linux (x86_64-linux-gnu)
>   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>
>
> El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker escribió:
>>
>> This is probably related to openblas, but it seems to be that tanh() 
>> is not multi-threaded, which hinders a considerable speed improvement.
>> For example, MATLAB does multi-thread it and gets something around 3x 
>> speed-up over the single-threaded version.
>>
>> For example,
>>
>>   x = rand(10,200);
>>   @time y = tanh(x);
>>
>> yields:
>>   - 0.71 sec in Julia
>>   - 0.76 sec in matlab with -singleCompThread
>>   - and 0.09 sec in Matlab (this one uses multi-threading by default)
>>
>> Good news is that julia (w/openblas) is competitive with matlab 
>> single-threaded version,
>> though setting the env variable OPENBLAS_NUM_THREADS doesn't have 
>> any effect on the timings, nor I see higher CPU usage with 'top'.
>>
>> Is there an override for OPENBLAS_NUM_THREADS in julia? what am I 
>> missing?
>>
>
>>  
>

Re: [julia-users] GSOC 3D Visualizations plotting API - Make a wish!

[Tobias Knopp]

It starts to get interesting if you want to have a 2D online display where 
data is colorized and you want to apply filter operations that can easily 
done on the GPU. Interesting but IMHO basic 3D graphics is more important 
at this stage.

Am Sonntag, 18. Mai 2014 16:02:10 UTC+2 schrieb Andreas Lobinger:
>
> Hello colleague,
>
> just as i read it
>
> On Saturday, May 17, 2014 10:23:49 PM UTC+2, Tim Holy wrote:
>>
>> Also, really fast 2d plotting of large datasets would not be a bad thing. 
>> Cairo + Gtk is not bad (and Gtk is quite a lot better than Tk in terms of 
>> speed), but it's also not all that impressive either. 
>>
>
> Could you quantify? afaics my times for (from Cairo/test/shape_functions) 
> lines1-4 on a 1024x1024 bitmap are roughly
>
> julia> @time(lines1(c,1024.0,1024.0,1.0,10))
> elapsed time: 36.95827684 seconds (4000368 bytes allocated)
>
> julia> @time(lines2(c,1024.0,1024.0,1.0,10))
> elapsed time: 3.365150476 seconds (4126836 bytes allocated)
>
> julia> @time(lines3(c,1024.0,1024.0,1.0,10))
> elapsed time: 1.091252869 seconds (4000368 bytes allocated)
>
> julia> @time(lines4(c,1024.0,1024.0,1.0,10))
> elapsed time: 5.748033081 seconds (4185816 bytes allocated)
>
> and drawing 10 lines antialiased in around 1s is not so bad.
>
> And i do not see a good reason, why Winston e.g should be slower.
>
>
>

Re: [julia-users] Re: tanh() speed / multi-threading

[Carlos Becker]

Sounds great!
I just gave it a try, and with 16 threads I get 0.07sec which is impressive.

That is when I tried it in isolated code. When put together with other
julia code I have, it segfaults. Have you experienced this as well?
 Le 18 mai 2014 16:05, "Tobias Knopp"  a
écrit :

> sure, the function is Base.parapply though. I had explicitly imported it.
>
> In the case of vectorize_1arg it would be great to automatically
> parallelize comprehensions. If someone could tell me where the actual
> looping happens, this would be great. I have not found that yet. Seems to
> be somewhere in the parser.
>
> Am Sonntag, 18. Mai 2014 14:30:49 UTC+2 schrieb Carlos Becker:
>>
>> btw, the code you just sent works as is with your pull request branch?
>>
>>
>> --
>> Carlos
>>
>>
>> On Sun, May 18, 2014 at 1:04 PM, Carlos Becker wrote:
>>
>>> HI Tobias, I saw your pull request and have been following it closely,
>>> nice work ;)
>>>
>>> Though, in the case of element-wise matrix operations, like tanh, there
>>> is no need for extra allocations, since the buffer should be allocated only
>>> once.
>>>
>>> From your first code snippet, is julia smart enough to pre-compute i*N/2
>>> ?
>>> In such cases, creating a kind of array view on the original data would
>>> probably be faster, right? (though I don't know how allocations work here).
>>>
>>> For vectorize_1arg_openmp, I was thinking of "hard-coding" it for known
>>> operations such as trigonometric ones, that benefit a lot from
>>> multi-threading.
>>> I know this is a hack, but it is quick to implement and brings an
>>> amazing speed up (8x in the case of the code I posted above).
>>>
>>>
>>>
>>>
>>> --
>>> Carlos
>>>
>>>
>>> On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp >> > wrote:
>>>
 Hi Carlos,

 I am working on something that will allow to do multithreading on Julia
 functions (https://github.com/JuliaLang/julia/pull/6741). Implementing
 vectorize_1arg_openmp is actually a lot less trivial as the Julia runtime
 is not thread safe (yet)

 Your example is great. I first got a slowdown of 10 because the example
 revealed a locking issue. With a little trick I now get a speedup of 1.75
 on a 2 core machine. Not to bad taking into account that memory allocation
 cannot be parallelized.

 The tweaked code looks like

 function tanh_core(x,y,i)

 N=length(x)

 for l=1:N/2

   y[l+i*N/2] = tanh(x[l+i*N/2])

 end

 end


 function ptanh(x;numthreads=2)

 y = similar(x)

 N = length(x)

 parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)

 y

 end


 I actually want this to be also fast for


 function tanh_core(x,y,i)

 y[i] = tanh(x[i])

 end


 function ptanh(x;numthreads=2)

 y = similar(x)

 N = length(x)

 parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)

 y

 end

 Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:

> now that I think about it, maybe openblas has nothing to do here,
> since @which tanh(y) leads to a call to vectorize_1arg().
>
> If that's the case, wouldn't it be advantageous to have a
> vectorize_1arg_openmp() function (defined in C/C++) that works for
> element-wise operations on scalar arrays,
> multi-threading with OpenMP?
>
>
> El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:
>>
>> forgot to add versioninfo():
>>
>> julia> versioninfo()
>> Julia Version 0.3.0-prerelease+2921
>> Commit ea70e4d* (2014-05-07 17:56 UTC)
>> Platform Info:
>>   System: Linux (x86_64-linux-gnu)
>>   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>   LAPACK: libopenblas
>>   LIBM: libopenlibm
>>
>>
>> El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker escribió:
>>>
>>> This is probably related to openblas, but it seems to be that tanh()
>>> is not multi-threaded, which hinders a considerable speed improvement.
>>> For example, MATLAB does multi-thread it and gets something around
>>> 3x speed-up over the single-threaded version.
>>>
>>> For example,
>>>
>>>   x = rand(10,200);
>>>   @time y = tanh(x);
>>>
>>> yields:
>>>   - 0.71 sec in Julia
>>>   - 0.76 sec in matlab with -singleCompThread
>>>   - and 0.09 sec in Matlab (this one uses multi-threading by default)
>>>
>>> Good news is that julia (w/openblas) is competitive with matlab
>>> single-threaded version,
>>> though setting the env variable OPENBLAS_NUM_THREADS doesn't have
>>> any effect on the timings, nor I

Re: [julia-users] Re: tanh() speed / multi-threading

[Tobias Knopp]

Well when I started I got segfaullt all the time :-)

Could you please send me a minimal code example that segfaults? This would 
be great! This is the only way we can get this stable.

Am Sonntag, 18. Mai 2014 16:35:47 UTC+2 schrieb Carlos Becker:
>
> Sounds great!
> I just gave it a try, and with 16 threads I get 0.07sec which is 
> impressive.
>
> That is when I tried it in isolated code. When put together with other 
> julia code I have, it segfaults. Have you experienced this as well?
>  Le 18 mai 2014 16:05, "Tobias Knopp" > 
> a écrit :
>
>> sure, the function is Base.parapply though. I had explicitly imported it.
>>
>> In the case of vectorize_1arg it would be great to automatically 
>> parallelize comprehensions. If someone could tell me where the actual 
>> looping happens, this would be great. I have not found that yet. Seems to 
>> be somewhere in the parser.
>>
>> Am Sonntag, 18. Mai 2014 14:30:49 UTC+2 schrieb Carlos Becker:
>>>
>>> btw, the code you just sent works as is with your pull request branch?
>>>
>>>
>>> --
>>> Carlos
>>>  
>>>
>>> On Sun, May 18, 2014 at 1:04 PM, Carlos Becker wrote:
>>>
 HI Tobias, I saw your pull request and have been following it closely, 
 nice work ;)

 Though, in the case of element-wise matrix operations, like tanh, there 
 is no need for extra allocations, since the buffer should be allocated 
 only 
 once.

 From your first code snippet, is julia smart enough to pre-compute 
 i*N/2 ?
 In such cases, creating a kind of array view on the original data would 
 probably be faster, right? (though I don't know how allocations work here).

 For vectorize_1arg_openmp, I was thinking of "hard-coding" it for 
 known operations such as trigonometric ones, that benefit a lot from 
 multi-threading.
 I know this is a hack, but it is quick to implement and brings an 
 amazing speed up (8x in the case of the code I posted above).




 --
 Carlos
  

 On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp <
 tobias...@googlemail.com> wrote:

> Hi Carlos,
>
> I am working on something that will allow to do multithreading on 
> Julia functions (https://github.com/JuliaLang/julia/pull/6741). 
> Implementing vectorize_1arg_openmp is actually a lot less trivial as the 
> Julia runtime is not thread safe (yet)
>
> Your example is great. I first got a slowdown of 10 because the 
> example revealed a locking issue. With a little trick I now get a speedup 
> of 1.75 on a 2 core machine. Not to bad taking into account that memory 
> allocation cannot be parallelized.
>
> The tweaked code looks like
>
> function tanh_core(x,y,i)
>
> N=length(x)
>
> for l=1:N/2
>
>   y[l+i*N/2] = tanh(x[l+i*N/2])
>
> end
>
> end
>
>
> function ptanh(x;numthreads=2)
>
> y = similar(x)
>
> N = length(x)
>
> parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)
>
> y
>
> end
>
>
> I actually want this to be also fast for
>
>
> function tanh_core(x,y,i)
>
> y[i] = tanh(x[i])
>
> end
>
>
> function ptanh(x;numthreads=2)
>
> y = similar(x)
>
> N = length(x)
>
> parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)
>
> y
>
> end
>
> Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>
>> now that I think about it, maybe openblas has nothing to do here, 
>> since @which tanh(y) leads to a call to vectorize_1arg().
>>
>> If that's the case, wouldn't it be advantageous to have a 
>> vectorize_1arg_openmp() function (defined in C/C++) that works for 
>> element-wise operations on scalar arrays,
>> multi-threading with OpenMP?
>>
>>
>> El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:
>>>
>>> forgot to add versioninfo():
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.0-prerelease+2921
>>> Commit ea70e4d* (2014-05-07 17:56 UTC)
>>> Platform Info:
>>>   System: Linux (x86_64-linux-gnu)
>>>   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>>   LAPACK: libopenblas
>>>   LIBM: libopenlibm
>>>
>>>
>>> El domingo, 18 de mayo de 2014 11:33:45 UTC+2, Carlos Becker 
>>> escribió:

 This is probably related to openblas, but it seems to be that 
 tanh() is not multi-threaded, which hinders a considerable speed 
 improvement.
 For example, MATLAB does multi-thread it and gets something around 
 3x speed-up over the single-threaded version.

 For

Re: [julia-users] Re: tanh() speed / multi-threading

[Andreas Noack Jensen]

The computation of `tanh` is done in openlibm, not openblas, and it is not
multithreaded.  Probably, MATLAB uses Intel's Vectorized Mathematical
Functions (VML) in MKL. If you have MKL you can do that yourself. It makes
a big difference as you also saw in MATLAB. With openlibm I get

julia> @time y = tanh(x);
elapsed time: 1.229392453 seconds (16096 bytes allocated)

and with VML I get

julia> @time (ymkl=similar(x);ccall((:vdtanh_,Base.libblas_name), Void,
(Ptr{Int}, Ptr{Float64}, Ptr{Float64}), &length(x), x, ymkl))
elapsed time: 0.086282489 seconds (16112 bytes allocated)

It appears that we can get something similar with Tobias' work, which is
cool.


2014-05-18 16:35 GMT+02:00 Carlos Becker :

> Sounds great!
> I just gave it a try, and with 16 threads I get 0.07sec which is
> impressive.
>
> That is when I tried it in isolated code. When put together with other
> julia code I have, it segfaults. Have you experienced this as well?
>  Le 18 mai 2014 16:05, "Tobias Knopp"  a
> écrit :
>
> sure, the function is Base.parapply though. I had explicitly imported it.
>>
>> In the case of vectorize_1arg it would be great to automatically
>> parallelize comprehensions. If someone could tell me where the actual
>> looping happens, this would be great. I have not found that yet. Seems to
>> be somewhere in the parser.
>>
>> Am Sonntag, 18. Mai 2014 14:30:49 UTC+2 schrieb Carlos Becker:
>>>
>>> btw, the code you just sent works as is with your pull request branch?
>>>
>>>
>>> --
>>> Carlos
>>>
>>>
>>> On Sun, May 18, 2014 at 1:04 PM, Carlos Becker wrote:
>>>
 HI Tobias, I saw your pull request and have been following it closely,
 nice work ;)

 Though, in the case of element-wise matrix operations, like tanh, there
 is no need for extra allocations, since the buffer should be allocated only
 once.

 From your first code snippet, is julia smart enough to pre-compute
 i*N/2 ?
 In such cases, creating a kind of array view on the original data would
 probably be faster, right? (though I don't know how allocations work here).

 For vectorize_1arg_openmp, I was thinking of "hard-coding" it for
 known operations such as trigonometric ones, that benefit a lot from
 multi-threading.
 I know this is a hack, but it is quick to implement and brings an
 amazing speed up (8x in the case of the code I posted above).




 --
 Carlos


 On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp <
 tobias...@googlemail.com> wrote:

> Hi Carlos,
>
> I am working on something that will allow to do multithreading on
> Julia functions (https://github.com/JuliaLang/julia/pull/6741).
> Implementing vectorize_1arg_openmp is actually a lot less trivial as the
> Julia runtime is not thread safe (yet)
>
> Your example is great. I first got a slowdown of 10 because the
> example revealed a locking issue. With a little trick I now get a speedup
> of 1.75 on a 2 core machine. Not to bad taking into account that memory
> allocation cannot be parallelized.
>
> The tweaked code looks like
>
> function tanh_core(x,y,i)
>
> N=length(x)
>
> for l=1:N/2
>
>   y[l+i*N/2] = tanh(x[l+i*N/2])
>
> end
>
> end
>
>
> function ptanh(x;numthreads=2)
>
> y = similar(x)
>
> N = length(x)
>
> parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)
>
> y
>
> end
>
>
> I actually want this to be also fast for
>
>
> function tanh_core(x,y,i)
>
> y[i] = tanh(x[i])
>
> end
>
>
> function ptanh(x;numthreads=2)
>
> y = similar(x)
>
> N = length(x)
>
> parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)
>
> y
>
> end
>
> Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>
>> now that I think about it, maybe openblas has nothing to do here,
>> since @which tanh(y) leads to a call to vectorize_1arg().
>>
>> If that's the case, wouldn't it be advantageous to have a
>> vectorize_1arg_openmp() function (defined in C/C++) that works for
>> element-wise operations on scalar arrays,
>> multi-threading with OpenMP?
>>
>>
>> El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker escribió:
>>>
>>> forgot to add versioninfo():
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.0-prerelease+2921
>>> Commit ea70e4d* (2014-05-07 17:56 UTC)
>>> Platform Info:
>>>   System: Linux (x86_64-linux-gnu)
>>>   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>>   LAPACK: libopenblas
>>>   LIBM: libopenlibm
>

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Simon Danisch]

Well it's probably no bad performance for a CPU based rendering system.
But with my crappy Intel GPU on fullscreen(1920x1200) and anti-aliased, I 
can draw 10,000,000 3D lines in ~ 0.02 seconds, which makes 1 second for 
100,000 lines look reeally slow.
Even 100,000,000 still offers near real time performance on my GPU.
(If someone wonders, this is OpenGL performance with my prototype)

I totally forgot:
If you've have a concrete project, like visualizing volumetric data, it 
would be wonderful if you can supply me with an example datasets, so that 
I've something to play around with.

Best,
Simon

[julia-users] Call julia.bat under Windows 8.1

[Günter Faes]

Dear Community,

Sorry if this question was already asked, I'm a real julia novice! I 
installed the version "julia-0.2.1-win64.exe" and tried the first steps in 
Windows 8.1 environment with Julia but I got the following error message 
(DOS box: C:\WINDOWS\system32\cmd.exe):

Fatal: error throw and no exception handler available.
Base.SystemError(prefix="mkdir", errnum::Int32)
Drücken (... is not important, it's German   ... ;-)  )

 Can a tip someone give me, what went wrong?

Thank's and regards from 
Germany
!
Guenter

Re: [julia-users] Re: tanh() speed / multi-threading

[Tobias Knopp]

And I am pretty excited that it seems to scale so well at your setup. I 
have only 2 cores so could not see if it scales to more cores.

Am Sonntag, 18. Mai 2014 16:40:18 UTC+2 schrieb Tobias Knopp:
>
> Well when I started I got segfaullt all the time :-)
>
> Could you please send me a minimal code example that segfaults? This would 
> be great! This is the only way we can get this stable.
>
> Am Sonntag, 18. Mai 2014 16:35:47 UTC+2 schrieb Carlos Becker:
>>
>> Sounds great!
>> I just gave it a try, and with 16 threads I get 0.07sec which is 
>> impressive.
>>
>> That is when I tried it in isolated code. When put together with other 
>> julia code I have, it segfaults. Have you experienced this as well?
>>  Le 18 mai 2014 16:05, "Tobias Knopp"  a 
>> écrit :
>>
>>> sure, the function is Base.parapply though. I had explicitly imported it.
>>>
>>> In the case of vectorize_1arg it would be great to automatically 
>>> parallelize comprehensions. If someone could tell me where the actual 
>>> looping happens, this would be great. I have not found that yet. Seems to 
>>> be somewhere in the parser.
>>>
>>> Am Sonntag, 18. Mai 2014 14:30:49 UTC+2 schrieb Carlos Becker:

 btw, the code you just sent works as is with your pull request branch?


 --
 Carlos
  

 On Sun, May 18, 2014 at 1:04 PM, Carlos Becker wrote:

> HI Tobias, I saw your pull request and have been following it closely, 
> nice work ;)
>
> Though, in the case of element-wise matrix operations, like tanh, 
> there is no need for extra allocations, since the buffer should be 
> allocated only once.
>
> From your first code snippet, is julia smart enough to pre-compute 
> i*N/2 ?
> In such cases, creating a kind of array view on the original data 
> would probably be faster, right? (though I don't know how allocations 
> work 
> here).
>
> For vectorize_1arg_openmp, I was thinking of "hard-coding" it for 
> known operations such as trigonometric ones, that benefit a lot from 
> multi-threading.
> I know this is a hack, but it is quick to implement and brings an 
> amazing speed up (8x in the case of the code I posted above).
>
>
>
>
> --
> Carlos
>  
>
> On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp <
> tobias...@googlemail.com> wrote:
>
>> Hi Carlos,
>>
>> I am working on something that will allow to do multithreading on 
>> Julia functions (https://github.com/JuliaLang/julia/pull/6741). 
>> Implementing vectorize_1arg_openmp is actually a lot less trivial as the 
>> Julia runtime is not thread safe (yet)
>>
>> Your example is great. I first got a slowdown of 10 because the 
>> example revealed a locking issue. With a little trick I now get a 
>> speedup 
>> of 1.75 on a 2 core machine. Not to bad taking into account that memory 
>> allocation cannot be parallelized.
>>
>> The tweaked code looks like
>>
>> function tanh_core(x,y,i)
>>
>> N=length(x)
>>
>> for l=1:N/2
>>
>>   y[l+i*N/2] = tanh(x[l+i*N/2])
>>
>> end
>>
>> end
>>
>>
>> function ptanh(x;numthreads=2)
>>
>> y = similar(x)
>>
>> N = length(x)
>>
>> parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)
>>
>> y
>>
>> end
>>
>>
>> I actually want this to be also fast for
>>
>>
>> function tanh_core(x,y,i)
>>
>> y[i] = tanh(x[i])
>>
>> end
>>
>>
>> function ptanh(x;numthreads=2)
>>
>> y = similar(x)
>>
>> N = length(x)
>>
>> parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)
>>
>> y
>>
>> end
>>
>> Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>>
>>> now that I think about it, maybe openblas has nothing to do here, 
>>> since @which tanh(y) leads to a call to vectorize_1arg().
>>>
>>> If that's the case, wouldn't it be advantageous to have a 
>>> vectorize_1arg_openmp() function (defined in C/C++) that works for 
>>> element-wise operations on scalar arrays,
>>> multi-threading with OpenMP?
>>>
>>>
>>> El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker 
>>> escribió:

 forgot to add versioninfo():

 julia> versioninfo()
 Julia Version 0.3.0-prerelease+2921
 Commit ea70e4d* (2014-05-07 17:56 UTC)
 Platform Info:
   System: Linux (x86_64-linux-gnu)
   CPU: Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
   WORD_SIZE: 64
   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
   LAPACK: libopenblas
   LIBM: libopenlibm


 El domingo, 18 de mayo de 2014

Re: [julia-users] GSOC 3D Visualizations plotting API - Make a wish!

[Tim Holy]

Pour yourself a nice cup of tea and start reading here:
https://groups.google.com/d/msg/julia-users/4pT81kO1jDE/dRvWbqYhJH8J
https://github.com/nolta/Winston.jl/issues/89

--Tim

On Sunday, May 18, 2014 07:02:10 AM Andreas Lobinger wrote:
> Hello colleague,
> 
> just as i read it
> 
> On Saturday, May 17, 2014 10:23:49 PM UTC+2, Tim Holy wrote:
> > Also, really fast 2d plotting of large datasets would not be a bad thing.
> > Cairo + Gtk is not bad (and Gtk is quite a lot better than Tk in terms of
> > speed), but it's also not all that impressive either.
> 
> Could you quantify? afaics my times for (from Cairo/test/shape_functions)
> lines1-4 on a 1024x1024 bitmap are roughly
> 
> julia> @time(lines1(c,1024.0,1024.0,1.0,10))
> elapsed time: 36.95827684 seconds (4000368 bytes allocated)
> 
> julia> @time(lines2(c,1024.0,1024.0,1.0,10))
> elapsed time: 3.365150476 seconds (4126836 bytes allocated)
> 
> julia> @time(lines3(c,1024.0,1024.0,1.0,10))
> elapsed time: 1.091252869 seconds (4000368 bytes allocated)
> 
> julia> @time(lines4(c,1024.0,1024.0,1.0,10))
> elapsed time: 5.748033081 seconds (4185816 bytes allocated)
> 
> and drawing 10 lines antialiased in around 1s is not so bad.
> 
> And i do not see a good reason, why Winston e.g should be slower.

Re: [julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Tim Holy]

That's the kind of performance I think we should be aiming for :). Struggling 
to match Matlab seems rather yesteryear.

Re volumetric data: when I've been playing around with such things, I 
generally find it helpful to start with synthetic examples, because I _know_ 
what those are supposed to look like. There's one example in 
ImageView/test/test4d.jl. You can look at it in ImageView to get a sense of 
what each slice looks like, and then use that array as an input to your volume 
renderer(s). See the README for instructions 
(https://github.com/timholy/ImageView.jl, starting about halfway down the 
page.)

When you need some real volumetric data, I can send you some of that, too. Of 
course the datasets are large, certainly too large to send by email. Send me a 
note off-list when you want it.

--Tim

On Sunday, May 18, 2014 07:48:54 AM Simon Danisch wrote:
> Well it's probably no bad performance for a CPU based rendering system.
> But with my crappy Intel GPU on fullscreen(1920x1200) and anti-aliased, I
> can draw 10,000,000 3D lines in ~ 0.02 seconds, which makes 1 second for
> 100,000 lines look reeally slow.
> Even 100,000,000 still offers near real time performance on my GPU.
> (If someone wonders, this is OpenGL performance with my prototype)
> 
> I totally forgot:
> If you've have a concrete project, like visualizing volumetric data, it
> would be wonderful if you can supply me with an example datasets, so that
> I've something to play around with.
> 
> Best,
> Simon

Re: [julia-users] Help Understanding an InexactError() in Code Sample

[zach]

I've inluded the entire code as attachments per Milan's request.

Thanks!

enc



On Sunday, May 18, 2014 3:28:14 AM UTC-7, Milan Bouchet-Valat wrote:
>
>  Le samedi 17 mai 2014 à 20:56 -0700, za...@rescale.com  a 
> écrit : 
>
> Sorry  I missed a line when transcribing the code snippet in my message. 
>  The while loop should read: 
>
> Please provide the complete code and check it's working before posting. 
> After replacing the loop in the rest of the code, I got an error about 
> REARTH not being defined.
>
> That said, the problem is simply that in htab[k], k is not a integer 
> value. Julia tries to convert k to an integer, and fails. I'm not sure what 
> you intended to do, but a non-integer index doesn't make sense to me. :-)
>
>
> Regards 
>  


atmos.jl
Description: Binary data


constants.jl
Description: Binary data


main.jl
Description: Binary data

[julia-users] Re: Proof of concept: hydrodynamics in julia!

[Joonas Nättilä]

Yeah, I intend to wrap this into a package once I get all the testing and 
major refactors done. First I also have to come up with a proper name, too. 
Sadly there seems to be no famous researchers named Julia in the field, 
whose last name I could have stolen for this. I was thinking Toro or Bull 
after the famous Eleuterio Toro, almost a father like figure in the field, 
but naming it to a Bull does not really reflect the modular and lightweight 
nature of this! Maybe I just be lame and use the current Hydro.jl, tho.


On Sunday, 18 May 2014 15:15:04 UTC+3, Mike Innes wrote:
>
> This is really cool! Thanks for sharing it, especially with the video.
>
> You might be interested in packaging this 
> up– 
> it doesn't have to be officially registered or anything, but just putting 
> everything into a module would mean that people can download it and try out 
> some fluid dynamics really easily.
>
> On Sunday, 18 May 2014 12:41:43 UTC+1, Joonas Nättilä wrote:
>>
>> Hi all,
>>
>> After some twiddling and debugging I can finally announce the first alpha 
>> version of (what I suspect to be the first) hydrodynamics code written in 
>> julia:
>>
>> http://github.com/natj/hydro 
>>
>> There are still quite a lot of things to do like parallelization but even 
>> currently it is capable of running a 100x100 grid with reasonable speed 
>> live. The original python code I based this on, was able to maintain 
>> approximately the same speed in 1 dimension but we are already doing 
>> computations in 2d!
>>
>> One of my design goals was to make this as modular and flexible as 
>> possible so that it could be used a as basis for more complex calculations. 
>> Due to this it should be relatively straightforward to upgrade it to for 
>> example to magnetohydrodynamics or to shallow water equations. Also, now 
>> that I have the initial frame done, I plan to begin a heavy testing and 
>> optimization period so all comments, tips and improvements are welcome! 
>>
>> I also computed some eye-candy for you that you can amaze here 
>> https://vimeo.com/95607699
>>
>>
>> Cheers,
>> Joonas
>>
>

Re: [julia-users] DataFrame (2 questions)

[John Myles White]

> On my retina display it often times uses less than half of terminal window 
> width.

Are you expanding the window after starting Julia? We’re using the same 
machinery as Base Julia to determine the window width, which doesn’t adjust 
dynamically.

 — John

On May 17, 2014, at 3:04 PM, Rob J. Goedman  wrote:

> Thanks John,
> 
> On May 17, 2014, at 11:57 AM, John Myles White  
> wrote:
> 
>> In (1), you’re trying to put to insert multiple columns into a single 
>> column, which means that you’re effectively inserting a column with 6 
>> entries instead of 3. The error message should probably be changed to note 
>> that the size (rather than the length) is wrong. We could change the formula 
>> interface at some point to allow “.” as an operator.
> 
> Clearly what I was trying to do was wrong and for readability it is probably 
> better to be explicit with respect to column names in generating the df and 
> model formula.
> 
>> Point (2) is intentional. There are a lot of options that control printing 
>> of DataFrames and they need to be exposed better in the documentation. 
>> They’re documented here for now: 
>> https://github.com/JuliaStats/DataFrames.jl/blob/master/spec/show.md
>> 
>> The printing decision doesn’t depend on the structure of the DataFrame. It 
>> only depends on whether or not the DataFrame could be printed to the screen 
>> without spillover.
> 
> Will study the specs. On my retina display it often times uses less than half 
> of terminal window width. But show(..., true) and showall(...) give me 
> exactly what I was looking for!
> 
> Thanks again, regards,
> Rob J. Goedman
> goed...@icloud.com
> 
> 

[julia-users] GSOC 3D Visualizations plotting API - Make a wish!

[gael . mcdon]

High quality and low complexity vector graphics.

By high quality I mean clear, nice and customizable.

By low complexity I mean direct generation of SVG/PDF primitives : opengl2ps is 
horrible for that purpose, for instance opengl spheres are approximated by 
thousands of triangles instead of just being represented as a SVG/PDF circle 
primitive.

And vector graphics is just the way to go in almost any case.

As a bonus, please do no provide direct jpeg export. 

Re: [julia-users] suggestion of OSX julia/ijulia setup

[Jon Norberg]

Many thanks Cameron, I'll try that setup. Did I understand that you use 
brew to compile julia?

On Friday, May 16, 2014 4:21:19 PM UTC+2, Ethan Anderes wrote:
>
> +1 for Cameron. I use the same workflow. 

Re: [julia-users] suggestion of OSX julia/ijulia setup

[Jon Norberg]

Also, I sometimes seem to get issues with what libraries are being used. I 
am not very good at this but I understand there are different compiler 
libraries and native osx ones. How do you guys handle this? or is it not an 
issue using brew?

On Sunday, May 18, 2014 6:39:38 PM UTC+2, Jon Norberg wrote:
>
> Many thanks Cameron, I'll try that setup. Did I understand that you use 
> brew to compile julia?
>
> On Friday, May 16, 2014 4:21:19 PM UTC+2, Ethan Anderes wrote:
>>
>> +1 for Cameron. I use the same workflow. 
>
>

Re: [julia-users] Re: Downloaded binary startup way slower than when compiled from github

[Dom Luna]

Just downloaded it today again to try it out and the binary has the same 
startup times as from source now. The version of darwin in the binary is 
still 12.5.0 vs 13.1.0 from source. I have no idea if that's an issue or 
not but the startup time is fine now, thanks Elliot.

Dom

On Saturday, May 17, 2014 5:09:42 PM UTC-4, Elliot Saba wrote:
>
> Yep, we used to do this on purpose, since we didn't have a good way of 
> restricting the optimizations used by the compiler.  Now we've got a good 
> baseline set, and the nightlies needed their configurations to be matched. 
>  New binaries should be up by tonight.
> -E
>
>
> On Sat, May 17, 2014 at 11:34 AM, Tobias Knopp 
> 
> > wrote:
>
>> It seems that the compiled system image is not included in the prerelease 
>> binaries.
>>
>> Am Samstag, 17. Mai 2014 20:23:46 UTC+2 schrieb Dom Luna:
>>
>>> I find it weird that the downloaded one has a drastically slower REPL 
>>> startup than when compiled from github repo.
>>>
>>> $ where julia
>>> /Applications/Julia-0.3.0-prerelease-0b05b21911.app/
>>> Contents/Resources/julia/bin/julia
>>> /usr/local/bin/julia
>>>
>>> I'm symlinking $HOME/julia/julia to /usr/local/bin/julia
>>>
>>> Here's the startup times
>>>
>>> Downloaded:
>>>
>>> time julia -e 'println("Helo")'
>>> 5.07s user 0.10s system 98% cpu 5.250 total
>>>
>>> Source:
>>>
>>> time /usr/local/bin/julia -e 'println("Helo")'
>>> 0.28s user 0.08s system 117% cpu 0.308 total
>>>
>>> The versions are 1 day old from each other.
>>>
>>> Downloaded:
>>>
>>>_
>>>_   _ _(_)_ |  A fresh approach to technical computing
>>>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>>_ _   _| |_  __ _   |  Type "help()" to list help topics
>>>   | | | | | | |/ _` |  |
>>>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3053 (2014-05-14 
>>> 22:03 UTC)
>>>  _/ |\__'_|_|_|\__'_|  |  Commit 0b05b21* (2 days old master)
>>> |__/   |  x86_64-apple-darwin12.5.0
>>>
>>>
>>> Source:
>>>
>>>   _
>>>_   _ _(_)_ |  A fresh approach to technical computing
>>>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>>_ _   _| |_  __ _   |  Type "help()" to list help topics
>>>   | | | | | | |/ _` |  |
>>>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3081 (2014-05-16 
>>> 15:12 UTC)
>>>  _/ |\__'_|_|_|\__'_|  |  Commit eb4bfcc (1 day old master)
>>> |__/   |  x86_64-apple-darwin13.1.0
>>>
>>> The main thing I notice is the apple-darwin12.5.0 vs apple-darwin13.1.0. 
>>> I'm not sure what that means. I'm on OSX 10.9.2.
>>>
>>> Dom
>>>
>>>
>

[julia-users] linear algebra speed comparisons with MATLAB

[Thomas Covert]

I am finding that MATLAB is considerably faster than Julia for simple 
linear algebra work on my machine (mid-2009 macbook pro).  Why might this 
be?  Is this an OpenBLAS vs Intel MKL issue?

For example, on my machine, matrix inversion of a random, symmetric matrix 
is more than twice as fast in MATLAB as it is in Julia:

MATLAB code:
K = randn(2500,2500);
K = K' * K;
tic; inv(K); toc
Elapsed time is 2.182241 seconds.

Julia code:
K = convert(Array{Float32},randn(2500,2500));
K = K' * K;
tic(); inv(K); toc()
elapsed time: 6.249259727 seconds

I'm running a fairly recent MATLAB release (2014a), and versioninfo() in my 
Julia install reads:
Julia Version 0.3.0-prerelease+2918
Commit 104568c* (2014-05-06 22:29 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin12.5.0)
  CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
  WORD_SIZE: 64
  BLAS: libgfortblas
  LAPACK: liblapack
  LIBM: libopenlibm

Any advice is much appreciated.

[julia-users] Re: linear algebra speed comparisons with MATLAB

[J Luis]

Funny, in a similar machine (but running Windows) I get the opposite

Matlab 2012a (32 bits)
>> tic; inv(K); toc
Elapsed time is 3.837033 seconds.


julia> tic(); inv(K); toc()
elapsed time: 1.157727675 seconds
1.157727675

julia> versioninfo()
Julia Version 0.3.0-prerelease+3081
Commit eb4bfcc* (2014-05-16 15:12 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7 CPU   M 620  @ 2.67GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm

Domingo, 18 de Maio de 2014 19:16:48 UTC+1, Thomas Covert escreveu:
>
> I am finding that MATLAB is considerably faster than Julia for simple 
> linear algebra work on my machine (mid-2009 macbook pro).  Why might this 
> be?  Is this an OpenBLAS vs Intel MKL issue?
>
> For example, on my machine, matrix inversion of a random, symmetric matrix 
> is more than twice as fast in MATLAB as it is in Julia:
>
> MATLAB code:
> K = randn(2500,2500);
> K = K' * K;
> tic; inv(K); toc
> Elapsed time is 2.182241 seconds.
>
> Julia code:
> K = convert(Array{Float32},randn(2500,2500));
> K = K' * K;
> tic(); inv(K); toc()
> elapsed time: 6.249259727 seconds
>
> I'm running a fairly recent MATLAB release (2014a), and versioninfo() in 
> my Julia install reads:
> Julia Version 0.3.0-prerelease+2918
> Commit 104568c* (2014-05-06 22:29 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin12.5.0)
>   CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
>   WORD_SIZE: 64
>   BLAS: libgfortblas
>   LAPACK: liblapack
>   LIBM: libopenlibm
>
> Any advice is much appreciated.
>
>

[julia-users] sizehint( set, n ) returns Dict

[Andrew Dabrowski]

Any particular reason that when s is a Set,  sizehint( s, n ) returns 
s.dict rather than s?

Re: [julia-users] sizehint for new array

[Andrew Dabrowski]

Thanks.  What confused me is whether it's advantageous to prepare the new 
variable for the initial value, or whether that's done automatically.  I.e. 
is

newarray = f( oldarray )

OK or is it better to do

newarray = similar( oldarray )

followed by adding the elements of f( oldarray ) 1 by 1?  I gather from 
what you said that the latter is not necessary.


On Sunday, May 18, 2014 7:19:36 AM UTC-4, Tim Holy wrote:
>
> On Saturday, May 17, 2014 02:04:49 PM Andrew Dabrowski wrote: 
> > But is it wrong to use it the way I suggested? 
>
> Not wrong, but whether it buys you anything depends on what comes next. 
> The 
> sizehint takes effect after the call to f(oldarray) returns, and it 
> doesn't 
> affect f at all. However, if the next thing you do with newarray is to 
> grow it, 
> then the sizehint might be useful. 
>
> Best, 
> --Tim 
>
>
> > On Saturday, May 17, 2014 4:27:19 PM UTC-4, Tim Holy wrote: 
> > > I use it right after creating an array that I'm going to be modifying 
> with 
> > > push!: 
> > > 
> > > a = Array(Int, 0) 
> > > sizehint(a, 10^5) 
> > > 
> > > Now I'll be able to push! at least 10^5 elements without it having to 
> re- 
> > > allocate and copy the data I've already added. 
> > > 
> > > --Tim 
> > > 
> > > On Saturday, May 17, 2014 09:29:49 AM Andrew Dabrowski wrote: 
> > > > What's the proper way to use sizehint when defining a new array?  Is 
> it 
> > > > 
> > > > newarray = sizehint( f( oldarray ), n ), 
> > > > 
> > > > or do you have to already have the new variable defined before using 
> > > > sizehint? 
>

Re: [julia-users] linear algebra speed comparisons with MATLAB

[Thomas Covert]

Seems like the windows and Mac versions of Julia call different blas/lapack
routines.  Might that be the cause?  Is it possible for me to ask julia to
use a different blas/lapack?

On Sunday, May 18, 2014, J Luis  wrote:

> Funny, in a similar machine (but running Windows) I get the opposite
>
> Matlab 2012a (32 bits)
> >> tic; inv(K); toc
> Elapsed time is 3.837033 seconds.
>
>
> julia> tic(); inv(K); toc()
> elapsed time: 1.157727675 seconds
> 1.157727675
>
> julia> versioninfo()
> Julia Version 0.3.0-prerelease+3081
> Commit eb4bfcc* (2014-05-16 15:12 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i7 CPU   M 620  @ 2.67GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>
> Domingo, 18 de Maio de 2014 19:16:48 UTC+1, Thomas Covert escreveu:
>>
>> I am finding that MATLAB is considerably faster than Julia for simple
>> linear algebra work on my machine (mid-2009 macbook pro).  Why might this
>> be?  Is this an OpenBLAS vs Intel MKL issue?
>>
>> For example, on my machine, matrix inversion of a random, symmetric
>> matrix is more than twice as fast in MATLAB as it is in Julia:
>>
>> MATLAB code:
>> K = randn(2500,2500);
>> K = K' * K;
>> tic; inv(K); toc
>> Elapsed time is 2.182241 seconds.
>>
>> Julia code:
>> K = convert(Array{Float32},randn(2500,2500));
>> K = K' * K;
>> tic(); inv(K); toc()
>> elapsed time: 6.249259727 seconds
>>
>> I'm running a fairly recent MATLAB release (2014a), and versioninfo() in
>> my Julia install reads:
>> Julia Version 0.3.0-prerelease+2918
>> Commit 104568c* (2014-05-06 22:29 UTC)
>> Platform Info:
>>   System: Darwin (x86_64-apple-darwin12.5.0)
>>   CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
>>   WORD_SIZE: 64
>>   BLAS: libgfortblas
>>   LAPACK: liblapack
>>   LIBM: libopenlibm
>>
>> Any advice is much appreciated.
>>
>>

Re: [julia-users] sizehint for new array

[Tim Holy]

If you know the size in advance, it's always better to use that information. 
Use a comprehension, or allocate it at the final size and use a loop. sizehint 
is really for things like push!. Try timing different approaches, and you'll 
discover that sizehint helps some but does not make push! as fast as either of 
the other two options. But it's wonderful for those cases where you don't know 
the final size.

--Tim

On Sunday, May 18, 2014 01:06:02 PM Andrew Dabrowski wrote:
> Thanks.  What confused me is whether it's advantageous to prepare the new
> variable for the initial value, or whether that's done automatically.  I.e.
> is
> 
> newarray = f( oldarray )
> 
> OK or is it better to do
> 
> newarray = similar( oldarray )
> 
> followed by adding the elements of f( oldarray ) 1 by 1?  I gather from
> what you said that the latter is not necessary.
> 
> On Sunday, May 18, 2014 7:19:36 AM UTC-4, Tim Holy wrote:
> > On Saturday, May 17, 2014 02:04:49 PM Andrew Dabrowski wrote:
> > > But is it wrong to use it the way I suggested?
> > 
> > Not wrong, but whether it buys you anything depends on what comes next.
> > The
> > sizehint takes effect after the call to f(oldarray) returns, and it
> > doesn't
> > affect f at all. However, if the next thing you do with newarray is to
> > grow it,
> > then the sizehint might be useful.
> > 
> > Best,
> > --Tim
> > 
> > > On Saturday, May 17, 2014 4:27:19 PM UTC-4, Tim Holy wrote:
> > > > I use it right after creating an array that I'm going to be modifying
> > 
> > with
> > 
> > > > push!:
> > > > 
> > > > a = Array(Int, 0)
> > > > sizehint(a, 10^5)
> > > > 
> > > > Now I'll be able to push! at least 10^5 elements without it having to
> > 
> > re-
> > 
> > > > allocate and copy the data I've already added.
> > > > 
> > > > --Tim
> > > > 
> > > > On Saturday, May 17, 2014 09:29:49 AM Andrew Dabrowski wrote:
> > > > > What's the proper way to use sizehint when defining a new array?  Is
> > 
> > it
> > 
> > > > > newarray = sizehint( f( oldarray ), n ),
> > > > > 
> > > > > or do you have to already have the new variable defined before using
> > > > > sizehint?

[julia-users] Re: linear algebra speed comparisons with MATLAB

[Hans W Borchers]

Because not so many may have Matlab installed on Linux,
here are my votes:

Matlab: 1.59 sec
Julia:  0.92 sec

julia> versioninfo()
Julia Version 0.3.0-prerelease+2985
Commit 645c696 (2014-05-10 17:14 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm


On Sunday, May 18, 2014 8:38:11 PM UTC+2, J Luis wrote:
>
> Funny, in a similar machine (but running Windows) I get the opposite
>
> Matlab 2012a (32 bits)
> >> tic; inv(K); toc
> Elapsed time is 3.837033 seconds.
>
>
> julia> tic(); inv(K); toc()
> elapsed time: 1.157727675 seconds
> 1.157727675
>
> julia> versioninfo()
> Julia Version 0.3.0-prerelease+3081
> Commit eb4bfcc* (2014-05-16 15:12 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i7 CPU   M 620  @ 2.67GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>
> Domingo, 18 de Maio de 2014 19:16:48 UTC+1, Thomas Covert escreveu:
>>
>> I am finding that MATLAB is considerably faster than Julia for simple 
>> linear algebra work on my machine (mid-2009 macbook pro).  Why might this 
>> be?  Is this an OpenBLAS vs Intel MKL issue?
>>
>> For example, on my machine, matrix inversion of a random, symmetric 
>> matrix is more than twice as fast in MATLAB as it is in Julia:
>>
>> MATLAB code:
>> K = randn(2500,2500);
>> K = K' * K;
>> tic; inv(K); toc
>> Elapsed time is 2.182241 seconds.
>>
>> Julia code:
>> K = convert(Array{Float32},randn(2500,2500));
>> K = K' * K;
>> tic(); inv(K); toc()
>> elapsed time: 6.249259727 seconds
>>
>> I'm running a fairly recent MATLAB release (2014a), and versioninfo() in 
>> my Julia install reads:
>> Julia Version 0.3.0-prerelease+2918
>> Commit 104568c* (2014-05-06 22:29 UTC)
>> Platform Info:
>>   System: Darwin (x86_64-apple-darwin12.5.0)
>>   CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
>>   WORD_SIZE: 64
>>   BLAS: libgfortblas
>>   LAPACK: liblapack
>>   LIBM: libopenlibm
>>
>> Any advice is much appreciated.
>>
>>

[julia-users] Re: Proof of concept: hydrodynamics in julia!

[Iain Dunning]

Really nice work! Would be awesome (and non-trivial :D) to parallelize it, 
would be a pretty cool Julia demonstration.

On Sunday, May 18, 2014 7:41:43 AM UTC-4, Joonas Nättilä wrote:
>
> Hi all,
>
> After some twiddling and debugging I can finally announce the first alpha 
> version of (what I suspect to be the first) hydrodynamics code written in 
> julia:
>
> http://github.com/natj/hydro 
>
> There are still quite a lot of things to do like parallelization but even 
> currently it is capable of running a 100x100 grid with reasonable speed 
> live. The original python code I based this on, was able to maintain 
> approximately the same speed in 1 dimension but we are already doing 
> computations in 2d!
>
> One of my design goals was to make this as modular and flexible as 
> possible so that it could be used a as basis for more complex calculations. 
> Due to this it should be relatively straightforward to upgrade it to for 
> example to magnetohydrodynamics or to shallow water equations. Also, now 
> that I have the initial frame done, I plan to begin a heavy testing and 
> optimization period so all comments, tips and improvements are welcome! 
>
> I also computed some eye-candy for you that you can amaze here 
> https://vimeo.com/95607699
>
>
> Cheers,
> Joonas
>

[julia-users] sizehint( set, n ) returns Dict

[Ivar Nesje]

Probably because nobody noticed/cared before you did. It seems likely that this 
could happen by accident.

See: https://github.com/JuliaLang/julia/blob/master/base/set.jl#L29

Re: [julia-users] Re: tanh() speed / multi-threading

[Carlos Becker]

Great to see that Tobias' PR rocks ;)

I am still getting a weird segfault, and cannot reproduce it when put to
simpler code.
I will keep working on it, and post it as soon as I nail it.

Tobias: any pointer towards possible incompatibilities of the current state
of the PR?

thanks.


--
Carlos


On Sun, May 18, 2014 at 5:26 PM, Tobias Knopp
wrote:

> And I am pretty excited that it seems to scale so well at your setup. I
> have only 2 cores so could not see if it scales to more cores.
>
> Am Sonntag, 18. Mai 2014 16:40:18 UTC+2 schrieb Tobias Knopp:
>
>> Well when I started I got segfaullt all the time :-)
>>
>> Could you please send me a minimal code example that segfaults? This
>> would be great! This is the only way we can get this stable.
>>
>> Am Sonntag, 18. Mai 2014 16:35:47 UTC+2 schrieb Carlos Becker:
>>>
>>> Sounds great!
>>> I just gave it a try, and with 16 threads I get 0.07sec which is
>>> impressive.
>>>
>>> That is when I tried it in isolated code. When put together with other
>>> julia code I have, it segfaults. Have you experienced this as well?
>>>  Le 18 mai 2014 16:05, "Tobias Knopp"  a
>>> écrit :
>>>
 sure, the function is Base.parapply though. I had explicitly imported
 it.

 In the case of vectorize_1arg it would be great to automatically
 parallelize comprehensions. If someone could tell me where the actual
 looping happens, this would be great. I have not found that yet. Seems to
 be somewhere in the parser.

 Am Sonntag, 18. Mai 2014 14:30:49 UTC+2 schrieb Carlos Becker:
>
> btw, the code you just sent works as is with your pull request branch?
>
>
> --
> Carlos
>
>
> On Sun, May 18, 2014 at 1:04 PM, Carlos Becker wrote:
>
>> HI Tobias, I saw your pull request and have been following it
>> closely, nice work ;)
>>
>> Though, in the case of element-wise matrix operations, like tanh,
>> there is no need for extra allocations, since the buffer should be
>> allocated only once.
>>
>> From your first code snippet, is julia smart enough to pre-compute
>> i*N/2 ?
>> In such cases, creating a kind of array view on the original data
>> would probably be faster, right? (though I don't know how allocations 
>> work
>> here).
>>
>> For vectorize_1arg_openmp, I was thinking of "hard-coding" it for
>> known operations such as trigonometric ones, that benefit a lot from
>> multi-threading.
>> I know this is a hack, but it is quick to implement and brings an
>> amazing speed up (8x in the case of the code I posted above).
>>
>>
>>
>>
>> --
>> Carlos
>>
>>
>> On Sun, May 18, 2014 at 12:30 PM, Tobias Knopp <
>> tobias...@googlemail.com> wrote:
>>
>>> Hi Carlos,
>>>
>>> I am working on something that will allow to do multithreading on
>>> Julia functions (https://github.com/JuliaLang/julia/pull/6741).
>>> Implementing vectorize_1arg_openmp is actually a lot less trivial as the
>>> Julia runtime is not thread safe (yet)
>>>
>>> Your example is great. I first got a slowdown of 10 because the
>>> example revealed a locking issue. With a little trick I now get a 
>>> speedup
>>> of 1.75 on a 2 core machine. Not to bad taking into account that memory
>>> allocation cannot be parallelized.
>>>
>>> The tweaked code looks like
>>>
>>> function tanh_core(x,y,i)
>>>
>>> N=length(x)
>>>
>>> for l=1:N/2
>>>
>>>   y[l+i*N/2] = tanh(x[l+i*N/2])
>>>
>>> end
>>>
>>> end
>>>
>>>
>>> function ptanh(x;numthreads=2)
>>>
>>> y = similar(x)
>>>
>>> N = length(x)
>>>
>>> parapply(tanh_core,(x,y), 0:1, numthreads=numthreads)
>>>
>>> y
>>>
>>> end
>>>
>>>
>>> I actually want this to be also fast for
>>>
>>>
>>> function tanh_core(x,y,i)
>>>
>>> y[i] = tanh(x[i])
>>>
>>> end
>>>
>>>
>>> function ptanh(x;numthreads=2)
>>>
>>> y = similar(x)
>>>
>>> N = length(x)
>>>
>>> parapply(tanh_core,(x,y), 1:N, numthreads=numthreads)
>>>
>>> y
>>>
>>> end
>>>
>>> Am Sonntag, 18. Mai 2014 11:40:13 UTC+2 schrieb Carlos Becker:
>>>
 now that I think about it, maybe openblas has nothing to do here,
 since @which tanh(y) leads to a call to vectorize_1arg().

 If that's the case, wouldn't it be advantageous to have a
 vectorize_1arg_openmp() function (defined in C/C++) that works for
 element-wise operations on scalar arrays,
 multi-threading with OpenMP?


 El domingo, 18 de mayo de 2014 11:34:11 UTC+2, Carlos Becker
 escribió:

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Simon Danisch]

I just noticed, I haven't mentioned anywhere, that this will be OpenGL 
plotting only.
There are just limited options for rendering shapes, but there are 
definitely some more tricks to render shapes, than by approximating them 
with a gazillion triangles.
One is, to draw pixels on a quad in the fragment shader, at every position 
a shape function returns true, which also allows for some various methods 
of anti-aliasing.
But this is restricted to 2D planes, as far as I'm concerned. 
But I'm still learning GLSL and always find new ways of supporting magical 
stuff (or nasty platform dependencies).

I did think about svg/pdf/latex output, but this is quite a big project by 
itself. But I'll keep it in mind and try to design the API in a way, that 
it behaves friendly towards those kind of projects.
It might not be terribly difficult though, if every of my render primitives 
implements a function, that returns the corresponding svg/pdf/latex code.
Jpeg support should be rather trivial in comparison, thanks to Images.jl =)

Re: [julia-users] sizehint( set, n ) returns Dict

[Stefan Karpinski]

Yes, that's an oversight. It should return s instead.


On Sun, May 18, 2014 at 5:30 PM, Ivar Nesje  wrote:

> Probably because nobody noticed/cared before you did. It seems likely that
> this could happen by accident.
>
> See: https://github.com/JuliaLang/julia/blob/master/base/set.jl#L29
>
>

Re: [julia-users] linear algebra speed comparisons with MATLAB

[Leah Hanson]

There are instructions in the Julia README and on Intel's website for
running Julia with MKL:

https://github.com/JuliaLang/julia#intel-math-kernel-libraries
https://software.intel.com/en-us/articles/julia-with-intel-mkl-for-improved-performance

-- Leah


On Sun, May 18, 2014 at 3:59 PM, Thomas Covert wrote:

> Seems like the windows and Mac versions of Julia call different
> blas/lapack routines.  Might that be the cause?  Is it possible for me to
> ask julia to use a different blas/lapack?
>
>
> On Sunday, May 18, 2014, J Luis  wrote:
>
>> Funny, in a similar machine (but running Windows) I get the opposite
>>
>> Matlab 2012a (32 bits)
>> >> tic; inv(K); toc
>> Elapsed time is 3.837033 seconds.
>>
>>
>> julia> tic(); inv(K); toc()
>> elapsed time: 1.157727675 seconds
>> 1.157727675
>>
>> julia> versioninfo()
>> Julia Version 0.3.0-prerelease+3081
>> Commit eb4bfcc* (2014-05-16 15:12 UTC)
>> Platform Info:
>>   System: Windows (x86_64-w64-mingw32)
>>   CPU: Intel(R) Core(TM) i7 CPU   M 620  @ 2.67GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>   LAPACK: libopenblas
>>   LIBM: libopenlibm
>>
>> Domingo, 18 de Maio de 2014 19:16:48 UTC+1, Thomas Covert escreveu:
>>>
>>> I am finding that MATLAB is considerably faster than Julia for simple
>>> linear algebra work on my machine (mid-2009 macbook pro).  Why might this
>>> be?  Is this an OpenBLAS vs Intel MKL issue?
>>>
>>> For example, on my machine, matrix inversion of a random, symmetric
>>> matrix is more than twice as fast in MATLAB as it is in Julia:
>>>
>>> MATLAB code:
>>> K = randn(2500,2500);
>>> K = K' * K;
>>> tic; inv(K); toc
>>> Elapsed time is 2.182241 seconds.
>>>
>>> Julia code:
>>> K = convert(Array{Float32},randn(2500,2500));
>>> K = K' * K;
>>> tic(); inv(K); toc()
>>> elapsed time: 6.249259727 seconds
>>>
>>> I'm running a fairly recent MATLAB release (2014a), and versioninfo() in
>>> my Julia install reads:
>>> Julia Version 0.3.0-prerelease+2918
>>> Commit 104568c* (2014-05-06 22:29 UTC)
>>> Platform Info:
>>>   System: Darwin (x86_64-apple-darwin12.5.0)
>>>   CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
>>>   WORD_SIZE: 64
>>>BLAS: libgfortblas
>>>   LAPACK: liblapack
>>>   LIBM: libopenlibm
>>>
>>> Any advice is much appreciated.
>>>
>>>

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[gael . mcdon]

I actually said *not* to implement direct jpeg export. I thought you were 
targeting stuff like 3D graphs in which case jpeg export generaly does more 
harm than good because most of the people don't know which image format to 
choose and use what they are the most used to see: jpeg; even though it makes 
absolutely no sense for graphs.

Just a comment. If you are really willing to implement something from scratch 
please do. But did you consider using libraries like VTK (I'm sure I've read 
something about it on one of julia's lists a few days ago).

VTK is not only about providing a way to visualize data, it's also a complete 
framework for choosing how and what to render from a given dataset using a 
pipeline of filters which alter data or representations of data. This is what 
is used by paraview and in Python in Mayavi.

I would love to see something inspired by Mayavi in Julia!

Again, if you want to implement something using opengl, it's fine but you might 
also consider leveraging such a powerful tool.

Re: [julia-users] Re: Downloaded binary startup way slower than when compiled from github

[Elliot Saba]

Awesome, glad it's working.

The Darwin version is because the binaries distributed online are built on
an OSX 10.8 machine, so it gets baked in with a different Darwin version.
-E


On Sun, May 18, 2014 at 11:06 AM, Dom Luna  wrote:

> Just downloaded it today again to try it out and the binary has the same
> startup times as from source now. The version of darwin in the binary is
> still 12.5.0 vs 13.1.0 from source. I have no idea if that's an issue or
> not but the startup time is fine now, thanks Elliot.
>
> Dom
>
>
> On Saturday, May 17, 2014 5:09:42 PM UTC-4, Elliot Saba wrote:
>
>> Yep, we used to do this on purpose, since we didn't have a good way of
>> restricting the optimizations used by the compiler.  Now we've got a good
>> baseline set, and the nightlies needed their configurations to be matched.
>>  New binaries should be up by tonight.
>> -E
>>
>>
>> On Sat, May 17, 2014 at 11:34 AM, Tobias Knopp 
>> wrote:
>>
>>> It seems that the compiled system image is not included in the
>>> prerelease binaries.
>>>
>>> Am Samstag, 17. Mai 2014 20:23:46 UTC+2 schrieb Dom Luna:
>>>
 I find it weird that the downloaded one has a drastically slower REPL
 startup than when compiled from github repo.

 $ where julia
 /Applications/Julia-0.3.0-prerelease-0b05b21911.app/Contents
 /Resources/julia/bin/julia
 /usr/local/bin/julia

 I'm symlinking $HOME/julia/julia to /usr/local/bin/julia

 Here's the startup times

 Downloaded:

 time julia -e 'println("Helo")'
 5.07s user 0.10s system 98% cpu 5.250 total

 Source:

 time /usr/local/bin/julia -e 'println("Helo")'
 0.28s user 0.08s system 117% cpu 0.308 total

 The versions are 1 day old from each other.

 Downloaded:

_
_   _ _(_)_ |  A fresh approach to technical computing
   (_) | (_) (_)|  Documentation: http://docs.julialang.org
_ _   _| |_  __ _   |  Type "help()" to list help topics
   | | | | | | |/ _` |  |
   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3053 (2014-05-14
 22:03 UTC)
  _/ |\__'_|_|_|\__'_|  |  Commit 0b05b21* (2 days old master)
 |__/   |  x86_64-apple-darwin12.5.0


 Source:

   _
_   _ _(_)_ |  A fresh approach to technical computing
   (_) | (_) (_)|  Documentation: http://docs.julialang.org
_ _   _| |_  __ _   |  Type "help()" to list help topics
   | | | | | | |/ _` |  |
   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3081 (2014-05-16
 15:12 UTC)
  _/ |\__'_|_|_|\__'_|  |  Commit eb4bfcc (1 day old master)
 |__/   |  x86_64-apple-darwin13.1.0

 The main thing I notice is the apple-darwin12.5.0 vs
 apple-darwin13.1.0. I'm not sure what that means. I'm on OSX 10.9.2.

 Dom


>>

Re: [julia-users] linear algebra speed comparisons with MATLAB

[Thomas Covert]

Thanks for sending that along - might go down that route once it's clear
that MKL would do the trick and that the fixed costs of building it myself
are worth it.

Are there other mac users using the pre-built binaries that see these same
performance differences?  Why do the mac binaries report libgfortblas and
liblapack when the windows and Linux binaries report libopenblas?

On Sunday, May 18, 2014, Leah Hanson  wrote:

> There are instructions in the Julia README and on Intel's website for
> running Julia with MKL:
>
> https://github.com/JuliaLang/julia#intel-math-kernel-libraries
>
> https://software.intel.com/en-us/articles/julia-with-intel-mkl-for-improved-performance
>
> -- Leah
>
>
> On Sun, May 18, 2014 at 3:59 PM, Thomas Covert 
> 
> > wrote:
>
>> Seems like the windows and Mac versions of Julia call different
>> blas/lapack routines.  Might that be the cause?  Is it possible for me to
>> ask julia to use a different blas/lapack?
>>
>>
>> On Sunday, May 18, 2014, J Luis 
>> >
>> wrote:
>>
>>> Funny, in a similar machine (but running Windows) I get the opposite
>>>
>>> Matlab 2012a (32 bits)
>>> >> tic; inv(K); toc
>>> Elapsed time is 3.837033 seconds.
>>>
>>>
>>> julia> tic(); inv(K); toc()
>>> elapsed time: 1.157727675 seconds
>>> 1.157727675
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.0-prerelease+3081
>>> Commit eb4bfcc* (2014-05-16 15:12 UTC)
>>> Platform Info:
>>>   System: Windows (x86_64-w64-mingw32)
>>>   CPU: Intel(R) Core(TM) i7 CPU   M 620  @ 2.67GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>>   LAPACK: libopenblas
>>>   LIBM: libopenlibm
>>>
>>> Domingo, 18 de Maio de 2014 19:16:48 UTC+1, Thomas Covert escreveu:

 I am finding that MATLAB is considerably faster than Julia for simple
 linear algebra work on my machine (mid-2009 macbook pro).  Why might this
 be?  Is this an OpenBLAS vs Intel MKL issue?

 For example, on my machine, matrix inversion of a random, symmetric
 matrix is more than twice as fast in MATLAB as it is in Julia:

 MATLAB code:
 K = randn(2500,2500);
 K = K' * K;
 tic; inv(K); toc
 Elapsed time is 2.182241 seconds.

 Julia code:
 K = convert(Array{Float32},randn(2500,2500));
 K = K' * K;
 tic(); inv(K); toc()
 elapsed time: 6.249259727 seconds

 I'm running a fairly recent MATLAB release (2014a), and versioninfo()
 in my Julia install reads:
 Julia Version 0.3.0-prerelease+2918
 Commit 104568c* (2014-05-06 22:29 UTC)
 Platform Info:
   System: Darwin (x86_64-apple-darwin12.5.0)
   CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
   WORD_SIZE: 64
BLAS: libgfortblas
   LAPACK: liblapack
   LIBM: libopenlibm

 Any advice is much appreciated.


>

[julia-users] iterating over a dictionary

[Jason Solack]

Hello everyone!

I'm iterating over a dictionary returned by proportionmap and i'm wondering 
how i can tell what key the current iteration is referring to.

Thank you!

Jason

Re: [julia-users] suggestion of OSX julia/ijulia setup

[Cameron McBride]

Hi Jon,

No -- I pull julia via git on github, and compile by hand every few days.
 I've symlinked ~/bin/julia to the directory that I compile julia into, so
julia is in my path.

On 10.9, the "native" option is Clang, which works fine..  I've been able
to dodge gcc (gnu) for all system dependencies so far.  Homebrew seems to
handle a lot of lib conflicts pretty well, unless you tap some obvious ones
or do some forcing.

Cameron


On Sun, May 18, 2014 at 12:46 PM, Jon Norberg wrote:

> Also, I sometimes seem to get issues with what libraries are being used. I
> am not very good at this but I understand there are different compiler
> libraries and native osx ones. How do you guys handle this? or is it not an
> issue using brew?
>
>
> On Sunday, May 18, 2014 6:39:38 PM UTC+2, Jon Norberg wrote:
>>
>> Many thanks Cameron, I'll try that setup. Did I understand that you use
>> brew to compile julia?
>>
>> On Friday, May 16, 2014 4:21:19 PM UTC+2, Ethan Anderes wrote:
>>>
>>> +1 for Cameron. I use the same workflow.
>>
>>

Re: [julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Tim Holy]

I'd also point out that our two leading plotting packages, Gadfly and Winston, 
are both pretty good at exporting 2d plots. We're weaker at real-time 
interactive exploration of large datasets, and that's a pretty big hole. Since 
the great strength of OpenGL is that it has the kind of performance that can 
allow one to make some "difficult" problems (like volume rendering) fast enough 
to be pleasantly interactive, I'd say this should be the priority. If you can 
solve the export problem too, wonderful, but if constraints of time force you 
to choose, I urge you to callously throw export out the window and focus on 
interactivity :).

--Tim

On Sunday, May 18, 2014 02:58:39 PM Simon Danisch wrote:
> I just noticed, I haven't mentioned anywhere, that this will be OpenGL
> plotting only.
> There are just limited options for rendering shapes, but there are
> definitely some more tricks to render shapes, than by approximating them
> with a gazillion triangles.
> One is, to draw pixels on a quad in the fragment shader, at every position
> a shape function returns true, which also allows for some various methods
> of anti-aliasing.
> But this is restricted to 2D planes, as far as I'm concerned.
> But I'm still learning GLSL and always find new ways of supporting magical
> stuff (or nasty platform dependencies).
> 
> I did think about svg/pdf/latex output, but this is quite a big project by
> itself. But I'll keep it in mind and try to design the API in a way, that
> it behaves friendly towards those kind of projects.
> It might not be terribly difficult though, if every of my render primitives
> implements a function, that returns the corresponding svg/pdf/latex code.
> Jpeg support should be rather trivial in comparison, thanks to Images.jl =)

[julia-users] Re: iterating over a dictionary

[James Porter]

iterating over a dictionary yields (key, value) tuples:

julia> proportionmap([1,1,2,2,3])
[2=>0.4,3=>0.2,1=>0.4]

julia> for (k,v) in proportionmap([1,1,2,2,3])
 println(k)
   end
2
3
1

julia>


—James

On Sunday, May 18, 2014 7:26:39 PM UTC-5, Jason Solack wrote:
>
> Hello everyone!
>
> I'm iterating over a dictionary returned by proportionmap and i'm 
> wondering how i can tell what key the current iteration is referring to.
>
> Thank you!
>
> Jason
>

[julia-users] Re: iterating over a dictionary

[Jason Solack]

perfect, thank you very much!

On Sunday, May 18, 2014 10:10:47 PM UTC-4, James Porter wrote:
>
> iterating over a dictionary yields (key, value) tuples:
>
> julia> proportionmap([1,1,2,2,3])
> [2=>0.4,3=>0.2,1=>0.4]
>
> julia> for (k,v) in proportionmap([1,1,2,2,3])
>  println(k)
>end
> 2
> 3
> 1
>
> julia>
>
>
> —James
>
> On Sunday, May 18, 2014 7:26:39 PM UTC-5, Jason Solack wrote:
>>
>> Hello everyone!
>>
>> I'm iterating over a dictionary returned by proportionmap and i'm 
>> wondering how i can tell what key the current iteration is referring to.
>>
>> Thank you!
>>
>> Jason
>>
>

Re: [julia-users] purpose of the end keyword

[James Porter]

The really compelling thing about a non-whitespace block ending delimiter 
for me is editors being able to automatically indent my code. I've been 
bitten by far too many python bugs that Emacs would have caught for me in a 
second if python had and `end` keyword instead of syntactic whitespace.

On Thursday, May 15, 2014 3:12:47 PM UTC-5, Stefan Karpinski wrote:
>
> Yes, the point about metaprogramming is a good one.
>
>
> On Thu, May 15, 2014 at 4:03 PM, Steven G. Johnson 
> 
> > wrote:
>
>> It's a tradeoff. The cost of having an explicit "end" is a few extra 
>> characters that you have to type, and an extra line of code at the end of 
>> each block.  On the other hand, the benefits include less error-prone 
>> cut-and-paste (as Stefan mentioned), the possibility of automated 
>> reformatting of code (e.g. think emacs indent-region or gofmt), and 
>> flexibility in writing one-liners (e.g. "try foo() end").
>>
>> I think the metaprogramming facilities in Julia also favor the choice of 
>> explicit block delimiters.  In Julia, code can also be a symbolic 
>> expression, simply by surrounding it with :() or quote ... end, and 
>> whitespace sensitivity within symbolic expressions seems like it would get 
>> annoying quickly
>>
>> Probably this should be in the Julia FAQ or Manual, since our 
>> inexplicable rejection of the holy whitespace seems to be the first thing 
>> that every Python programmer asks about.  (If you hate typing extraneous 
>> characters, the colons in Python must drive you bonkers.)
>>
>> (People who like maximum terseness in a practical programming language 
>> should take a look at J.   The J examples on 
>> RosettaCodeare pretty amazing.)
>>
>
>

[julia-users] Re: DataFrames, no method push!

[Travis Porco]

Actually, as far as I can tell now, one should really have 0.3 to use 
DataFrames after all. Sorry for posting the question.

On Friday, May 16, 2014 8:47:57 PM UTC-7, Travis Porco wrote:
>
> This from Julia 0.2.1 on MacOSX 10.7.5, using the DataFrames package, 
> just now updated before the following attemp to execute example code from 
> the manual:
>
> Version 0.2.1 (2014-02-11 06:30 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-apple-darwin12.5.0
>
> julia> using DataFrames
>
> julia> df = DataFrame()
> 0x0 DataFrame:
>
> julia> df[:A] = 1:8
> ERROR: no method push!(Index,Symbol)
>  in insert_single_column! at 
> /Users/travis/.julia/DataFrames/src/dataframe.jl:480
>  in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525
>
> julia> df[:B] = ["M", "F", "F", "M", "F", "M", "M", "F"]
> ERROR: no method push!(Index,Symbol)
>  in insert_single_column! at 
> /Users/travis/.julia/DataFrames/src/dataframe.jl:480
>  in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525
>
> But stranger, to me:
>
> julia> push!
> push! (generic function with 12 methods)
>
> Etc. I googled "no method push!" julia
> but I didn't see anything that seemed relevant to my beginner's mind, and 
> I searched 
> this group as well.
>
> Also, the same problem happened just before updating (the update was a 
> failed attempt to fix it).
>
> Is it fixable and worth fixing, or should I just wait for the official 
> 0.3? 
>
> Thanks kindly.
>
>

Re: [julia-users] sizehint( set, n ) returns Dict

[Ivar Nesje]

https://github.com/JuliaLang/julia/pull/6883

kl. 00:35:41 UTC+2 mandag 19. mai 2014 skrev Stefan Karpinski følgende:
>
> Yes, that's an oversight. It should return s instead.
>
>
> On Sun, May 18, 2014 at 5:30 PM, Ivar Nesje 
> > wrote:
>
>> Probably because nobody noticed/cared before you did. It seems likely 
>> that this could happen by accident.
>>
>> See: https://github.com/JuliaLang/julia/blob/master/base/set.jl#L29
>>
>>
>