Groups > comp.lang.forth > #20463

Re: pde2 floating point benchmark code

Path	csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder3.xlned.com!news2.euro.net!postnews2.euro.net!news.wanadoo.nl!not-for-mail
From	mhx@iae.nl (Marcel Hendrix)
Subject	Re: pde2 floating point benchmark code
Newsgroups	comp.lang.forth
Message-ID	<03991495008434@frunobulax.edu> (permalink)
Date	Fri, 8 Mar 2013 21:04:00 +0200
References	<d1ab93ec-911b-4b46-8b3e-87a9d05d018f@l16g2000yqe.googlegroups.com>
X-Newsreader	iForth 2.0 console (October 21, 2006)
Lines	66
Organization	Wanadoo
NNTP-Posting-Date	08 Mar 2013 20:03:43 GMT
NNTP-Posting-Host	s529d937f.adsl.online.nl
X-Trace	1362773023 dr4.euro.net 9195 82.157.147.127:55595
X-Complaints-To	abuse@wanadoo.nl
Xref	csiph.com comp.lang.forth:20463

Show key headers only | View raw

Krishna Myneni <krishna.myneni@ccreweb.org> writes Re: pde2 floating point benchmark code

> On Mar 8, 12:32am, humptydumpty <ouat...@gmail.com> wrote:
[..]

> That's certainly an interesting approach for this problem, to unroll
> the inner loop. A factor of two speedup is significant -- it may not
> hold up for a native code compiler, where the loop overhead is likely
> to be substantially lower. 

Not because of the loop overhead, but because the indexed
address is calculated at compile time.

FORTH> see fiberONE
Flags: ANSI
$0140DE00  : fiberONE
$0140DE0A  fld           $01405130 tbyte-offset
$0140DE10  fld           $014098D0 qword-offset
$0140DE16  fld           $014098C0 qword-offset
$0140DE1C  faddp         ST(1), ST
$0140DE1E  fmulp         ST(1), ST
$0140DE20  fld           $014098C8 qword-offset
$0140DE26  fld           $01405150 tbyte-offset
$0140DE2C  fmulp         ST(1), ST
$0140DE2E  faddp         ST(1), ST
$0140DE30  fstp          $0140B828 qword-offset
$0140DE36  fld           $01405130 tbyte-offset
$0140DE3C  fld           $014098D8 qword-offset
... etcetera.

> For raw speed improvement, I would consider
> writing the inner loop as an assembler code word. That should provide
> a huge improvement on indirect threaded code systems. Also, I found
> that replacing the array indexing with simpler pointer arithmetic in
> the inner loop also led to close to a factor of two improvement.

Or use a different Forth, when speed is really a concern :-)

> However, speed is only one concern with this method of calculation.
> The grid size, set by dt and dx, must be small to obtain reasonable
> accuracy of the solution, even for short time intervals such as t = 1.

Yes, that is really a problem. What is the error of this method?

FORTH> in
nx: 1001
fiber size:44008

0.135 seconds elapsed.
0.059 seconds elapsed. ok

| Output:
| ~/wrk <> gforth-fast pde.fs
| redefined DT with dt 
| nx: 1001
| fiber size:87940

| 1451235
| 1116868

Microseconds, so 1.451 and 1.117 seconds. 
Amazingly, the Gforth code is almost twice *larger* than iForth native code.

-marcel

Thread

pde2 floating point benchmark code krishna.myneni@ccreweb.org - 2013-03-04 18:02 -0800
  Re: pde2 floating point benchmark code Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-04 23:23 -0800
    Re: pde2 floating point benchmark code krishna.myneni@ccreweb.org - 2013-03-05 05:22 -0800
  Re: pde2 floating point benchmark code Doug Hoffman <glidedog@gmail.com> - 2013-03-05 12:11 -0500
    Re: pde2 floating point benchmark code krishna.myneni@ccreweb.org - 2013-03-05 16:11 -0800
      Re: pde2 floating point benchmark code Doug Hoffman <glidedog@gmail.com> - 2013-03-06 04:26 -0500
        Re: pde2 floating point benchmark code krishna.myneni@ccreweb.org - 2013-03-06 05:22 -0800
          Re: pde2 floating point benchmark code Doug Hoffman <glidedog@gmail.com> - 2013-03-06 09:44 -0500
  Re: pde2 floating point benchmark code krishna.myneni@ccreweb.org - 2013-03-05 16:17 -0800
    Re: pde2 floating point benchmark code mhx@iae.nl (Marcel Hendrix) - 2013-03-06 23:06 +0200
      Re: pde2 floating point benchmark code krishna.myneni@ccreweb.org - 2013-03-07 04:57 -0800
        Re: pde2 floating point benchmark code m.a.m.hendrix@tue.nl - 2013-03-07 05:49 -0800
        Re: pde2 floating point benchmark code mhx@iae.nl (Marcel Hendrix) - 2013-03-07 21:12 +0200
          Re: pde2 floating point benchmark code krishna.myneni@ccreweb.org - 2013-03-07 16:07 -0800
      Re: pde2 floating point benchmark code Doug Hoffman <glidedog@gmail.com> - 2013-03-10 09:17 -0400
        Re: pde2 floating point benchmark code mhx@iae.nl (Marcel Hendrix) - 2013-03-10 18:33 +0200
          Re: pde2 floating point benchmark code Doug Hoffman <glidedog@gmail.com> - 2013-03-11 04:54 -0400
    Re: pde2 floating point benchmark code humptydumpty <ouatubi@gmail.com> - 2013-03-07 22:32 -0800
      Re: pde2 floating point benchmark code Krishna Myneni <krishna.myneni@ccreweb.org> - 2013-03-08 05:19 -0800
        Re: pde2 floating point benchmark code mhx@iae.nl (Marcel Hendrix) - 2013-03-08 21:04 +0200
          Re: pde2 floating point benchmark code Krishna Myneni <krishna.myneni@ccreweb.org> - 2013-03-08 16:31 -0800
            Re: pde2 floating point benchmark code Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-09 00:56 +0000
              Re: pde2 floating point benchmark code Krishna Myneni <krishna.myneni@ccreweb.org> - 2013-03-08 19:52 -0800
                Re: pde2 floating point benchmark code Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-09 09:09 +0000
            Re: pde2 floating point benchmark code mhx@iae.nl (Marcel Hendrix) - 2013-03-09 13:37 +0200
              Re: pde2 floating point benchmark code Krishna Myneni <krishna.myneni@ccreweb.org> - 2013-03-09 06:28 -0800
              Re: pde2 floating point benchmark code mhx@iae.nl (Marcel Hendrix) - 2013-03-09 17:58 +0200
        Re: pde2 floating point benchmark code humptydumpty <ouatubi@gmail.com> - 2013-03-08 12:23 -0800
          Re: pde2 floating point benchmark code Krishna Myneni <krishna.myneni@ccreweb.org> - 2013-03-08 16:43 -0800

csiph-web