> Silly me...
>
> I was using python anaconda and it seems to be user more than one process...
No, OpenBLAS used by Julia should also use several threads.
You can change the number of threads like so:
~/julia/tmp >> export OPENBLAS_NUM_THREADS=2
~/julia/tmp >> julia5 tt.jl
I actually get the be
Silly me...
I was using python anaconda and it seems to be user more than one process...
I apologize for this,
Thanks everybody for your help,
Best
There's already a certain amount of automatic bounds-checking removal, but it
does that only when it can prove that it's safe. It's not hard to cook up
situations where the compiler can't do that.
See also the `--check-bounds` command line option for starting julia.
--Tim
On Thursday, January
Hi Steven,
I added your version (vander3) to my benchmark and updated the IJulia
notebook:
http://nbviewer.ipython.org/gist/synapticarbors/26910166ab775c04c47b
As you mentioned it's a lot faster than the other version I wrote and evens
out the underperformance vs numpy for the larger arrays on
For comparison, the NumPy vander function
https://github.com/numpy/numpy/blob/f4be1039d6fe3e4fdc157a22e8c071ac10651997/numpy/lib/twodim_base.py#L490-L577
does all its work in multiply.accumulate. Here is the outer loop of
multiply.accumulate (written in C):
https://github.com/nump
No, I'm just using the 0.3.4 release build from the website. I don't have a
personal MKL license. The python build is from Continuum via their Anaconda
distribution with the accelerate add-on (free for academics).
Josh
On Jan 8, 2015, at 4:21 PM, Jiahao Chen wrote:
> Thanks for the update. A
Thanks for the update. Are you also building Julia with MKL also then?
On Thu Jan 08 2015 at 4:19:48 PM Joshua Adelman
wrote:
> Hi Jiahao,
>
> Just a small note - based on your comments in the thread you mentioned, I
> ended up changing my test to just multiply ones to avoid over/underflow.
> Th
On Thursday, January 8, 2015 at 4:15:09 PM UTC-5, Jiahao Chen wrote:
>
> Furthermore Vandermonde is not a good test with larger matrix sizes since
> you are basically testing the speed of multiplying things by infinity,
> which may not be representative of typical computations as it may incur
Hi Jiahao,
Just a small note - based on your comments in the thread you mentioned, I ended
up changing my test to just multiply ones to avoid over/underflow. Those are
the results that are now in that notebook, so that shouldn't be an issue in the
plotted timings. On the python side, I'm using
On Thursday, January 8, 2015 at 3:29:01 PM UTC-5, Joshua Adelman wrote:
>
> You're reading it correctly. I'm not sure exactly why numpy is performing
> better for the larger matrices, but I suspect that numpy's accumulate
> function that np.vander uses may be taking advantage of simd, sse or mk
As Stefan wrote, all you are really doing with larger matrix tests is
testing the speed of the different BLAS implementations being used by your
distributions of Julia and NumPy.
As I wrote in the other thread
https://groups.google.com/d/msg/julia-users/Q96aPufg4S8/IBU9hW0xvWYJ
the Vandermonde
You're reading it correctly. I'm not sure exactly why numpy is performing
better for the larger matrices, but I suspect that numpy's accumulate function
that np.vander uses may be taking advantage of simd, sse or mkl optimizations.
I'd have to do a bit of digging though to confirm that. I also h
hey Josh,
that makes sense to me. your benchmark, though, I may not be understanding;
it looks as if Julia is slower for larger matrices. is this true, or am I
just going crazy and not able to properly read graphs anymore?
On Thursday, January 8, 2015 at 12:46:29 PM UTC-6, Joshua Adelman wrote:
Also, that's a 1.5% performance difference which is pretty negligible.
> On Jan 8, 2015, at 2:15 PM, Stefan Karpinski
> wrote:
>
> You're really just comparing BLASes. So the question is what BLAS is each
> system using? You can find out in Julia using versioninfo().
>
>
>> On Jan 8, 2015,
You're really just comparing BLASes. So the question is what BLAS is each
system using? You can find out in Julia using versioninfo().
> On Jan 8, 2015, at 1:27 PM, Dakota St. Laurent
> wrote:
>
> hi all, I've been trying to test some simple benchmarks for my new job to see
> what language w
numpy.dot is calling BLAS under the hood so it's calling fast code and I
wouldn't expect Julia to shine against it. Try calling numpy methods that
aren't thin wrappers around C and you should see a bigger difference. Or
implement a larger more complex algorithm. Here's a simple micro-benchmark I
hi all, I've been trying to test some simple benchmarks for my new job to
see what language we should use between Python (Numpy/Scipy) and Julia. I
like how simple it seems for Julia to do things in parallel (we plan to be
running code on a supercomputer using lots and lots of cores), but I'm no
17 matches
Mail list logo
