Re: euForth
>Peter Lawrence wrote:
>
>> Applying the adage "make it work first, make it
>> efficient second", I think we can agree that the
>> "portable" (i.e. implementable) first step is no
>> way to leave a production system, for the very
>> reasons you describe.
>
>There's a slogan I live by.
>
>> But on the other hand if you just happen to have
>> a highly tuned, platform specific, commercial Forth
>> you can use as a back end - you might even end up
>> with a performance gain on a bespoke Euphoria
>> implementation done in the usual way.
>
>To beat a dead horse - not if your data structures are disk-based. A FORTH
>port of Euphoria could be pretty cool, but I doubt that it's going to beat
>Euphoria at speed tests. For one thing, Euphoria is (apparently) not based
>on a stack machine, and doesn't have the overhead of threading. On these two
>points alone, it's got less overhead than FORTH on every call.
Ah, but the highly tuned, platform specific, commercial Forths inline
practically everything - down to machine code - so the generated machine
code isn't so heavily stack based. They also use the Forth
secondary/primitive structures to give hints to their peephole optimising.
The disk overhead is more explicit than with other virtual memory approaches
but they're not essentially or qualitatively different. Taken together that
means that there's no inherent reason for less efficiency - you just have to
benchmark to find the winners.
Having said that, yes, most Forths aren't highly tuned, platform specific,
commercial Forths - but don't rule them out in advance. PML.
GST+NPT=JOBS
I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.
See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.
|
Not Categorized, Please Help
|
|
