Chris, Thanks for the comments! I tried @inbounds and @fastmath, which reduced Julia execution time from 2.55 sec to 2.46 sec. @simd wouldn't be appropriate here as the point is to test brute-force loops that in reality are employed in calculations that cannot be vectorized. (And yes, I agree I should have used "brute-force". :-))
-Zhong On Monday, July 11, 2016 at 10:28:24 PM UTC-5, Chris Rackauckas wrote: > > 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. >>>>>> >>>>>>
