Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #12206 > unrolled thread
| Started by | quiet_lad <gavcomedy@gmail.com> |
|---|---|
| First post | 2012-05-15 23:27 -0700 |
| Last post | 2012-05-18 22:58 -0700 |
| Articles | 20 on this page of 158 — 33 participants |
Back to article view | Back to comp.lang.forth
I beleive that forth could supplant ruby and perl and python if it wanted to quiet_lad <gavcomedy@gmail.com> - 2012-05-15 23:27 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to marko <marko@marko.marko> - 2012-05-16 17:50 +1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-16 06:51 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-16 07:59 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Jason Damisch <jasondamisch@yahoo.com> - 2012-05-16 09:28 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-17 04:08 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-16 22:22 -1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "A. K." <akk@nospam.org> - 2012-05-17 11:43 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-17 10:22 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "A. K." <akk@nospam.org> - 2012-05-17 17:03 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-18 01:15 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-17 19:19 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-18 12:40 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-18 00:17 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 16:02 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "A. K." <akk@nospam.org> - 2012-05-17 18:08 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 16:58 +0000
Re: I beleive that forth could supplant ruby and perl and python if it to Nomen Nescio <nobody@dizum.com> - 2012-05-17 19:03 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 12:27 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 18:52 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:18 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 01:39 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 04:50 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 04:40 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to humptydumpty <ouatubi@gmail.com> - 2012-05-18 15:15 +0300
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-18 08:02 -1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-17 12:40 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:32 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 01:45 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-19 11:28 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Peter Knaggs" <pjk@bcs.org.uk> - 2012-05-17 21:38 +0100
Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 21:17 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-18 09:41 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 04:55 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-18 13:50 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-18 03:24 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 06:10 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-18 08:10 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Mark Wills <forthfreak@gmail.com> - 2012-05-18 05:57 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-18 08:14 -1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to John Passaniti <john.passaniti@gmail.com> - 2012-05-18 10:01 -0700
VFX code quality (was: I beleive that forth could supplant ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-18 12:58 +0000
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 09:43 -0500
Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-19 10:54 +0000
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-19 11:43 -0500
Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-22 08:26 +0000
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-22 03:52 -0500
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-22 04:02 -0500
Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-22 09:25 +0000
Re: VFX code quality Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-30 23:39 +0200
Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-31 15:07 +0000
Re: VFX code quality Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-31 20:24 +0200
Re: VFX code quality (was: I beleive that forth could supplant ...) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-18 15:25 +0000
Re: VFX code quality (was: I beleive that forth could supplant ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-19 11:31 +0000
Re: VFX code quality (was: I beleive that forth could supplant ...) Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-20 17:41 +0200
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-20 12:49 -0500
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-20 11:43 -0700
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-20 14:01 -1000
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-20 19:10 -0700
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-20 17:05 -1000
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-20 20:38 -0700
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-20 21:37 -1000
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 01:27 -0700
Re: VFX code quality m.a.m.hendrix@tue.nl - 2012-05-21 01:52 -0700
Re: VFX code quality Ecki <ecki@intershop.de> - 2012-05-21 11:06 +0200
Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-21 20:34 +0200
Re: VFX code quality Ecki <ecki@intershop.de> - 2012-05-22 08:54 +0200
Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-21 14:36 +0000
Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-21 20:33 +0200
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:29 -0500
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 08:39 -0700
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 15:22 -0500
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-22 12:47 -0700
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-22 11:25 -1000
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-23 03:19 -0500
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-24 22:51 -0700
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-24 23:16 -0700
Re: VFX code quality Fritz Wuehler <fritz@spamexpire-201205.rodent.frell.theremailer.net> - 2012-05-23 17:36 +0200
Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-21 12:57 -0400
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 08:42 -1000
Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-21 19:41 -0400
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 21:53 -0700
Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-22 07:10 -0400
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 08:36 -1000
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 21:46 -0700
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 20:30 -1000
Re: VFX code quality David Kuehling <dvdkhlng@gmx.de> - 2012-05-22 14:06 +0200
Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-22 08:59 -0400
FP locals (was: VFX code quality) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-22 13:39 +0000
Re: FP locals Doug Hoffman <glidedog@gmail.com> - 2012-05-22 14:03 -0400
Re: FP locals (was: VFX code quality) C G Montgomery <cgm@physics.utoledo.edu> - 2012-05-22 18:09 -0400
Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-23 03:47 -0700
Re: FP locals (was: VFX code quality) "Ed" <invalid@nospam.com> - 2012-05-26 21:03 +1000
Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-26 04:40 -0700
Re: FP locals (was: VFX code quality) mhx@iae.nl (Marcel Hendrix) - 2012-05-26 18:27 +0200
Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-26 12:55 -0700
Re: FP locals (was: VFX code quality) BruceMcF <agila61@netscape.net> - 2012-05-26 14:54 -0700
Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-26 22:02 -0700
Re: FP locals (was: VFX code quality) mhx@iae.nl (Marcel Hendrix) - 2012-05-27 08:50 +0200
Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-27 05:26 -0700
Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-22 09:04 -0700
Re: VFX code quality "A. K." <akk@nospam.org> - 2012-05-21 09:55 +0200
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 01:22 -0700
Re: VFX code quality "A. K." <akk@nospam.org> - 2012-05-21 14:19 +0200
Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-22 12:33 -0700
Re: VFX code quality "A. K." <akk@nospam.org> - 2012-05-22 23:14 +0200
Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-21 20:31 +0200
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 15:17 -0500
Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-21 13:50 -0700
Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-21 16:47 -0700
Re: VFX code quality "Harry Vaderchi" <admin@127.0.0.1> - 2012-05-22 09:57 +0100
Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-22 04:39 -0700
Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-23 20:25 +0200
Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-23 13:47 -0700
Re: VFX code quality humptydumpty <ouatubi@gmail.com> - 2012-05-21 20:23 +0000
Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-20 20:22 -0700
Re: VFX code quality Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-21 10:57 +0000
Re: VFX code quality Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-21 01:35 +0200
Re: VFX code quality Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-20 22:44 -0700
Re: VFX code quality Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-20 22:53 -0700
Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:32 -0500
Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 08:44 -1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-20 00:58 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-20 15:09 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-18 07:20 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 10:22 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-18 22:09 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-19 04:20 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-19 13:19 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:33 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 01:49 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-18 07:59 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 10:32 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-20 17:24 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-20 15:43 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-20 16:03 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-20 16:34 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-20 17:02 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:46 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-21 08:33 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-21 12:10 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:40 -0500
address units (was: I beleive that forth could supplant ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-21 14:40 +0000
Re: address units Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 10:07 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-21 10:59 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-21 14:22 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-18 00:43 +0200
Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 23:10 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Doug Hoffman <glidedog@gmail.com> - 2012-05-17 19:24 -0400
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:38 -0500
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-17 22:30 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-17 10:59 -0700
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-05-20 13:14 +0100
Re: I beleive that forth could supplant ruby and perl and python if it wanted to marko <marko@marko.marko> - 2012-05-18 11:46 +1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-17 20:10 -1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Arnold Doray <invalid@invalid.com> - 2012-05-18 10:32 +0000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to marko <marko@marko.marko> - 2012-05-18 21:27 +1000
Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 22:58 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2012-05-18 10:01 -0700 |
| Message-ID | <9c6a5109-cdf5-4b31-8991-a5b3e0cd6269@googlegroups.com> |
| In reply to | #12268 |
On Friday, May 18, 2012 6:24:39 AM UTC-4, Mark Wills wrote: > However, this discussion raises an interesting point. > Most Forth programmers would have the ability to drop > into assembler and simply write something in machine > code if they needed to - if they thought the stack was > a bottleneck in a particular routine, for example. Most > C programmers wouldn't know how to do that. Oh please. There are Forth programmers who don't know the underlying machine architecture (and who don't care) and there are C programmers who break into assembly language at the drop of a hat. Practically every C compiler I've ever used has had the ability to do inline assembly. Do you honestly believe this capability is unused? > I make that statement, because I just asked an office > of 9 software engineers (who code C (not C++) day in > day out) if they could write memcpy in assembler for > PC104 stacks that we use. If you asked me, I would have said yes, I could certainly write such a routine. But I would ask you why you would make such an optimization? Did you perform some measurement and determine that a memcpy would offer a meaningful increase in speed? If speed is really important here, did you consider if the platform supported memory-to-memory DMA? Or if the platform doesn't support such DMA, did you determine if the memory you're copying actually needs to be copied-- is there some "zero-copy" version of the same algorithm that eliminates the need? Or are you really asking because you started with the presumption that being able to code trivial routines in assembly somehow makes you a L33T programmer? Gosh, could it be that the reason they haven't acquired this skill is because they aren't worrying about the same microoptimizations that you are and are instead more on larger issues? > They all said they wouldn't know how to do it, > but then they all pointed out that they wouldn't > have to - there are library calls in QNX to do > it all for you! Correct. If the infrastructure you are using already supports an efficient memcpy (and other routines) as part of the system libraries, then your ability to code or not code that routine in assembly is pointless. Why are you wasting time reinventing wheels? Is your wheel more round? > *THAT* is the difference between C and Forth. > The difference is between the chair and the > keyboard, in the caliber of the programmer. False. The difference is more in the type of work that they do. Programmers who write code for embedded systems or who do system-level programming tend to have a deeper understanding of the underlying architecture. That's independent of language, because in order to do that kind of work, you typically need that information. It works the other way too. We have expert Forth programmers in this newsgroup who only work in embedded systems. Ask them to write code for a different problem domain, and they'll probably flop around with poor approaches. Take for example anytime the subject of web applications comes up and the peanut gallery here chimes in how they would do it using CGI. Hey, I liked 1994 too, but I moved on.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-05-18 12:58 +0000 |
| Subject | VFX code quality (was: I beleive that forth could supplant ...) |
| Message-ID | <2012May18.145840@mips.complang.tuwien.ac.at> |
| In reply to | #12264 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>What's really killing us here is the memory traffic. The memory
>traffic arrives because
>a) we generate a canonical stack at loop boundaries,
>b) Forth is bad at handling four items
>
>There are two solutions
>a) adjust the canonical stack model at inner block
>boundaries. This is doable at the expense of complexity
>and the x86 code generator is already 6000 lines of source.
Yes. Also note, that in applications (not micro-benchmarks), most
basic block boundaries are due to calls. You already do inlining
which should move that a bit towards loops and conditionals. But some
kind of interprocedural register allocation could be quite effective
(or not, depending on how aggressive the inliner is).
>b) Use register-based locals. I believe Marcel does this
>in some versions of iForth.
Yes.
>But thanks for retriggering the code generation competition.
>I now have work to do ...
Why does such a micro-benchmark trigger this for you? Granted, if you
work on application benchmarks like
<http://www.complang.tuwien.ac.at/forth/appbench.zip>, you will need
more effort to see the same speedups, but I think that these
improvements are more likely to also be profitable for other
applications than improvements for a micro-benchmark (even when you
consider improvement per effort as metric, as is sensible).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-18 09:43 -0500 |
| Subject | Re: VFX code quality |
| Message-ID | <W7ednYDdl45rwivSnZ2dnUVZ_hydnZ2d@supernews.com> |
| In reply to | #12278 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Also note, that in applications (not micro-benchmarks), most > basic block boundaries are due to calls. In Conventional compiler terminology, a call does not terminate a basic block. >>But thanks for retriggering the code generation competition. >>I now have work to do ... > > Why does such a micro-benchmark trigger this for you? Granted, if you > work on application benchmarks like > <http://www.complang.tuwien.ac.at/forth/appbench.zip>, you will need > more effort to see the same speedups, but I think that these > improvements are more likely to also be profitable for other > applications than improvements for a micro-benchmark (even when you > consider improvement per effort as metric, as is sensible). There's a lot to be said for micro-benchmarks: you can see think about a single thing, clearly. This one is just a simple combination of a loop and stak ops, and improving it will benefit a lot of code. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-05-19 10:54 +0000 |
| Subject | Re: VFX code quality |
| Message-ID | <2012May19.125419@mips.complang.tuwien.ac.at> |
| In reply to | #12282 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Also note, that in applications (not micro-benchmarks), most
>> basic block boundaries are due to calls.
>
>In Conventional compiler terminology, a call does not terminate a
>basic block.
There is no such convention. In some contexts, they do, and in some
contexts, they don't. In the VFX register allocation context, AFAIK
they do (they certainly do in RAFTS and in Gforth).
>> Why does such a micro-benchmark trigger this for you? Granted, if you
>> work on application benchmarks like
>> <http://www.complang.tuwien.ac.at/forth/appbench.zip>, you will need
>> more effort to see the same speedups, but I think that these
>> improvements are more likely to also be profitable for other
>> applications than improvements for a micro-benchmark (even when you
>> consider improvement per effort as metric, as is sensible).
>
>There's a lot to be said for micro-benchmarks: you can see think about
>a single thing, clearly.
Yes, but it does not tell you if that matters for a
lot of code.
>This one is just a simple combination of a
>loop and stak ops, and improving it will benefit a lot of code.
How do you know that it will benefit a lot of code? In my work, I see
very short basic blocks in Forth applications, and the most frequent
reason for basic block boundaries is calls.
In particular, see Figures 8-10 in
<http://www.complang.tuwien.ac.at/papers/ertl&pirker96.ps.gz>, Figure
9 in
<http://www.complang.tuwien.ac.at/papers/ertl%26gregg04ivme.ps.gz>,
and compare the dynamic counts of ;S (aka EXIT), COL: (aka ENTER),
?BRANCH, (LOOP) and (+LOOP) in
<http://www.complang.tuwien.ac.at/forth/peep/sorted>.
Inlining in VFX may lead to longer blocks so one would have to make
such evaluations especially for VFX, but as long as we don't have such
an evaluation, we are completely in the dark whether working on loop
optimizations benefits a lot of code, or just a few small benchmarks.
The code by Wil Baden in the MPE benchmark certainly does not look
like idiomatic Forth to me.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-19 11:43 -0500 |
| Subject | Re: VFX code quality |
| Message-ID | <4YSdnc_FNf0EUCrSnZ2dnUVZ_uydnZ2d@supernews.com> |
| In reply to | #12294 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Also note, that in applications (not micro-benchmarks), most >>> basic block boundaries are due to calls. >> >>In Conventional compiler terminology, a call does not terminate a >>basic block. > > There is no such convention. IME there is, but there's no point arguing about the meanings of words. >>There's a lot to be said for micro-benchmarks: you can see think about >>a single thing, clearly. > > Yes, but it does not tell you if that matters for a lot of code. No, you have to use other knowledge, such as: >>This one is just a simple combination of a loop and stack ops, and >>improving it will benefit a lot of code. > How do you know that it will benefit a lot of code? Of course, there are ways of generating efficient code for this pattern that will not benefit a lot of code. For example, one could just recognize the pattern and treat it as a special case. However, I suspect, based on my knowledge and experience, that a more general solution which does an efficient register allocation would benefit other code. I can't prove it without doing it. > In my work, I see very short basic blocks in Forth applications, I'm not surprised by that, if you terminate a basic block at a call. This is Forth, after all. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-05-22 08:26 +0000 |
| Subject | Re: VFX code quality |
| Message-ID | <2012May22.102634@mips.complang.tuwien.ac.at> |
| In reply to | #12301 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>This one is just a simple combination of a loop and stack ops, and
>>>improving it will benefit a lot of code.
>
>> How do you know that it will benefit a lot of code?
>
>Of course, there are ways of generating efficient code for this
>pattern that will not benefit a lot of code. For example, one could
>just recognize the pattern and treat it as a special case. However, I
>suspect, based on my knowledge and experience, that a more general
>solution which does an efficient register allocation would benefit
>other code. I can't prove it without doing it.
Fortunately, we have already done it, in RAFTS. It had efficient
register allocation within blocks, probably a bit better than what VFX
does for blocks (but we had the benefit of more registers). And while
that produced good speedups over Gforth for some micro-benchmarks, for
applications the speedups over Gforth were much smaller, because the
basic blocks were very short.
>> In my work, I see very short basic blocks in Forth applications,
>
>I'm not surprised by that, if you terminate a basic block at a call.
>This is Forth, after all.
AFAIK, calls (that are not inlined) bound blocks in VFX, too.
Of course, inlining might eliminate enough calls that calls are no
longer the dominating cause of basic block boundaries, but whether
VFX's inliner achieves that for applications would have to be
measured. Concentrating on a micro-benchmark like the one earlier in
this thread won't give us any insight on that.
- anton
-
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-22 03:52 -0500 |
| Subject | Re: VFX code quality |
| Message-ID | <I_ednTVqBtYmzibSnZ2dnUVZ_jSdnZ2d@supernews.com> |
| In reply to | #12368 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>This one is just a simple combination of a loop and stack ops, and >>>>improving it will benefit a lot of code. >> >>> How do you know that it will benefit a lot of code? >> >>Of course, there are ways of generating efficient code for this >>pattern that will not benefit a lot of code. For example, one could >>just recognize the pattern and treat it as a special case. However, I >>suspect, based on my knowledge and experience, that a more general >>solution which does an efficient register allocation would benefit >>other code. I can't prove it without doing it. > > Fortunately, we have already done it, in RAFTS. It had efficient > register allocation within blocks, probably a bit better than what > VFX does for blocks (but we had the benefit of more registers). And > while that produced good speedups over Gforth for some > micro-benchmarks, for applications the speedups over Gforth were > much smaller, because the basic blocks were very short. Why do you terminate a block at a call? I'm guessing that it's because of insufficient knowledge about what a callee will do to the stack, so there's no choice but to dump the whole stack and reload it on return. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-22 04:02 -0500 |
| Subject | Re: VFX code quality |
| Message-ID | <I_ednTdqBtbfyybSnZ2dnUVZ_jSdnZ2d@supernews.com> |
| In reply to | #12369 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>This one is just a simple combination of a loop and stack ops, and >>>>>improving it will benefit a lot of code. >>> >>>> How do you know that it will benefit a lot of code? >>> >>>Of course, there are ways of generating efficient code for this >>>pattern that will not benefit a lot of code. For example, one could >>>just recognize the pattern and treat it as a special case. However, I >>>suspect, based on my knowledge and experience, that a more general >>>solution which does an efficient register allocation would benefit >>>other code. I can't prove it without doing it. >> >> Fortunately, we have already done it, in RAFTS. It had efficient >> register allocation within blocks, probably a bit better than what >> VFX does for blocks (but we had the benefit of more registers). And >> while that produced good speedups over Gforth for some >> micro-benchmarks, for applications the speedups over Gforth were >> much smaller, because the basic blocks were very short. > > Why do you terminate a block at a call? I'm guessing that it's > because of insufficient knowledge about what a callee will do to the > stack, so there's no choice but to dump the whole stack and reload it > on return. One other thing: if speeding up basic blocks with better register allocation doesn't much help applications, that suggests that most of the time is spent not on doing real work but on call overhead. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-05-22 09:25 +0000 |
| Subject | Re: VFX code quality |
| Message-ID | <2012May22.112518@mips.complang.tuwien.ac.at> |
| In reply to | #12371 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>> Why do you terminate a block at a call? I'm guessing that it's
>> because of insufficient knowledge about what a callee will do to the
>> stack, so there's no choice but to dump the whole stack and reload it
>> on return.
Something like that. We started out with basic block register
allocation to get something working. The idea was to add "global"
(within a colon definition) and interprocedural register allocation
later. Our results indicated that interprocedural would be much more
effective, so the plan was to do that first, but that work was not
finished before the project ended.
>One other thing: if speeding up basic blocks with better register
>allocation doesn't much help applications, that suggests that most of
>the time is spent not on doing real work but on call overhead.
Yes.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-05-30 23:39 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <jq643b$iln$1@online.de> |
| In reply to | #12374 |
Anton Ertl wrote: > Something like that. We started out with basic block register > allocation to get something working. The idea was to add "global" > (within a colon definition) and interprocedural register allocation > later. Our results indicated that interprocedural would be much more > effective, so the plan was to do that first, but that work was not > finished before the project ended. IIRC what I proposed, the global allocation would treat the available registers as stack - the leaf procedures would start with the end of the stack, and mark the registers they use as well as the registers they use for parameter passing. Each word would either have a wrapper for EXECUTE (with normalized stack), or is compiled twice - with the typical on-demand approach, i.e. if you EXECUTE it first time, it compiles the normalized stack version, if you COMPILE, it the first time, it compiles the register-parameter-passing version. The question however is if that is really a good idea, or if inlining provides so much more opportunities for optimization. And, as observed with VFX vs. bigForth on MINOS: If you have lots of small late-binding OOP words, you better optimize for the few things the OOP system needs (this pointer+offset access, calling through the vtable) instead of having a fancy inliner which is actually not used much - dedicating a register for the this pointer is worth it. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-05-31 15:07 +0000 |
| Subject | Re: VFX code quality |
| Message-ID | <2012May31.170705@mips.complang.tuwien.ac.at> |
| In reply to | #12623 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Something like that. We started out with basic block register
>> allocation to get something working. The idea was to add "global"
>> (within a colon definition) and interprocedural register allocation
>> later. Our results indicated that interprocedural would be much more
>> effective, so the plan was to do that first, but that work was not
>> finished before the project ended.
>
>IIRC what I proposed, the global allocation would treat the available
>registers as stack - the leaf procedures would start with the end of the
>stack, and mark the registers they use as well as the registers they use
>for parameter passing.
That's certainly a simple approach, and probably better than a fixed
calling convention, but leaves quite a bit of potential for
improvement: A simple definition calling first A and then B would have
to adjust the stack mapping between the calls.
An alternative, possibly better approach would be to use something
like the coagulating register allocator: Start with one (ideally the
most-executed) word, then propagate its register allocation to
adjacent (in the call graph) words (ideally following frequently
executed edges first); due to cycles in the graph you will have to
adjust the stack mapping at some edges, but ideally these would be
infrequently-executed ones.
However, the coagulating register allocator never caught on, probably
because graph colouring and (alternatively) linear scan are more
effective. However, it's not clear how to apply these techniques
interprocedurally.
>The question however is if that is really a good idea, or if inlining
>provides so much more opportunities for optimization.
These optimizations are not exclusive, so a compiler can do them both.
Although admittedly a good interprocedural register allocator will
reduce the optimization benefit from inlining and vice versa.
> And, as observed
>with VFX vs. bigForth on MINOS: If you have lots of small late-binding
>OOP words, you better optimize for the few things the OOP system needs
>(this pointer+offset access, calling through the vtable) instead of
>having a fancy inliner which is actually not used much
Do you have numbers for that? I.e., how many of the dynamically
executed calls are late-bound method calls?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-05-31 20:24 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <jq8d15$krd$1@online.de> |
| In reply to | #12638 |
Anton Ertl wrote: > Do you have numbers for that? I.e., how many of the dynamically > executed calls are late-bound method calls? All performance-critical loops within MINOS itself (excluding e.g. drawing through X11 or OpenGL) are an iterator around a late-bound method or two, plus a little bit of processing, like adding points together or such. The called methods do usually very simple stuff, because I try to cache everything that otherwise would go to X11 (e.g. height and width of a text string - calculated once, and then kept in the cache. The method is there to return the cached value if it's available, or otherwise call the X11 function to obtain the values to be cached). There are objects where caching is not possible, some where caching needs special care, and some where caching is simply not necessary. After all, it's a Forth program, so all methods are rather short, and usually call methods of other objects (if anything). AFAIK, code in other object oriented languages is not fundamentally different. The result is that modern CPU architectures do not work well on this code, because the loop+unpredictable indirect call breaks the branch predictor, and the small basic blocks make sure it breaks very often. Using non-OOP benchmarks to decide how deep the pipeline is (like ARM A15 vs. A9) is a bad idea if your main software base is written in OOP style or uses a VM with similar behavior. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-05-18 15:25 +0000 |
| Subject | Re: VFX code quality (was: I beleive that forth could supplant ...) |
| Message-ID | <4fb661ae.287328288@192.168.0.50> |
| In reply to | #12278 |
On Fri, 18 May 2012 12:58:40 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Yes. Also note, that in applications (not micro-benchmarks), most >basic block boundaries are due to calls. You already do inlining >which should move that a bit towards loops and conditionals. But some >kind of interprocedural register allocation could be quite effective >(or not, depending on how aggressive the inliner is). Better intra-procedural register allocation would help loops considerably, which is what Andy's example shows. >>b) Use register-based locals. I believe Marcel does this >>in some versions of iForth. > >Yes. If we get better handling of the third and fourth items on the Forth data stack (even if we have to invent some notation), then the need for locals is reduced. Some systems already have words such as THIRD and FOURTH, albeit as macros for x PICK. >>But thanks for retriggering the code generation competition. >>I now have work to do ... > >Why does such a micro-benchmark trigger this for you? Sorry, I should have said *other* work. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-05-19 11:31 +0000 |
| Subject | Re: VFX code quality (was: I beleive that forth could supplant ...) |
| Message-ID | <2012May19.133123@mips.complang.tuwien.ac.at> |
| In reply to | #12285 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>Better intra-procedural register allocation would help loops
>considerably, which is what Andy's example shows.
The question is: Would it help Forth applications considerably?
Without your inliner, no. With your inliner, maybe. You have to
measure.
>If we get better handling of the third and fourth items on
>the Forth data stack (even if we have to invent some notation),
>then the need for locals is reduced. Some systems already have
>words such as THIRD and FOURTH, albeit as macros for x PICK.
Sure, as far as the compiler is concerned.
But for programmers, if they have so much data flying around and don't
find a way to factor it for fewer stack items, having THIRD and FOURTH
is probably worse than locals, and it's certainly less popular. So if
you want to have good register allocation for such things, it might be
more beneficial to let the register allocator cover locals.
Or maybe these things are not so frequent and other improvements would
have more effect on application performance.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-05-20 17:41 +0200 |
| Subject | Re: VFX code quality (was: I beleive that forth could supplant ...) |
| Message-ID | <jpb3bm$4tr$1@online.de> |
| In reply to | #12285 |
Stephen Pelc wrote: > If we get better handling of the third and fourth items on > the Forth data stack (even if we have to invent some notation), > then the need for locals is reduced. Some systems already have > words such as THIRD and FOURTH, albeit as macros for x PICK. But they are used rarely (and should so). Locals are used for words where you can't figure out how to reduce the stack pressure so that it can be written nicely. Locals in a word are a warning label, and my dominant usage of locals is when calling C functions. The warning label means "bad factoring, cluttered stack", and well, when calling C, I know that it is badly factored and the stack is cluttered (C's stacks are allocated in megabytes, Forth stacks usually do with kilobytes, if at all). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-20 12:49 -0500 |
| Subject | Re: VFX code quality |
| Message-ID | <m5WdnaEpV6kRsyTSnZ2dnUVZ_o2dnZ2d@supernews.com> |
| In reply to | #12312 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Stephen Pelc wrote: >> If we get better handling of the third and fourth items on >> the Forth data stack (even if we have to invent some notation), >> then the need for locals is reduced. Some systems already have >> words such as THIRD and FOURTH, albeit as macros for x PICK. > > But they are used rarely (and should so). > > Locals are used for words where you can't figure out how to reduce the > stack pressure so that it can be written nicely. Locals in a word are a > warning label, and my dominant usage of locals is when calling C > functions. The warning label means "bad factoring, cluttered stack", Well, not necessarily. If locals are a super-efficient way of using registers in colon definitions, then they're an easy way to write fiddly low-level words that use multiple operands, maybe as good as dropping into asm. That's a nice thing, isn't it? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-20 11:43 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <7xmx528zi4.fsf@ruckus.brouhaha.com> |
| In reply to | #12313 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Well, not necessarily. If locals are a super-efficient way of using > registers in colon definitions, then they're an easy way to write > fiddly low-level words that use multiple operands, maybe as good as > dropping into asm. That's a nice thing, isn't it? With extensive use of locals, Forth becomes just yet another computer language. Having to organize one's algorithms to get the stack effects to match up (avoiding a lot of juggling, locals, and PICK) to me seems sort of like having to write computer documentation as poems that rhyme and scan, instead of as ordinary English text. That seems to be part of the Zen that makes Forth interesting, even if it slows coding down. I've also seen a Forth style that simply uses globals (re-entrancy? Who needs it) instead of locals, but I don't know how the cogniscenti react to it. [Bernd:] > and well, when calling C, I know that it is badly factored > and the stack is cluttered (C's stacks are allocated in megabytes, > Forth stacks usually do with kilobytes, if at all). One thing happening is C programs putting large structures or arrays on the stack where Forthers would use ALLOT/FORGET or the like. The memory usage from that is the same either way, but in Forth you have to manually restore the old HERE, you can't allocate new permanent stuff while the temp thing is there, etc. So I'm not persuaded the C approach is worse. Stack-allocating large objects is perfectly natural sometimes. The other thing is Forth's convention of using a separate return stack, and having called words consume their args from the data stack, while C traditionally uses one stack, and has the caller clean up the args after the called function returns. That means in Forth, if the called word then calls other words, it's probably already consumed some args, and this keeps going so that when you get further down the call chain, there is quite a bit less stuff on the data stack. Maybe C compilers could also generate code like that, saving some memory. Of course they already pass a few args in registers on some architectures.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-05-20 14:01 -1000 |
| Subject | Re: VFX code quality |
| Message-ID | <s82dndbzBMpsGCTSnZ2dnUVZ_q-dnZ2d@supernews.com> |
| In reply to | #12314 |
On 5/20/12 8:43 AM, Paul Rubin wrote: > Andrew Haley<andrew29@littlepinkcloud.invalid> writes: >> Well, not necessarily. If locals are a super-efficient way of using >> registers in colon definitions, then they're an easy way to write >> fiddly low-level words that use multiple operands, maybe as good as >> dropping into asm. That's a nice thing, isn't it? > > With extensive use of locals, Forth becomes just yet another computer > language. Having to organize one's algorithms to get the stack effects > to match up (avoiding a lot of juggling, locals, and PICK) to me seems > sort of like having to write computer documentation as poems that rhyme > and scan, instead of as ordinary English text. That seems to be part of > the Zen that makes Forth interesting, even if it slows coding down. Except that, in virtually every comparison I've seen (both in the context of professional programming projects and competitions held in the past) projects are complete in Forth much faster than in C. For over 30 years FORTH, Inc. has been bidding on projects against teams using C. Our bids usually come in 1/4 to 1/6 that of the C team bids. And we usually deliver on time. > I've also seen a Forth style that simply uses globals (re-entrancy? Who > needs it) instead of locals, but I don't know how the cogniscenti react > to it. In the first place, "re-entrancy" is only an issue in the presence of multiple tasks. For people using single-threaded Forths, it isn't an issue at all. For most of my career, though, I've used multi-tasked Forths (everything produced by FORTH, Inc. since 1973). Our style is to use variables for values that need to have a "lifetime" beyond a single definition or be shared by multiple tasks as a component of the overall application design. Variables that might have re-entrancy issues or which tasks need private copies are defined as "user variables" (every task has a private copy). > [Bernd:] >> and well, when calling C, I know that it is badly factored >> and the stack is cluttered (C's stacks are allocated in megabytes, >> Forth stacks usually do with kilobytes, if at all). > > One thing happening is C programs putting large structures or arrays on > the stack where Forthers would use ALLOT/FORGET or the like. The memory > usage from that is the same either way, but in Forth you have to > manually restore the old HERE, you can't allocate new permanent stuff > while the temp thing is there, etc. So I'm not persuaded the C approach > is worse. Stack-allocating large objects is perfectly natural > sometimes. ALLOT yes, FORGET almost never. Given that Forth is extremely parsimonious with memory, it's rarely necessary to worry about temporarily allocating space. Temporary arrays can go in the unallocated space at PAD, and ALLOCATE/FREE is useful sometimes. Programmers coming from other languages tend to worry a lot more about releasing space than Forth programmers. > The other thing is Forth's convention of using a separate return stack, > and having called words consume their args from the data stack, while C > traditionally uses one stack, and has the caller clean up the args after > the called function returns. That means in Forth, if the called word > then calls other words, it's probably already consumed some args, and > this keeps going so that when you get further down the call chain, there > is quite a bit less stuff on the data stack. Maybe C compilers could > also generate code like that, saving some memory. Of course they > already pass a few args in registers on some architectures. Except when we're having to call C (or other language) routines, Forth programs don't use very much stack space. We have done studies on a few large applications and found that they rarely get more than 8-10 elements deep. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-20 19:10 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <7x8vgmffmz.fsf@ruckus.brouhaha.com> |
| In reply to | #12321 |
"Elizabeth D. Rather" <erather@forth.com> writes: > In the first place, "re-entrancy" is only an issue in the presence of > multiple tasks. For people using single-threaded Forths, it isn't an > issue at all. If you're doing anything at interrupt level, that counts as multitasking, and re-entrancy matters. And these days, it seems like almost every program I deal with is multi-threaded (maybe that's just me). Single-threading seems like a 20th-century thing. > Variables that might have re-entrancy issues or which tasks need > private copies are defined as "user variables" (every task has a > private copy). In this case you're burning memory unnecessarily, if you're using a variable for some temporary result, and you have a copy in every task when it's if variable will be never active in more than one or two tasks simultaneously. The usual approach is to put the variable on the stack. > ALLOT yes, FORGET almost never. Given that Forth is extremely > parsimonious with memory, it's rarely necessary to worry about > temporarily allocating space. Temporary arrays can go in the > unallocated space at PAD, and ALLOCATE/FREE is useful > sometimes. Programmers coming from other languages tend to worry a lot > more about releasing space than Forth programmers. I hope that doesn't mean you're programming in a way that simply leaks space. Also, ALLOCATE is even clumsier than ALLOT compared to straightforward stack allocation. >> this keeps going so that when you get further down the call chain, there >> is quite a bit less stuff on the data stack. > Except when we're having to call C (or other language) routines, Forth > programs don't use very much stack space. We have done studies on a > few large applications and found that they rarely get more than 8-10 > elements deep. Yes, partly a matter of calling conventions, partly a matter of coding style, and probably partly a matter of what the applications do (Forth applications are simply less likely to be the kinds of applications that munch on large volumes of data). One reason C code is more likely to keep stuff on the stack is that it considers the stack to be randomly addressible, while Forth traditionally avoids PICK. Right now I'm messing with some C++ code that crunches XML documents that can be megabytes in size (they are usually smaller), extracting different fields and computing stuff. So there have to be a few dozen variables active (across multiple call frames), keeping track of what's in the different input buffers, copying stuff out of fields for processing, and so on. A Forth program would probably use globals for that stuff. The C++ code puts it on the stack since it considers the stack to be randomly addressible.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-05-20 17:05 -1000 |
| Subject | Re: VFX code quality |
| Message-ID | <ed-dnUkypMOSLCTSnZ2dnUVZ_jKdnZ2d@supernews.com> |
| In reply to | #12323 |
On 5/20/12 4:10 PM, Paul Rubin wrote: > "Elizabeth D. Rather"<erather@forth.com> writes: >> In the first place, "re-entrancy" is only an issue in the presence of >> multiple tasks. For people using single-threaded Forths, it isn't an >> issue at all. > > If you're doing anything at interrupt level, that counts as > multitasking, and re-entrancy matters. And these days, it seems like > almost every program I deal with is multi-threaded (maybe that's just > me). Single-threading seems like a 20th-century thing. Well, as I said, I've always worked on multitasked Forths. But we do not handle interrupts in task code. It's a little hard to explain here, but there's a whole consistent design concept involving the relationship between interrupts and task-level code. >> Variables that might have re-entrancy issues or which tasks need >> private copies are defined as "user variables" (every task has a >> private copy). > > In this case you're burning memory unnecessarily, if you're using a > variable for some temporary result, and you have a copy in every task > when it's if variable will be never active in more than one or two tasks > simultaneously. The usual approach is to put the variable on the stack. We rarely use variables for a truly "temporary" result, that's what the data stack is for. User variables are allocated and managed conservatively. >> ALLOT yes, FORGET almost never. Given that Forth is extremely >> parsimonious with memory, it's rarely necessary to worry about >> temporarily allocating space. Temporary arrays can go in the >> unallocated space at PAD, and ALLOCATE/FREE is useful >> sometimes. Programmers coming from other languages tend to worry a lot >> more about releasing space than Forth programmers. > > I hope that doesn't mean you're programming in a way that simply leaks > space. Also, ALLOCATE is even clumsier than ALLOT compared to > straightforward stack allocation. No, space is allotted according to the overall design of the application, but the allocations are usually permanent. I'm not even sure what a "leak" means in the Forth context. >>> this keeps going so that when you get further down the call chain, there >>> is quite a bit less stuff on the data stack. > >> Except when we're having to call C (or other language) routines, Forth >> programs don't use very much stack space. We have done studies on a >> few large applications and found that they rarely get more than 8-10 >> elements deep. > > Yes, partly a matter of calling conventions, partly a matter of coding > style, and probably partly a matter of what the applications do (Forth > applications are simply less likely to be the kinds of applications that > munch on large volumes of data). One reason C code is more likely to > keep stuff on the stack is that it considers the stack to be randomly > addressible, while Forth traditionally avoids PICK. > > Right now I'm messing with some C++ code that crunches XML documents > that can be megabytes in size (they are usually smaller), extracting > different fields and computing stuff. So there have to be a few dozen > variables active (across multiple call frames), keeping track of what's > in the different input buffers, copying stuff out of fields for > processing, and so on. A Forth program would probably use globals for > that stuff. The C++ code puts it on the stack since it considers the > stack to be randomly addressible. Yes, it's a very different programming style. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web