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. >>>> >>>>
