unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Floating Point?
@ 2003-09-06 18:10 Peter S. Christopher
  2003-09-08 14:43 ` Betoes
  0 siblings, 1 reply; 6+ messages in thread
From: Peter S. Christopher @ 2003-09-06 18:10 UTC (permalink / raw)


Hi there listers,

	I've been thinking about how to make my floating point
calculations go faster. I thought that my FP calculations where so slow
because of excessive allocation. i.e. if a and b are floats then 
(+ a b) will return a *NEW* float with the value a+b in it. Is this
true? If this where true I thought that I could speed up my calculations
by replacing the normal operands (+,-,*,/) by versions that don't allocate
new cells (a-la (reg+, reg-, reg*, reg/)). Something like

(reg+ temp_1 a b) 

would evaluate to 

SCM_REAL_VALUE(temp_1) = 	
    scm_num2dbl(a, FUNC_NAME)+scm_num2dbl(b, FUNC_NAME);

in some C extension function. This would prevent the allocation of the
additional doubles. The real advantage, of course, would be in expressions
like

(let ((register-1 0.0))
   (do ((i 0 (+ i 1))
       ((> i big-huge-number))
     (set-my-double-array i
       (reg+ register-1 5.7 (reg* register-1 3.1 i))))))

where this loop sets element i of my-double-array to 3.1*i+5.7. By my
reasoning (which may be suspect) this would save me many-many cell
allocations (2*big-huge-number to be exact).

	So how far off base am I? And, does anyone have other ideas on how
to improve my floating point performance (within the guile world that is).

Thanks for any help,
Pete Christopher



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Floating Point?
  2003-09-06 18:10 Floating Point? Peter S. Christopher
@ 2003-09-08 14:43 ` Betoes
  2003-09-09  7:52   ` tomas
  0 siblings, 1 reply; 6+ messages in thread
From: Betoes @ 2003-09-08 14:43 UTC (permalink / raw)


On Sat, Sep 06, 2003 at 01:10:21PM -0500, Peter S. Christopher wrote:
> Hi there listers,
> 
> 	I've been thinking about how to make my floating point
> calculations go faster. I thought that my FP calculations where so slow

I have doubt about the speed of floating point calculations too, but
because of arbitrary precision of guile floating point
arthmetics... Does it have a way to turn off this feature? Does it
really have influence on speedy calculations?

Redefinitions of math functions would be woth, but an expensive way to
increase such speed...

Any idea?

> because of excessive allocation. i.e. if a and b are floats then 
> (+ a b) will return a *NEW* float with the value a+b in it. Is this
> true? If this where true I thought that I could speed up my calculations
> by replacing the normal operands (+,-,*,/) by versions that don't allocate
> new cells (a-la (reg+, reg-, reg*, reg/)). Something like
> 
> (reg+ temp_1 a b) 
> 
> would evaluate to 
> 
> SCM_REAL_VALUE(temp_1) = 	
>     scm_num2dbl(a, FUNC_NAME)+scm_num2dbl(b, FUNC_NAME);
> 
> in some C extension function. This would prevent the allocation of the
> additional doubles. The real advantage, of course, would be in expressions
> like
> 
> (let ((register-1 0.0))
>    (do ((i 0 (+ i 1))
>        ((> i big-huge-number))
>      (set-my-double-array i
>        (reg+ register-1 5.7 (reg* register-1 3.1 i))))))
> 
> where this loop sets element i of my-double-array to 3.1*i+5.7. By my
> reasoning (which may be suspect) this would save me many-many cell
> allocations (2*big-huge-number to be exact).
> 
> 	So how far off base am I? And, does anyone have other ideas on how
> to improve my floating point performance (within the guile world that is).
> 
> Thanks for any help,
> Pete Christopher


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Floating Point?
  2003-09-08 14:43 ` Betoes
@ 2003-09-09  7:52   ` tomas
  2003-09-09  9:26     ` David Allouche
  0 siblings, 1 reply; 6+ messages in thread
From: tomas @ 2003-09-09  7:52 UTC (permalink / raw)
  Cc: guile-user

On Mon, Sep 08, 2003 at 11:43:59AM -0300, Betoes wrote:
> On Sat, Sep 06, 2003 at 01:10:21PM -0500, Peter S. Christopher wrote:
> > Hi there listers,
> > 
> > 	I've been thinking about how to make my floating point
> > calculations go faster. I thought that my FP calculations where so slow
> 
> I have doubt about the speed of floating point calculations too, but
> because of arbitrary precision of guile floating point
> arthmetics... Does it have a way to turn off this feature? Does it
> really have influence on speedy calculations?

