Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15078 > unrolled thread
| Started by | visualforth@rocketmail.com |
|---|---|
| First post | 2012-08-21 21:43 -0700 |
| Last post | 2012-08-22 07:37 -0700 |
| Articles | 20 on this page of 163 — 19 participants |
Back to article view | Back to comp.lang.forth
Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-21 21:43 -0700
Re: Comparative Productivity of Programming Languages "A. K." <akk@nospam.org> - 2012-08-22 07:07 +0200
Re: Comparative Productivity of Programming Languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-22 03:35 -0500
Re: Comparative Productivity of Programming Languages John Passaniti <john.passaniti@gmail.com> - 2012-08-22 14:06 -0700
Function Points (was: Comparative Productivity of Programming Languages) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-23 14:50 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-23 11:43 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-25 14:13 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 10:12 -0700
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-25 15:39 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 15:09 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 12:34 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 16:43 -0700
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-25 18:05 -0700
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-25 20:34 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-26 03:24 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 22:44 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 21:19 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 00:36 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 21:50 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 01:08 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-26 23:20 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 19:33 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-27 13:34 -0500
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-27 22:38 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 02:45 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 18:14 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 18:24 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:22 +0000
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 03:07 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-28 08:18 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 12:15 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-28 23:05 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-29 03:55 -0500
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-27 22:28 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 20:26 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-28 23:17 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 01:13 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 02:23 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:59 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 22:18 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 20:44 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-31 01:29 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-31 09:33 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:58 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 19:39 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:10 +0000
Re: Function Points gavino_himself <visploveslisp@gmail.com> - 2012-08-30 20:08 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 17:47 -1000
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-27 13:43 -1000
Re: Function Points "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-08-27 12:14 +0100
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-27 05:12 -0700
Re: Function Points "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-08-27 15:52 +0100
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-26 13:09 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 20:52 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:08 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-30 10:43 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 08:25 -1000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 22:42 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 01:23 -0400
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-31 03:08 -0500
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:56 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 02:35 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-31 23:52 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:27 +0000
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:18 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 17:45 +0200
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 16:14 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 19:13 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 03:19 -0500
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:18 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:04 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 04:02 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 17:40 +0200
Re: Function Points jim@rainbarrel.com - 2012-09-02 10:32 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 20:49 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:33 -0400
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 17:03 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 09:02 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:35 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 13:42 -1000
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:54 -0700
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-09-03 00:29 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:30 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 21:21 -1000
Re: Function Points jim@rainbarrel.com - 2012-09-03 10:37 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-04 07:14 +0000
Re: Function Points Coos Haak <chforth@hccnet.nl> - 2012-09-03 21:12 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 17:32 -0400
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 17:51 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-03 22:37 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-04 04:25 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-04 07:35 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 02:13 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-04 20:18 -1000
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-05 10:56 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 16:11 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-05 14:07 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:27 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 00:52 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-02 16:28 -0700
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:48 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 20:21 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 14:45 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:12 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 21:26 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:06 -0400
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 03:29 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-31 10:35 +0000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:49 -0400
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:49 +0000
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-01 08:36 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:11 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 01:58 +0200
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 17:54 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:19 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:05 +0200
Re: Function Points Coos Haak <chforth@hccnet.nl> - 2012-08-31 23:10 +0200
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-31 15:50 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-01 10:31 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 21:52 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:36 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-01 14:36 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:30 +0200
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 23:15 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-02 15:02 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 01:50 +0200
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:57 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-03 23:11 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-04 14:30 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-04 10:14 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-04 22:10 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 00:19 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-06 17:48 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 12:01 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-06 22:02 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 14:19 -0700
Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-07 11:30 +0000
Re: Heap (was: Function Points) Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-07 18:12 +0200
Re: Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-07 16:48 +0000
Re: Heap (was: Function Points) Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-07 21:34 +0200
Re: Heap Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-09-07 22:04 +0100
Re: Heap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 11:52 +0000
Re: Heap Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-08 22:48 +0200
Re: Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 12:11 +0000
priority queue (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-03 11:46 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 15:03 +0200
Re: Function Points mhx@iae.nl (Marcel Hendrix) - 2012-09-03 22:36 +0200
Re: Function Points mhx@iae.nl (Marcel Hendrix) - 2012-09-06 20:27 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 04:00 -0500
Re: Function Points visualforth@rocketmail.com - 2012-09-03 10:40 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 20:26 +0200
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-27 11:49 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 09:16 -0700
Re: Function Points Josh Grams <josh@qualdan.com> - 2012-08-28 22:46 +0000
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-28 16:06 -0700
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-28 20:50 -0400
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-26 12:59 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 22:24 -0700
Re: Function Points (was: Comparative Productivity of Programming Languages) John Passaniti <john.passaniti@gmail.com> - 2012-08-23 15:02 -0700
Re: Function Points (was: Comparative Productivity of Programming Languages) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-25 14:57 +0000
Re: Comparative Productivity of Programming Languages "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-22 08:07 -0400
Re: Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-22 08:12 -0700
Re: Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-22 07:37 -0700
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2012-09-07 22:04 +0100 |
| Subject | Re: Heap |
| Message-ID | <k2dnfq$tdm$1@dont-email.me> |
| In reply to | #15516 |
On 07/09/2012 20:34, Bernd Paysan wrote: > Anton Ertl wrote: >>> A native code system could translate an IF DROP somevalue THEN to a >>> movcc. VFX doesn't. >> >> I think the Forthier approach is to have a selection word, equivalent >> to: >> >> : select ( x1 x2 f -- x ) >> if drop else nip then ; >> >> which would be implemented with movcc. > > We could add one into Gforth, let GCC do the movcc magic, and check if > it is worth the effort... If f is a well formed flag, you can do > > : mux ( x1 x2 flag -- x ) tuck invert and >r and r> or ; > > and have highly predictable code. or even : mux ( x1 x2 flag -- x ) 1+ roll drop ; -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-09-08 11:52 +0000 |
| Subject | Re: Heap |
| Message-ID | <2012Sep8.135258@mips.complang.tuwien.ac.at> |
| In reply to | #15517 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 07/09/2012 20:34, Bernd Paysan wrote:
>> Anton Ertl wrote:
>>>> A native code system could translate an IF DROP somevalue THEN to a
>>>> movcc. VFX doesn't.
>>>
>>> I think the Forthier approach is to have a selection word, equivalent
>>> to:
>>>
>>> : select ( x1 x2 f -- x )
>>> if drop else nip then ;
>>>
>>> which would be implemented with movcc.
>>
>> We could add one into Gforth, let GCC do the movcc magic, and check if
>> it is worth the effort...
The effort is small, the benefit will be hard to measure. How do you
want to check this? This would be a natural factor of MIN, MAX, UMIN
and UMAX, though.
>> If f is a well formed flag, you can do
>>
>> : mux ( x1 x2 flag -- x ) tuck invert and >r and r> or ;
>>
>> and have highly predictable code.
Anything wrong with the name "SELECT"? Is there some naming conflict?
Or is this just the "name NIH" syndrom that's even more rampant in
Forth than in other areas.
Another alternative (one word less:-):
: select ( x1 x2 f -- x )
>r tuck xor r> and xor ;
>or even
>
>: mux ( x1 x2 flag -- x ) 1+ roll drop ;
Cute, but probably slower than the above on many systems, particularly
on the faster ones.
- 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-09-08 22:48 +0200 |
| Subject | Re: Heap |
| Message-ID | <1471382.QOHZBGful2@sunwukong.fritz.box> |
| In reply to | #15524 |
Anton Ertl wrote: > Anything wrong with the name "SELECT"? Is there some naming conflict? No. The name for a multiplexer is MUX. As in AND, OR, XOR, which are all named by their logic equivalent. Though Forth chose to have an inverter called INVERT instead of just INV. > Or is this just the "name NIH" syndrom The name of that thing has long been invented. It's MUX. Please don't try to reinvent a different name for that thing. > that's even more rampant in Forth than in other areas. I've never seen a multiplexer named SELECT - it usually has an input line called S or select or so, but itself it is called MUX. SELECT is used for SQL statements to query a data base. > Another alternative (one word less:-): > > : select ( x1 x2 f -- x ) > >r tuck xor r> and xor ; Yes, but less obvious. >>or even >> >>: mux ( x1 x2 flag -- x ) 1+ roll drop ; > > Cute, but probably slower than the above on many systems, particularly > on the faster ones. On vfx, this one is 3 times slower. -- 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-09-08 12:11 +0000 |
| Subject | Re: Heap (was: Function Points) |
| Message-ID | <2012Sep8.141119@mips.complang.tuwien.ac.at> |
| In reply to | #15516 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> If the stuff is not in the cache, memory operations dominate, and it
>> does not matter whether in-cache moves are highly optimized; they get
>> swamped by the memory operations.
>
>Move operations are even highly optimized for out-of-cache, by having
>the apropriate prefetchers.
I never heard about separate prefetchers for move operations. The
prefetchers I have read about would benefit a scan at least as well as
a move. Someone on comp.arch described a direction change (from read
to write or vice versa) for DDR2 and DDR3 SDRAM as "train wreck"; I
would expect fewer direction changes with the scanning approach.
> You simply get all available bandwidth with
>a move, and you can't predict if you get the same bandwidth with a scan.
Due to the train wreck thing, I would not be so sure about getting all
the bandwidth when using moves, while scanning seems to be ideal for
hardware prefetchers. I also remember funny results when doing
multi-processor microbenchmarks with moves.
Let's just measure it:
[~/gforth:78229] time vfxlin "20000008 allocate throw constant pad : scanning ( n addr ) begin 2dup @ < while cell+ repeat 2drop ; : bench 1000 0 do -1 pad scanning loop ; pad 20000000 erase -2 pad 20000000 + ! bench bye" >/dev/null
real 0m4.209s
user 0m4.132s
sys 0m0.016s
[~/gforth:78230] time vfxlin "20000008 allocate throw constant pad : bench 1000 0 do pad cell+ pad 10000000 move loop ; pad 20000000 erase bench bye" >/dev/null
real 0m3.687s
user 0m3.600s
sys 0m0.024s
Moving x/2 memory is indeed a little (factor 1.15) faster than scanning.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-09-03 11:46 +0000 |
| Subject | priority queue (was: Function Points) |
| Message-ID | <2012Sep3.134639@mips.complang.tuwien.ac.at> |
| In reply to | #15400 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Bernd Paysan wrote:
>> I've written a binary heap now, it is considerably more code than the
>> O(n) code. I'd like to make a few benchmarks, before I post
>> comparisons.
>
>Ok, here's the benchmarking stuff.
>
> binary heap linear "heap"
> 10 inserts 17,666ns 9,287ns
> 10 deletes 15,941ns 6,960ns
> 256 inserts 164,048ns 452,609ns
> 256 deletes 476,276ns 251,134ns
>4096 inserts 2,609,171ns 93,231,767ns
>4096 deletes 12,061,005ns 55,881,857ns
[...]
>It's a typical mildly disappointing result - the O(n log n) doesn't meet
>its promise, due to the random memory access pattern. The O(n²)
>algorithm shuffles a lot more memory around, but its access pattern is
>predictable. Some people say that modern x86 CPUs are tuned to bad
>code, and that seems to include bad algorithms ;-).
How much memory do your 256 elements consume? I would expect that
they fit in the D-cache; if so, any spacial locality from the linear
algorithm should not play a role.
Inserts into the binary heap are equally expensive for 256 elements as
for 4096. Deletes slow down from 1594ns (10) through 1860ns (256) to
2944ns (4096); one would expect something like thi, but the constant
factor appears pretty bad; Gforth is not the fastest system around,
but why would deleting one element cost more than 2000 cycles?
- 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-09-03 15:03 +0200 |
| Subject | Re: Function Points |
| Message-ID | <103593693.MI7DYMrp4G@sunwukong.fritz.box> |
| In reply to | #15400 |
Mark Wills wrote: > On Sep 2, 10:15 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: >> It's a typical mildly disappointing result - the O(n log n) doesn't >> meet its promise, due to the random memory access pattern. The O(n²) >> algorithm shuffles a lot more memory around, but its access pattern >> is predictable. Some people say that modern x86 CPUs are tuned to >> bad code, and that seems to include bad algorithms ;-). > > I wonder if the cache is killing you? I suspect so, too. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-09-03 22:36 +0200 |
| Subject | Re: Function Points |
| Message-ID | <78671300948435@frunobulax.edu> |
| In reply to | #15400 |
Bernd Paysan <bernd.paysan@gmx.de> writes: Re: Function Points
> Bernd Paysan wrote:
>> I've written a binary heap now, it is considerably more code than the
>> O(n) code. I'd like to make a few benchmarks, before I post
>> comparisons.
> Ok, here's the benchmarking stuff.
> binary heap linear "heap"
> 10 inserts 17,666ns 9,287ns
> 10 deletes 15,941ns 6,960ns
> 256 inserts 164,048ns 452,609ns
> 256 deletes 476,276ns 251,134ns
> 4096 inserts 2,609,171ns 93,231,767ns
> 4096 deletes 12,061,005ns 55,881,857ns
[..]
Here are the iForth results (I had to remove the non-standard locals,
rdrop, the timer and the [IFUNDEF]). I must say that I was pleasantly
surprised that mini-oof.fs and string.fs worked immediately (after the
fixes) :-)
The trend is the same.
binary heap linear "heap"
-----------------------------------------+---------------------------
gForth iForth | gForth iForth
-----------------------------------------+---------------------------
10 inserts 17,666ns 14 us | 9,287ns 13 us
10 deletes 15,941ns 9 us | 6,960ns 6 us
256 inserts 164,048ns 55 us | 452,609ns 142 us
256 deletes 476,276ns 133 us | 251,134ns 99 us
4096 inserts 2,609,171ns 743 us | 93,231,767ns 15,493 us
4096 deletes 12,061,005ns 2,886 us | 55,881,857ns 7,712 us
Note: different hardware.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-09-06 20:27 +0200 |
| Subject | Re: Function Points |
| Message-ID | <12081597948435@frunobulax.edu> |
| In reply to | #15430 |
mhx@iae.nl (Marcel Hendrix) writes Re: Function Points
[..]
> Here are the iForth results
[..]
> The trend is the same.
[..]
I forgot to the test heap1.fs (non-OOP)
binary heap linear "heap" heap1
-----------------------------------------+---------------------------------
gForth iForth | gForth iForth iForth
-----------------------------------------+---------------------------------
10 inserts 17,666ns 14 us | 9,287ns 13 us 11 us
10 deletes 15,941ns 9 us | 6,960ns 6 us 7 us
256 inserts 164,048ns 55 us | 452,609ns 142 us 33 us
256 deletes 476,276ns 133 us | 251,134ns 99 us 83 us
4096 inserts 2,609,171ns 743 us | 93,231,767ns 15,493 us 368 us
4096 deletes 12,061,005ns 2,886 us | 55,881,857ns 7,712 us 1,895 us
Simpler *is* better :-)
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-09-02 04:00 -0500 |
| Subject | Re: Function Points |
| Message-ID | <g_SdnWHg-Zy2vd7NnZ2dnUVZ8tOdnZ2d@supernews.com> |
| In reply to | #15368 |
Paul Rubin <no.email@nospam.invalid> wrote: > I've been wondering, for example, how Forth multitaskers handle > event scheduling when there are a large number of tasks, and how > many tasks the traditional systems typically ran. It certainly > seems realistic to want to handle N>10000 in today's high > concurrency systems. They ran a fairly small number of tasks by today's high concurrency standards, for sure. The multi-tasker that Forth Inc used with great success for many years only had one queue, but it had almost zero overhead. This made it faster than its competitors, despite (because of?) its simplicity. But if a very large number of tasks were needed it was easy to change it to use two queues. On such a system handling a lot of tasks is simple: when one becomes ready, move it from the sleeping queue to the ready queue. The only slight awkwardness is the need to disable interrupts while manipulating the queues, and even that might be avoidable on some systems. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-09-03 10:40 -0700 |
| Subject | Re: Function Points |
| Message-ID | <d6ec27f5-9616-4286-b1df-77031a9a1c9b@googlegroups.com> |
| In reply to | #15280 |
the project I worked on two years ago was a battery monitor, and the customer wanted things like "accurate to about 1%" and "below 10µA current budget", "smaller number is better". Yes, the latter is partly a software requirement, as this thing was running on a b16 processor, and the current consumption can go up to milliamps if the CPU runs all the time at high clock speed. I had such a problem - using TI's MSP430 16-bit microprocessor solved that problem.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-03 20:26 +0200 |
| Subject | Re: Function Points |
| Message-ID | <5782942.yVAErjulpe@sunwukong.fritz.box> |
| In reply to | #15426 |
visualforth@rocketmail.com wrote: [citing me without proper quotation] > > the project I worked on two years ago was a battery monitor, and the > > customer wanted things like "accurate to about 1%" and "below 10µA > > current budget", "smaller number is better". Yes, the latter is > > partly a software requirement, as this thing was running on a b16 > > processor, and the current consumption can go up to milliamps if the > > CPU runs all the time at high clock speed. > > I had such a problem - using TI's MSP430 16-bit microprocessor solved > that problem. This was to be an embedded project, and the b16 consumes less current per operation than the Ti MSP430. Furthermore, we wanted the CPU to be integrated in one single chip, and the MSP430 is not available as softcore. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-08-27 11:49 -0400 |
| Subject | Re: Function Points |
| Message-ID | <503b9703$0$292$14726298@news.sunsite.dk> |
| In reply to | #15159 |
On 8/25/12 6:09 PM, Paul Rubin wrote: > Doug Hoffman <glidedog@gmail.com> writes: >> If you are ... testing each word [ or unit , added 8/27 dbh ] before >> continuing then that "+ instead of F+" should have become immediately >> apparent... > As I remember, it wasn't so immediately apparent what the problem was, > since the failure didn't occur til a little ways after the + happened. > And the symptom was that the program crashed without much clue about > what had happened. Interesting and surprising to hear that. > Anyway, if a type-checked language lets me write a page full of code and > fix the compile-time errors to usually get working program, while the > typeless counterpart makes me stop what I'm doing after basically every > single line to check for problems No. Stopping after every line isn't exactly necessary. Depends on the length of your words and what you would consider a coherent/testable unit (may be several words as a group). > the type checker would have caught > automatically, I'd say the type checker has made itself worthwhile. You might want to try StrongForth. Though it doesn't seem to have gained much traction. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-08-27 09:16 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7x4nno9uo9.fsf@ruckus.brouhaha.com> |
| In reply to | #15194 |
Doug Hoffman <glidedog@gmail.com> writes: >> And the symptom was that the program crashed without much clue about >> what had happened. > Interesting and surprising to hear that. Well, the issue probably would have been obvious to a more experienced Forth user--I remember staring at the code for a while and seeing nothing wrong, and having to go to some effort to debug the crash, and as mentioned it took a couple of repeats for the lesson to sink in. > No. Stopping after every line isn't exactly necessary. Depends on > the length of your words and what you would consider a > coherent/testable unit (may be several words as a group). Most of my words are one line. Testing several as a group does seem to make more sense. > You might want to try StrongForth. Though it doesn't seem to have > gained much traction. Yeah, if I were doing anything serious with Forth I suppose I'd consider it. For just fooling around as I'm doing, regular Forth's lack of safety probably builds character ;-).
[toc] | [prev] | [next] | [standalone]
| From | Josh Grams <josh@qualdan.com> |
|---|---|
| Date | 2012-08-28 22:46 +0000 |
| Subject | Re: Function Points |
| Message-ID | <503d4a3c$0$766$882e7ee2@usenet-news.net> |
| In reply to | #15194 |
Doug Hoffman wrote: <503b9703$0$292$14726298@news.sunsite.dk> > On 8/25/12 6:09 PM, Paul Rubin wrote: >> the type checker would have caught >> automatically, I'd say the type checker has made itself worthwhile. > > You might want to try StrongForth. Though it doesn't seem to have > gained much traction. My impression of StrongForth is that it's an experimental/toy system, not one intended for serious use. When Stephan came out with StrongForth.f and I tried it, I quickly gave up because it choked on several pieces of perfectly valid code which it simply didn't have the type signatures to handle. I had the impression that it would be relatively trivial to "finish" it so that it was much more comfortable to use, but figured it was a really bad sign that the author didn't care enough to do it in the first place... And the code wasn't particularly well organized or readable to my eye. I still think it would be really cool to take the concept and produce a clean, extensible static type checking library. I think you could do a lot of neat things with it without it being too obtrusive. --Josh
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2012-08-28 16:06 -0700 |
| Subject | Re: Function Points |
| Message-ID | <9d756859-50e6-4563-b2c0-430682f49e4c@googlegroups.com> |
| In reply to | #15228 |
Everything has it's place. I think systems are built in layers. 1) Machine code. 2) Assembly. 3) C, as the insecure cast acceptable, [] memory sequential indexing, and real control over byte ordering with a malloc. I would say forth can fit here. 4) A type abstraction language, with security proofs and restrictions on what can and can not be allocated or indexed into. Java fits here, although I would by choice have null removed and require a static null item declarator. Haskill could also fit here, even with it's higher order functions. 5) A weak typed all cast auto attempt script language, with underlying hidden types to ensure continual REPL or incremental operation without restart. Maybe even a reverse switch, and an execution buffer. 6) A strong functional interjection language, where available modules (auto profile space time optimized) are suggested to replace "intent code". The logic engine could even supply useful names for the possible behaviour which are detected at various "diagnosed effect entry points". 7) The far future..... where coders are metal and bank managers have no status. Cheers Jacko
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-08-28 20:50 -0400 |
| Subject | Re: Function Points |
| Message-ID | <503d6741$0$284$14726298@news.sunsite.dk> |
| In reply to | #15228 |
On 8/28/12 6:46 PM, Josh Grams wrote: > Doug Hoffman wrote: <503b9703$0$292$14726298@news.sunsite.dk> >> On 8/25/12 6:09 PM, Paul Rubin wrote: >>> the type checker would have caught >>> automatically, I'd say the type checker has made itself worthwhile. >> >> You might want to try StrongForth. Though it doesn't seem to have >> gained much traction. > > My impression of StrongForth is that it's an experimental/toy system, > not one intended for serious use. When Stephan came out with > StrongForth.f and I tried it, I quickly gave up because it choked on > several pieces of perfectly valid code which it simply didn't have the > type signatures to handle. > > I had the impression that it would be relatively trivial to "finish" it > so that it was much more comfortable to use, but figured it was a really > bad sign that the author didn't care enough to do it in the first > place... And the code wasn't particularly well organized or readable to > my eye. > > I still think it would be really cool to take the concept and produce a > clean, extensible static type checking library. I think you could do a > lot of neat things with it without it being too obtrusive. Perhaps. Every time I go back and take another look at it, as I did just now, StrongForth seems like extra work for no benefit-of-value at least to me. Maybe I'm just not being open-minded enough... -Doug
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-08-26 12:59 +0000 |
| Subject | Re: Function Points |
| Message-ID | <2012Aug26.145902@mips.complang.tuwien.ac.at> |
| In reply to | #15157 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Concerning being worth, I have far fewer type errors in Forth than in
>> Haskell.
>
>Do you mean type errors that the compiler didn't notice?
No, I mean that there are far fewer type errors in my Forth code than
type error messages for my Haskell code. Of course in Forth neither
the compiler nor the run-time system usually notices a type error, but
that's not what I claimed.
>When I wrote my first nontrivial Forth program, I several
>times said + when I meant F+, and of course the runtime happily added
>the wrong two stack items, causing later crashes that I then had to
>debug.
That's a type error, yes.
>Haskell's type system makes it feasible to write maintainable code in a
>quite abstract style involving higher-order functions, parametrized data
>types, and so on. This can also be done in Forth or Scheme but it gets
>confusing rather quickly.
I would have thought that it's the bread and butter of programming in
Scheme. Concerning parameterized data types, they are a solution for
a problem that you only have if you try to perform static type
checking.
> Having a computer keep track of the types
>takes cognitive burden off of the programmer,
I doubt that very much, because the programmer cannot write correct
programs if he does not keep track of the types himself.
> and makes refactoring
>easier (just fix the resulting type errors until the compiler stops
>complaining, and you probably have working code).
Yes, I can believe 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-08-26 22:24 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7xy5l0aow3.fsf@ruckus.brouhaha.com> |
| In reply to | #15175 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>Do you mean type errors that the compiler didn't notice? > No, I mean that there are far fewer type errors in my Forth code than > type error messages for my Haskell code. That could be a matter of differing programming styles between the two languages. Like in Forth, if you have a value denoting an optional string parameter, you might encode it as a null pointer if the string is not present; or maybe you'd pass it as a struct with some kind of flag indicating presence or absence. If there is some sort of error in passing this around, it's not a type error, it's just a runtime bug. In Haskell, you'd use a type of Maybe String, and then there are potentially type errors that in Forth would just be bugs. Then again it could be a matter of what you're used to. >>quite abstract style involving higher-order functions... > I would have thought that it's the bread and butter of programming in > Scheme. I think it's even more so in Haskell. Like the way one usually handles iteration with map or fold instead of with recursion. I haven't seen that much Scheme code written by experts though. > I doubt that very much, because the programmer cannot write correct > programs if he does not keep track of the types himself. Yes of course you have to think about the types, but (compared to a typeless language) you can let up a little on vigilance towards them and devote your attention to other aspects of the program, since the typechecker will catch the errors automatically. It's just like interactively trying things in Forth except it's at compile time. You can write some code that looks reasonable, then throw it at the typechecker to see what happens, instead of agonizing over it checking all the type assignments by hand. Also, types can get very complicated, like in that red-black tree example, where types track everything that happens to a complex data structure through a complicated function. The corresponding situation in Forth might be to treat stack effects as types, so some internal word in the program may be operating on a stack dozens of levels deep, with a hypothetical type checker keeping track of the whole stack contents so it could (maybe only sometimes) statically detect overflow. A human normally wouldn't track that carefully.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2012-08-23 15:02 -0700 |
| Subject | Re: Function Points (was: Comparative Productivity of Programming Languages) |
| Message-ID | <42627778-2321-4ec4-beb0-9a3103b11692@googlegroups.com> |
| In reply to | #15122 |
On Thursday, August 23, 2012 10:50:54 AM UTC-4, Anton Ertl wrote:
> However, for other applications I have no idea
> how to determine function points for them. [...]
My point wasn't that function points are some ideal measure but that they are an /objective/ measurement. Unlike some of the more squishy subjective metrics some people use in these discussions about productivity, function points are something we can actually talk about. I don't know the specifics of how function points were calculated in this particular study, but it's reasonable to assume they are using one of the standard tools out there that produce such statistics.
So we can talk about function points-- where they make sense, where they don't, when they reflect something essential about code programmers write in a language, where it is meaningless, etc. If we were talking instead about polls of programmer's opinions or anecdotal accounts about how using language X they finished a job Y times faster, then there really isn't much of a conversation possible.
> Given the differing functionality of the compared
> parser generators, it would be useful for that kind
> of study to get a number that represents the
> functionality and can be related to the SLOC (source
> lines of code) metric for the implementation. Are
> function points usable for this kind of application?
Possibly, although for the purpose of determining productivity, I don't see much value in physical SLOC. Some languages are more vertical than others and unless people believe that hitting the return key is a major source of productivity loss, then it makes more sense to (consistently) measure logical SLOC instead:
: square ( x -- x^2 )
dup * ;
let square x = x * x
int square(int x) {
return x*x;
}
These trivial examples in Forth, F#, and C are to me all one logical SLOC.
Even better might be to come up with some kind of cognitive measure of the code. This is a bit more tricky, but I think it's possible. For example, here's a silly Forth function:
: sumRange ( low high -- sum )
1+ 0 -rot swap do i + loop ;
When I look at this code, I abstractly see five things:
1. A definition of a new word.
2. Setting up the loop bounds.
3. Preparing an accumulator.
4. A loop with ...
5 ... a simple one operation body.
So if I was to come up with a cognitive metric, I might say that sumRange had a count of 5; there are five distinct things happening in this code. Compare to Haskell:
sumRange low high = sum [low .. high]
1. Definition of a new function.
2. Generate list of range.
3. Sum list.
I'd say this has a cognitive count of 3. And I would say that in this trivial example, the Haskell programmer is more productive than the Forth programmer in the sense that there is less on the programmer's mind to express the same idea. Now, if this holds for larger non-trivial programs is a matter of debate and discussion, but the methodology I'm using here is objective.
> Really? My experience with Haskell is that I get
> type error messages that are hard to comprehend.
I find German-language text to be hard to comprehend, mostly because the only German I know comes from Einsturzende Neubauten lyrics. I'm guessing you don't have that problem.
> OTOH, C type checking complicates things, but is
> still simple enough that I can get out of C what
> I want (or maybe I just have more experience
> with it). So, yes, Haskell type checking is
> different, but not in the way you imply.
Incorrect. I specifically referenced pattern matching and type inference. There is no equivalent to either in C. Pattern matching (especially on discriminated unions) and related features (like data destructuring) use type information at run-time, which isn't even a concept in C.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-08-25 14:57 +0000 |
| Subject | Re: Function Points (was: Comparative Productivity of Programming Languages) |
| Message-ID | <2012Aug25.165724@mips.complang.tuwien.ac.at> |
| In reply to | #15126 |
John Passaniti <john.passaniti@gmail.com> writes:
>On Thursday, August 23, 2012 10:50:54 AM UTC-4, Anton Ertl wrote:
>> However, for other applications I have no idea
>> how to determine function points for them. [...]
[...]
>So we can talk about function points-- where they make sense, where they do=
>n't, when they reflect something essential about code programmers write in =
>a language, where it is meaningless, etc.
Well, yes? That was my question. For which applications do they make
sense? Do they make sense for parser generators? How do I use them
there?
> If we were talking instead about=
> polls of programmer's opinions or anecdotal accounts about how using langu=
>age X they finished a job Y times faster, then there really isn't much of a=
> conversation possible.
Why not? Time seems to be at least as objective a metric as function
points.
>Possibly, although for the purpose of determining productivity, I don't see=
> much value in physical SLOC. Some languages are more vertical than others=
> and unless people believe that hitting the return key is a major source of=
> productivity loss, then it makes more sense to (consistently) measure logi=
>cal SLOC instead:
>
>: square ( x -- x^2 )
> dup * ;
>
>let square x =3D x * x
>
>int square(int x) {
> return x*x;
>}
>
>These trivial examples in Forth, F#, and C are to me all one logical SLOC. =
You are welcome to repeat the study I did with logical SLOC. Instead,
I just counted the physical SLOC, and for the two programs that I
looked at more closely, I looked at an example of equivalent code to
see how horizontal or vertical the code was written.
BTW, I would have loved to use time instead of SLOC, but I had no time
data.
>> Really? My experience with Haskell is that I get=20
>> type error messages that are hard to comprehend.
>
>I find German-language text to be hard to comprehend, mostly because the on=
>ly German I know comes from Einsturzende Neubauten lyrics. I'm guessing yo=
>u don't have that problem.
And?
>> OTOH, C type checking complicates things, but is=20
>> still simple enough that I can get out of C what=20
>> I want (or maybe I just have more experience=20
>> with it). So, yes, Haskell type checking is=20
>> different, but not in the way you imply.
>
>Incorrect. I specifically referenced pattern matching and type inference. =
> There is no equivalent to either in C.
Yes, that's probably the reason why C type checking is still simple
enough.
- 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]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web