11:06 a.m.
Dear all,
I just stumbled about this Julia post
https://www.juliabloggers.com/when-julia-is-faster-than-c/
and translated the code to hansl. Running the original Julia code on my
machine with 10^7 iterations takes about 0.19 seconds. Running the hansl
code below takes about 19 seconds which is 100 times slower compared to
Julia. I am pretty sure there is a much more efficient way to set this
up this up using gretl+hansl (Jack? :-D ) -- but this is not my point.
Let's just assume the average user would set up things as simple as
possible.
I am just curious to know at which point Julia makes it seemingly better
compared to C and hansl? Any ideas? Btw, I can't see that Julia makes
any use of parallelization -- according to CPU information only a single
core is fully used. The same holds for gretl.
<hansl>
function void euler(int n, scalar *mn) # pointer form
scalar m = 0
loop i = 1..n -q
scalar the_sum = 0
loop while the_sum<=1 -q
m++
the_sum += randgen1(u,0,1)
endloop
endloop
mn = m/n
end function
set verbose off
clear
set stopwatch
scalar mn = 0
euler(10^7,&mn) # originally 10^8
printf "This took = %.6f sec.\n", $stopwatch
mn
<hansl>
Best,
Artur
12:44 p.m.
On 10.02.2018 12:06, Artur Tarassow wrote:
function void euler(int n, scalar *mn) # pointer form
scalar m = 0
loop i = 1..n -q
scalar the_sum = 0
loop while the_sum<=1 -q
m++
the_sum += randgen1(u,0,1)
endloop
endloop
mn = m/n
end function
set verbose off
clear
set stopwatch
scalar mn = 0
euler(10^7,&mn) # originally 10^8
printf "This took = %.6f sec.\n", $stopwatch
mn
You can gain at least one second with this version of euler function:
function void euler2(int n, scalar *mn) # pointer form
scalar m = 0
loop n -q
scalar the_sum = 0
loop while 1 -q
m++
the_sum += randgen1(u,0,1)
if the_sum > 1
break
endif
endloop
endloop
mn = m/n
end function
Marcin
--
Marcin Błażejowski
2:01 p.m.
On Sat, 10 Feb 2018, Artur Tarassow wrote:
Dear all,
I just stumbled about this Julia post
https://www.juliabloggers.com/when-julia-is-faster-than-c/
and translated the code to hansl. Running the original Julia code on my
machine with 10^7 iterations takes about 0.19 seconds. Running the hansl code
below takes about 19 seconds which is 100 times slower compared to Julia. I
am pretty sure there is a much more efficient way to set this up this up
using gretl+hansl (Jack? :-D ) -- but this is not my point. Let's just assume
the average user would set up things as simple as possible.
I am just curious to know at which point Julia makes it seemingly better
compared to C and hansl? Any ideas? Btw, I can't see that Julia makes any use
of parallelization -- according to CPU information only a single core is
fully used. The same holds for gretl.
IMHO, this is one of the cases when teh JIT approach gives a huge
performance boost; if you try the attached script, you'll see gretl is not
bad at all, versus Octave and R. On my machine, I get:
<output>
gretl took 1.454405 sec.
2.718006
Octave took 11.453040 sec.
mn = 2.7172
[1] "R took 2.894000 sec."
[1] 2.717963
</output>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3:36 p.m.
Am 10.02.2018 um 15:01 schrieb Riccardo (Jack) Lucchetti:
On Sat, 10 Feb 2018, Artur Tarassow wrote:
IMHO, this is one of the cases when teh JIT approach gives a huge
performance boost;
I agree.
gretl took 1.454405 sec.
2.718006
On my oldish machine for input 10^6:
- gretl takes 2.7 secs
- Python (with numpy.random.uniform): 4.8 secs
- Python + Numba's just-in-time compilation (using the @jit decorator):
0.17 secs!
I don't have Julia here, but to compare this to Artur's numbers who used
10^7:
- gretl: 28 secs
- Python + Numba jit: 0.48 secs
So if Julia really is 100x faster than gretl here, Python+jit might be
just a little slower, being only 60x faster. (Note however that I only
have the free numba which uses llvmlite in the background I think;
Numbapro might be even faster, don't know.)
cheers,
sven
4:26 p.m.
Just my 2 cents,
Even without experimenting, I raise the question of different speeds for
the random generators (like randgen1). And also if we are comparing the
total time (suspect that JIT will increase setup time).
On Sat, Feb 10, 2018 at 3:36 PM, Sven Schreiber <svetosch(a)gmx.net> wrote:
Am 10.02.2018 um 15:01 schrieb Riccardo (Jack) Lucchetti:
> On Sat, 10 Feb 2018, Artur Tarassow wrote:
>
IMHO, this is one of the cases when teh JIT approach gives a huge
> performance boost;
>
I agree.
gretl took 1.454405 sec.
> 2.718006
>
On my oldish machine for input 10^6:
- gretl takes 2.7 secs
- Python (with numpy.random.uniform): 4.8 secs
- Python + Numba's just-in-time compilation (using the @jit decorator):
0.17 secs!
I don't have Julia here, but to compare this to Artur's numbers who used
10^7:
- gretl: 28 secs
- Python + Numba jit: 0.48 secs
So if Julia really is 100x faster than gretl here, Python+jit might be
just a little slower, being only 60x faster. (Note however that I only have
the free numba which uses llvmlite in the background I think; Numbapro
might be even faster, don't know.)
cheers,
sven
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
*My Favorite Open Source Projects awsome-lists
<https://github.com/sindresorhus/awesome> gretl
<http://gretl.sourceforge.net/> meld <http://meldmerge.org/> robotframework
<http://robotframework.org/> wxPython <https://wxpython.org/>*
7:15 p.m.
Am 10.02.2018 um 17:26 schrieb Hélio Guilherme:
Just my 2 cents,
Even without experimenting, I raise the question of different speeds for
the random generators (like randgen1).
Well, the speed of the RNG is part of the language in a sense. But I
think you're right that one should control for the _quality_ of the
resulting random numbers. Because a bad RNG could be much faster than a
good one. However, somehow I doubt that Julia has a bad RNG (but I don't
know).
total time (suspect that JIT will increase setup time).
Yes, that is why the the jit-version of python takes 0.17s for 10^6, but
only 0.48s for 10^7, so less than 3 times longer for 10 times more stuff
to do. So it's already in there. Today's jits technology is really quite
remarkable.
cheers,
sven
6:19 p.m.
Thank you all for your replies. It's amazing to see what JIT can
actually do.
But given that, at least in my view, gretl's natural competitors are R
and Eviews (and to a certain degree Octave/MATLAB) rather than
specialized software for numerical simulations or related stuff, I am
happy that gretl beats R, Octave and even Python (ok w.o. JIT) in this
task ;-)
Btw, I've just received the following link which may be of interest for
further competitions: https://modelingguru.nasa.gov/docs/DOC-2625
Best,
Artur
Am 10.02.2018 um 16:36 schrieb Sven Schreiber:
Am 10.02.2018 um 15:01 schrieb Riccardo (Jack) Lucchetti:
> On Sat, 10 Feb 2018, Artur Tarassow wrote:
> IMHO, this is one of the cases when teh JIT approach gives a huge
> performance boost;
I agree.
> gretl took 1.454405 sec.
> 2.718006
On my oldish machine for input 10^6:
- gretl takes 2.7 secs
- Python (with numpy.random.uniform): 4.8 secs
- Python + Numba's just-in-time compilation (using the @jit decorator):
0.17 secs!
I don't have Julia here, but to compare this to Artur's numbers who used
10^7:
- gretl: 28 secs
- Python + Numba jit: 0.48 secs
So if Julia really is 100x faster than gretl here, Python+jit might be
just a little slower, being only 60x faster. (Note however that I only
have the free numba which uses llvmlite in the background I think;
Numbapro might be even faster, don't know.)
cheers,
sven
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
11:28 p.m.
Am 10.02.2018 um 19:19 schrieb Artur Tarassow:
Thank you all for your replies. It's amazing to see what JIT can
actually do.
To follow up on this, I'm attaching a hansl function (plus a test case)
that internally uses (via a foreign block) a Python+Numba installation
to do the JITting, and which works for me here. BTW, to have Python's
syntax coloring in the foreign block is just great!
I think some hybrid computing like this is the way to go if in real life
you have some loop-heavy function that is slow and which can't be
accelerated by vectorization of better use of built-in functions. To put
together the necessary few lines of Python code is usually doable I'd say.
Of course there's a noticeable overhead here because some temporary
files are read and written, and you have the python startup plus the
just-in-time compilation. All this is less than 1sec and for practical
purposes this is really negligible compared to the speedup, if you don't
need to call the function too often.
I'd be interested in an analogous solution for Julia in a foreign block!
cheers,
sven
8:51 a.m.
Am 12.02.2018 um 00:28 schrieb Sven Schreiber:
I'd be interested in an analogous solution for Julia in a foreign
block!
OK, responding to myself, since Julia is close enough to Python to get
this done quickly. Attached is an extended version of the JIT tests with
foreign.
Allin, it seems there is a problem in gretl_io.jl in the gretl_export
function. AFAICS 'size(M)' will be empty in Julia for a scalar M, and
therefore the assignment 'r,c = size(M)' fails then. I'm not Julia savvy
enough yet to send a clean solution. (I worked around it by putting the
result into a dummy matrix before calling gretl_export.)
Whether Python or Julia is faster seems to depend on the problem size:
1) With 10^7:
Python / Numba
This took = 0.923493 sec.
mn = 2.7182583
Now Julia
This took = 1.346360 sec.
mn = 2.7183726
2) With 10^8:
Python / Numba
This took = 3.780052 sec.
mn = 2.7182127
Now Julia
This took = 2.689789 sec.
mn = 2.7184079
Apparently the one-time overhead is higher for Julia, and then at some
point it overtakes Python. Very interesting.
cheers,
sven
9:55 a.m.
Am 12.02.2018 um 09:51 schrieb Sven Schreiber:
OK, responding to myself, since Julia is close enough to Python to
get
this done quickly. Attached is an extended version of the JIT tests with
foreign.
Yet another self-response, sorry! But before I forget, this could
perhaps become the illustration in section 44.3 of the guide where it
currently says "TO BE WRITTEN".
cheers,
sven
2:43 a.m.
On Mon, 12 Feb 2018, Sven Schreiber wrote:
Am 12.02.2018 um 09:51 schrieb Sven Schreiber:
> OK, responding to myself, since Julia is close enough to Python
> to get this done quickly. Attached is an extended version of the
> JIT tests with foreign.
Yet another self-response, sorry! But before I forget, this could
perhaps become the illustration in section 44.3 of the guide where
it currently says "TO BE WRITTEN".
I'd very much like to fill in that unwritten slot, but I'd prefer
that it contain a "live" example, from an econometric point of view.
And I'm afraid we're not there yet. Your example is the closest so
far, but it's still artificial: if one wanted to calculate Euler's
'e' from scratch one could do so in hansl very much faster than by
generating random variates.
<hansl>
function scalar eulerJITjl (int n)
mwrite({n}, "ntransf.mat", 1)
foreign language=julia
function euler(n)
m = 0
for i = 1:n
the_sum = 0.0
while true
m += 1
the_sum += rand()
(the_sum>1.0) && break;
end
end
m/n
end
n = gretl_loadmat("ntransf.mat")[1]
gretl_export(fill(euler(n),1,1), "jl.mat")
end foreign
return mread("jl.mat", 1)
end function
function scalar euler (int n)
scalar m = 0
loop i=1..n -q
scalar s = 0.0
loop while s <= 1 -q
m++
s += randgen1(u,0,1)
endloop
endloop
return m/n
end function
function scalar alt_euler (int n)
scalar e = 2
loop i=2..n -q
e += 1/gamma(i+1)
endloop
return e
end function
set verbose off
scalar n = 10^6
set stopwatch
printf "Julia: %.8f (time %gs)\n", eulerJITjl(n), $stopwatch
printf "Native: %.8f (time %gs)\n", euler(n), $stopwatch
printf "alt gretl: %.8f (time %gs)\n", alt_euler(20), $stopwatch
</hansl>
<output>
Julia: 2.71788600 (time 1.18078s)
Native: 2.71811500 (time 2.02987s)
alt gretl: 2.71828183 (time 0.00012595s)
</output>
But given how fast Julia is at generating random floating-point
values, it seems to me there should be a real live example not far
off.
Allin
9:07 a.m.
Am 13.02.2018 um 03:43 schrieb Allin Cottrell:
On Mon, 12 Feb 2018, Sven Schreiber wrote:
> Yet another self-response, sorry! But before I forget, this could
> perhaps become the illustration in section 44.3 of the guide where it
> currently says "TO BE WRITTEN".
I'd very much like to fill in that unwritten slot, but I'd prefer that
it contain a "live" example, from an econometric point of view. And I'm
afraid we're not there yet. Your example is the closest so far, but it's
still artificial:
Of course the example is very artificial, it was never meant by anybody
(I believe) to be a serious calculation, just a crazy horserace.
But it's a very good point that the guide should contain something
"real". What about a contestant of the stationary bootstrap package
SB.gfn? That's something where I would expect some major value added
(but it remains to be seen...).
one could do so in hansl very much faster than by generating random
variates.
Obviously! As I said, I don't think it was anybody's point to really
calculate Euler's number.
<output>
Julia: 2.71788600 (time 1.18078s)
Native: 2.71811500 (time 2.02987s)
However, let me repeat Artur's (and Henrique's) observation here that
you will see a bigger divergence between Julia and Native when you
replace 10^6 with 10^7 or 10^8; the Native implementation will just
scale up linearly, but not the JITted Julia version.
alt gretl: 2.71828183 (time 0.00012595s)
Unfair! ;-)
But given how fast Julia is at generating random floating-point
values,
it seems to me there should be a real live example not far off.
Yes. Again, I suggest to tackle the SB.gfn package as a benchmark.
cheers,
sven
5:23 p.m.
On Tue, 13 Feb 2018, Sven Schreiber wrote:
Am 13.02.2018 um 03:43 schrieb Allin Cottrell:
> <output>
> Julia: 2.71788600 (time 1.18078s)
> Native: 2.71811500 (time 2.02987s)
However, let me repeat Artur's (and Henrique's) observation here that
you will see a bigger divergence between Julia and Native when you
replace 10^6 with 10^7 or 10^8; the Native implementation will just
scale up linearly, but not the JITted Julia version.
Yes, that's certainly noteworthy.
> alt gretl: 2.71828183 (time 0.00012595s)
Unfair! ;-)
Of course.
> But given how fast Julia is at generating random floating-point
values,
> it seems to me there should be a real live example not far off.
Yes. Again, I suggest to tackle the SB.gfn package as a benchmark.
Would make an interesting test case.
Allin
11:58 p.m.
On Mon, 12 Feb 2018, Sven Schreiber wrote:
Am 12.02.2018 um 00:28 schrieb Sven Schreiber:
> I'd be interested in an analogous solution for Julia in a foreign block!
OK, responding to myself, since Julia is close enough to Python to get this
done quickly. Attached is an extended version of the JIT tests with foreign.
Allin, it seems there is a problem in gretl_io.jl in the gretl_export
function. AFAICS 'size(M)' will be empty in Julia for a scalar M, and
therefore the assignment 'r,c = size(M)' fails then.
The gretl_export() function for Julia is explicitly designed for
matrices. But given a scalar x one could do
gretl_export(fill(x,1,1), "x.mat")
(I'm not aware of any equivalent of R's "as.matrix" in Julia.)
Allin
2509
days inactive
2512
days old
13 comments
6 participants
participants (6)
-
Allin Cottrell -
Artur Tarassow -
Hélio Guilherme -
Marcin Błażejowski -
Riccardo (Jack) Lucchetti -
Sven Schreiber