From: Simon W. <si...@ge...> - 2012-09-28 07:28:58
|
Dear All, I noticed that summing a lot of rounded numbers takes a lot of time in the jlisp version but not in the psl nor in the csl version. For example "<<on rounded; for i:1:100000 sum sqrt(i)>>;" takes in the psl version about four seconds, in the csl version less than three seconds but in the jlisp version more than one minute. Does anybody know or have an intuition why this takes so long? Is it possible to improve the speed of the sum significantly, and what can be done do so? Many thanks, Simon PS: I tried "<<on rounded; a:= for i:=1:100000 collect sqrt i; aeval(part(a,0):=plus)>>;" too but this is even slower. |
From: Arthur N. <ac...@ca...> - 2012-09-28 09:15:35
|
Jlisp is coded in Java and all data types are handled as Java objects in a neat class hierarchy and with any and all overheads that Java introduces. Integer arithmetic is done using values that are boxed within a Java class, since there is no obvious way to hold immediate values. CSL is coded in C and PSL is in Lisp that it compiles directly down to machine code. Both will handle modest sized integers a LOT faster. While they still box floats they have storage management tunes for what they expect to happen in Lisp and will have a lot less overhead than Jlisp. In general I always expect Jlisp to be substantially slower than the "real" Lisps. However one thing that MIGHT be causing confusion is that in Jlisp the time() function records wall-clock time, so if you test from the keyboard you get the time it takes you to type stuff in included. When I last looked Java did not provide a useful CPU time enquiry. But yes, on my machine I observe a factor of about 25 between jlisp and CSL on that. And I see similar slowness if I go "precision 20" so that Reduce is using bigfloats not native ones, so it is not just floating point as such. If I try a pure Lisp-level test of numerics as in lisp; q := 0; on time; for i := 1:3000 do for j :=1:3000 do q := remainder(q + i*j, 1234567); I see a factor of 20 in time difference between CSL and Jlisp, so this is down to the costs of general arithmetic. I know I put a lot of effort into CSL arithmetic with around 15000 lines of C to do it. In Jlisp because numbers have to be just a subclass of LispObject everything is boxed. I use method dispatch to cope with the dispatch when I have a potential mix of LispSmallInteger, LispBigInteger and floating values - and I have little scope (that I can think of) to optimise for the most common cases. So at present my belief is that this is one of the worst cases of overheap because of use of Java and i do not know how to speed it up. I will provide some potentially less helpful comments and your response may depend on how much of a show-stopper this is... (a) there are Java profiling tools that I have hardly ever used and that I am not up to data on - but maybe they would let you really track down exactlly where the time is going. If it is just in all the uses of "new" then you may be out of luck, but maybe it would give you more reliable info than my guesses here. (b) where speed matters I would always prefer CSL to Jlisp, and the "embedded" variant is aimed at being easier to build for interfacing than the regular version that often gets built with a GUI. One could IMAGINE wrapping that as Java native methods if necessary! (c) It could be that manually in-lining some methods in Jlisp would really help, but (a) would be needed first to track down what was the hottest spot to hit. Arthur On Fri, 28 Sep 2012, Simon Weitzhofer wrote: > Dear All, > > I noticed that summing a lot of rounded numbers takes a lot of time in > the jlisp version but not in the psl nor in the csl version. > For example "<<on rounded; for i:1:100000 sum sqrt(i)>>;" takes in the > psl version about four seconds, in the csl version less than three > seconds but in the jlisp version more than one minute. > > Does anybody know or have an intuition why this takes so long? Is it > possible to improve the speed of the sum significantly, and what can be > done do so? > > Many thanks, > Simon > > PS: I tried "<<on rounded; a:= for i:=1:100000 collect sqrt i; > aeval(part(a,0):=plus)>>;" too but this is even slower. > |
From: Andrey G. G. <A.G...@in...> - 2012-09-29 11:47:40
|
In the current reduce (svn 1759), if I say load_package specfn; int(exp(-x^2),x,0,infinity); this produces sqrt(pi)*erf(infinity) ------------------------ 2 If I don't load specfn, I get sqrt(pi) ---------- 2 So, loading specfn reduces the quality :-( Can this be avoided? Andrey |
From: Rainer S. <rai...@gm...> - 2012-09-29 12:11:18
|
On Sat, 29 Sep 2012 at 18:30 +0700, Andrey G. Grozin wrote: > In the current reduce (svn 1759), if I say > > load_package specfn; int(exp(-x^2),x,0,infinity); > > this produces > > sqrt(pi)*erf(infinity) > ------------------------ > 2 > > If I don't load specfn, I get > > sqrt(pi) > ---------- > 2 > > So, loading specfn reduces the quality :-( Can this be avoided? Yes. The problem are these two rules in the specfn package: int(1/e^(~tt^2),~tt,0,~z) => erf(z)/2*sqrt(pi), int(1/e^(~tt^2),~tt,~z,infinity) => erfc(z)/2*sqrt(pi), which are used even if z is infinity. The obvious solution is to replace them by int(1/e^(~tt^2),~tt,0,~z) => erf(z)/2*sqrt(pi) when z freeof infinity, int(1/e^(~tt^2),~tt,~z,infinity) => erfc(z)/2*sqrt(pi) when z freeof infinity I'll make the change later today. Rainer |
From: Arthur N. <ac...@ca...> - 2012-09-29 12:39:36
|
I note that int(exp(-x^2),x,y,infinity) seems to yield sqrt(pi)*(-erf(y)+1)/2 for me when I have specfn loaded, and then when I substitute y=0 it tidies up nicely. So I guess it will be possible but Term is just about to start here and I will be rather loaded for the coming week - I hoep to look into it after that. Arthur On Sat, 29 Sep 2012, Andrey G. Grozin wrote: > In the current reduce (svn 1759), if I say > > load_package specfn; int(exp(-x^2),x,0,infinity); > > this produces > > sqrt(pi)*erf(infinity) > ------------------------ > 2 > > If I don't load specfn, I get > > sqrt(pi) > ---------- > 2 > > So, loading specfn reduces the quality :-( Can this be avoided? > > Andrey > |