No. Arbitrary precision is for integers (it's impossible to do general
arbitrary precision for reals). Floats in Guile are just machine floats
(properly wrapped as SCMs, which might make them a tad `slower', though).

If I see right, they are just machine doubles, referenced indirectly
through the SCM object (thus the unwrapping costs you a dereference).

Please correct me someone more in the know.

Regards
-- tomas


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Floating Point?
  2003-09-09  7:52   ` tomas
@ 2003-09-09  9:26     ` David Allouche
  2003-09-09 14:34       ` Peter S. Christopher
  0 siblings, 1 reply; 6+ messages in thread
From: David Allouche @ 2003-09-09  9:26 UTC (permalink / raw)
  Cc: Betoes, guile-user

On Tue, Sep 09, 2003 at 09:52:26AM +0200, tomas@fabula.de wrote:
> No. Arbitrary precision is for integers (it's impossible to do general
> arbitrary precision for reals). Floats in Guile are just machine floats
> (properly wrapped as SCMs, which might make them a tad `slower', though).
> 
> If I see right, they are just machine doubles, referenced indirectly
> through the SCM object (thus the unwrapping costs you a dereference).

Just an idea...

Python had a similar problem: the language overhead dominated
computing time in number crunching applications. This problem was
solved by the implementation of a fast (written in C) matrix crunching
library. The basic idea is "to add 1000 FP numbers, add two matrices
and let the looping be done in C instead of in Scheme". Of course, the
usual collection of algebra is also a nice bonus.

Now, Python, though well known as a generally slow language is
successfully used in many demanding number-crunching applications.

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://savannah.gnu.org/projects/texmacs
   david@allouche.net  |    allouche@texmacs.org
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Floating Point?
  2003-09-09  9:26     ` David Allouche
@ 2003-09-09 14:34       ` Peter S. Christopher
  2003-09-09 21:15         ` Robert Uhl
  0 siblings, 1 reply; 6+ messages in thread
From: Peter S. Christopher @ 2003-09-09 14:34 UTC (permalink / raw)



As I mentioned in my last e-mail, I tried the python-approach and it does
give some nice performance enhancements. My problem with it is that it's
fairly awkward even for some relatively easy algorithms. I think (unless
anyone has any ideas;-}) it is as good as we'll get unless/until GUILE
becomes a compiled language. (In this later case, one could imagine
embedding special forms that allow fast array loops and other fancy
enhancments).  

Pete

On Tue, 9 Sep 2003, David Allouche wrote:

> On Tue, Sep 09, 2003 at 09:52:26AM +0200, tomas@fabula.de wrote:
> > No. Arbitrary precision is for integers (it's impossible to do general
> > arbitrary precision for reals). Floats in Guile are just machine floats
> > (properly wrapped as SCMs, which might make them a tad `slower', though).
> > 
> > If I see right, they are just machine doubles, referenced indirectly
> > through the SCM object (thus the unwrapping costs you a dereference).
> 
> Just an idea...
> 
> Python had a similar problem: the language overhead dominated
> computing time in number crunching applications. This problem was
> solved by the implementation of a fast (written in C) matrix crunching
> library. The basic idea is "to add 1000 FP numbers, add two matrices
> and let the looping be done in C instead of in Scheme". Of course, the
> usual collection of algebra is also a nice bonus.
> 
> Now, Python, though well known as a generally slow language is
> successfully used in many demanding number-crunching applications.
> 
> -- 
> David Allouche         | GNU TeXmacs -- Writing is a pleasure
> Free software engineer |    http://www.texmacs.org
>    http://ddaa.net     |    http://savannah.gnu.org/projects/texmacs
>    david@allouche.net  |    allouche@texmacs.org
> TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user
> 



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Floating Point?
  2003-09-09 14:34       ` Peter S. Christopher
@ 2003-09-09 21:15         ` Robert Uhl
  0 siblings, 0 replies; 6+ messages in thread
From: Robert Uhl @ 2003-09-09 21:15 UTC (permalink / raw)


"Peter S. Christopher" <peterc@midway.uchicago.edu> writes:
>
> As I mentioned in my last e-mail, I tried the python-approach and it
> does give some nice performance enhancements.  My problem with it is
> that it's fairly awkward even for some relatively easy algorithms.  I
> think (unless anyone has any ideas;-}) it is as good as we'll get
> unless/until GUILE becomes a compiled language.  (In this later case,
> one could imagine embedding special forms that allow fast array loops
> and other fancy enhancments).

That way lies Common Lisp.  Which isn't all that bad a thing.  Richard
P. Gabriel's Lisp: Good News, Bad News, How to Win Big
<http://www.dreamsongs.com/WIB.html> has made me rethink some of my
previous thoughts on CL.  It needs to be more like Scheme in some ways,
but Scheme could stand to be more like Common Lisp in a lot of ways,
IMHO.

-- 
Robert Uhl <ruhl@4dv.net>
Certain televangelists would have you believe Christianity is a bland
respectable religion suitable for the suburbs.  They are mistaken.
                                                --Patrick R. Wade


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-09-09 21:15 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-06 18:10 Floating Point? Peter S. Christopher
2003-09-08 14:43 ` Betoes
2003-09-09  7:52   ` tomas
2003-09-09  9:26     ` David Allouche
2003-09-09 14:34       ` Peter S. Christopher
2003-09-09 21:15         ` Robert Uhl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).