You should add @inbounds and try adding @fastmath to the Julia code. Maybe @simd, though the compiler should be doing that automatically. Make sure Julia is compiling with -O3. I wouldn't be surprised if this gets nearly to C++.
If you want to put the random number generation back in, you can improve Julia's time by using ChunkedArrays.jl which allows you to take the random numbers in chunks instead of one at a time in a loop. That should get rid of most of the RNG time in Julia, but the code won't be any more bloated. I think this is one thing to show off in Julia: Julia types (/object) don't have speed penalties, so you can use them to make "fast versions" of just about anything. [Master branch is for Julia v0.5, last tagged version if for Julia v0.4.x. It allows for the random buffer to replenish using a parallel process, but that part had to change in the update] Other notes: MATLAB really improved their JIT in 2015b, but as you can see, it cannot come close to Julia. The main reason is that, although it can do quite a bit because it ensures type stability, it has type stability only because everything in MATLAB is by default a complex number. So even in the simplest example (where its JIT works correctly. You'll notice that in many cases it won't work, and since it doesn't cache well it may recompile all the time, and ... it works okay but there's a reason I switched to Julia) you'd expect Julia to be at least twice as fast. You should test how whether the performance regresses on Julia v0.5 with LLVM 3.7 On Monday, July 11, 2016 at 8:43:12 AM UTC-7, Zhong Pan wrote: > > Alexander, > > You are right. I have posted some results in a previous reply with the > calls to random number generator left out. Relatively speaking, C++ > execution time is reduced more significantly than others, making it the > fastest in that test. > > -Zhong > > On Monday, July 11, 2016 at 9:25:08 AM UTC-5, Alexander Ranaldi wrote: >> >> I am not sure calling the rand function in a loop is fair; you're >> benchmarking that function, not the mathematics. Perhaps allocate a vector >> of random numbers and index them rather than calling rand repeatedly. >> >> >> >> On Monday, July 11, 2016 at 8:09:28 AM UTC-4, David Barton wrote: >>> >>> For reference, with Matlab 2016a: 4.97 sec; Julia 0.4.6: 2.76 sec; >>> Python 3.5.1: 166.76 sec. >>> >>> Note that there is a mistake in your Matlab code - zeros(n) returns an n >>> by n matrix of zeros (hence running out of memory). Instead you want >>> zeros(1, n) to get a vector. >>> >>> David >>> >>> On Monday, 11 July 2016 10:07:01 UTC+1, Zhong Pan wrote: >>>> >>>> Hi Andreas, >>>> >>>> Thanks for the comments. >>>> >>>> * If someone has a more recent Matlab it'll be interesting to try. The >>>> license is so expensive and I don't have access to newer version now. >>>> >>>> * Yes you are right, I also realized that I don't know how much the >>>> random number generator implementation difference would contribute. One >>>> thing to try is to leave out the random number generations. >>>> >>>> I tried it and here's the result: Python 166.44 sec (107.4x, was >>>> 64.3x), Julia 2.56 sec (1.7x, was 0.8x), VC++ 1.55 sec (1.0x as >>>> reference), >>>> C#.NET 3.49 sec (2.3x, was 1.1x), Java 10.14 sec (6.5x, was 3.0x), and >>>> Matlab 7.75 sec (5.0x, was 3.3x). Therefore, it seems VC++ improved the >>>> most by removing random number generations, and other languages just all >>>> look relatively 1.5 to 2.2 times more slower. Julia is still the fastest >>>> aside from VC++, and C#.NET is still not far behind. >>>> >>>> Cheers, >>>> -Zhong >>>> >>>> >>>> On Monday, July 11, 2016 at 3:27:30 AM UTC-5, Andreas Lobinger wrote: >>>>> >>>>> 2 small things: >>>>> >>>>> * a more recent Matlab should already be faster, especially in this >>>>> loop thing >>>>> * random generators' runtime -depending on the complexity they spend- >>>>> really makes a difference. >>>>> >>>>>
