 | | From: | Michael Park | | Subject: | (gforth) Relieved to learn that ekey? is slow | | Date: | 19 Jan 2005 16:58:38 -0800 |
|
|
 | Well, maybe relieved isn't quite the right word.
I have a gforth program and a c# program that do basically the same
thing, and I was quite disappointed that the gforth program's speed was
about 1/100 the c# program's. I finally realized that I was calling
ekey? inside a tight loop; taking ekey? out sped the program up to
about 2/3 the speed of the c# version, which seems much more reasonable
to me.
So that was an easy fix, but it does make me wonder why ekey? is so
slow. I was using ekey? because I wanted to watch for F1 (e.g.) during
the loop; is there a faster alternative?
m
|
|
| | From: | Jorge Acereda | | Subject: | Re: (gforth) Relieved to learn that ekey? is slow | | Date: | Thu, 20 Jan 2005 02:10:11 +0100 |
|
|
| On 19 Jan 2005 16:58:38 -0800, Michael Park wrote:
> Well, maybe relieved isn't quite the right word.
> I have a gforth program and a c# program that do basically the same
> thing, and I was quite disappointed that the gforth program's speed was
> about 1/100 the c# program's. I finally realized that I was calling
> ekey? inside a tight loop; taking ekey? out sped the program up to
> about 2/3 the speed of the c# version, which seems much more reasonable
> to me.
> So that was an easy fix, but it does make me wonder why ekey? is so
> slow. I was using ekey? because I wanted to watch for F1 (e.g.) during
> the loop; is there a faster alternative?
Sure,
0 value times
: faster-ekey?
times if 0 else ekey? 100 to times then times 1- to times ;
Greetings,
Jorge Acereda
|
|
| | From: | Bruce McFarling | | Subject: | Re: (gforth) Relieved to learn that ekey? is slow | | Date: | 20 Jan 2005 22:17:51 -0800 |
|
|
|
Bernd Paysan wrote:
> Michael Park wrote:
> > So that was an easy fix, but it does make me wonder why ekey? is so
> > slow. I was using ekey? because I wanted to watch for F1 (e.g.)
during
> > the loop; is there a faster alternative?
>
> Hm, some measurements show me that Gforth can do less than a million
KEY?s
> per second. bigFORTH, when used from the console, is exactly as fast
(no
> wonder, it does the same thing: ask the OS if there's any data in the
pty
> file descriptor). The GUI version of bigFORTH is 6 times faster. How
comes?
> Easy to explain: The GUI polling operation is *much more* expensive
than
> the file polling operation, so I do it only every 20 or 30
milliseconds.
> The time in between, KEY? only checks if it's time to do the
expensive
> operation.
In other words, something along the lines of Jorge Acereda's approach
is built in?
|
|
| | From: | Bernd Paysan | | Subject: | Re: (gforth) Relieved to learn that ekey? is slow | | Date: | Fri, 21 Jan 2005 11:22:48 +0100 |
|
|
| Bruce McFarling wrote:
> In other words, something along the lines of Jorge Acereda's approach
> is built in?
Exactly.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
|
|
| | From: | Jorge Acereda | | Subject: | Re: (gforth) Relieved to learn that ekey? is slow | | Date: | Thu, 20 Jan 2005 20:42:19 +0100 |
|
|
| On 20 Jan 2005 10:52:30 -0800, Michael Park wrote:
>
> Jorge Acereda wrote:
> ...
> > 0 value times
> > : faster-ekey?
> > times if 0 else ekey? 100 to times then times 1- to times ;
> >
> > Greetings,
> > Jorge Acereda
>
> Of course! Thanks.
> Any particular reason you made times a value rather than a variable?
A reason could be that I use a non-optimizing direct-threaded
interpreter and tend to think in terms of primitives. For this
example, using a value saves one.
times ... times 1- to times
dovalue ... dovalue 1- doto (4 primitives)
times @ ... -1 times +!
dovar @ ... dolit dovar +! (5 primitives)
But no, I wasn't thinking about that, it just came out that way :-)
Anyway, I tend to prefer values for things that are frequently
accessed and rarely stored.
Jorge Acereda
|
|
| | From: | Michael Park | | Subject: | Re: (gforth) Relieved to learn that ekey? is slow | | Date: | 20 Jan 2005 10:52:30 -0800 |
|
|
|
Jorge Acereda wrote:
....
> 0 value times
> : faster-ekey?
> times if 0 else ekey? 100 to times then times 1- to times ;
>
> Greetings,
> Jorge Acereda
Of course! Thanks.
Any particular reason you made times a value rather than a variable?
|
|
| | From: | Bernd Paysan | | Subject: | Re: (gforth) Relieved to learn that ekey? is slow | | Date: | Thu, 20 Jan 2005 15:41:58 +0100 |
|
|
| Michael Park wrote:
> So that was an easy fix, but it does make me wonder why ekey? is so
> slow. I was using ekey? because I wanted to watch for F1 (e.g.) during
> the loop; is there a faster alternative?
Hm, some measurements show me that Gforth can do less than a million KEY?s
per second. bigFORTH, when used from the console, is exactly as fast (no
wonder, it does the same thing: ask the OS if there's any data in the pty
file descriptor). The GUI version of bigFORTH is 6 times faster. How comes?
Easy to explain: The GUI polling operation is *much more* expensive than
the file polling operation, so I do it only every 20 or 30 milliseconds.
The time in between, KEY? only checks if it's time to do the expensive
operation.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
|
|
