An idea for forth?

forth

    Sponsored Links

    Next

  • 1. 0 ALLOCATE
    According to the standard 0 ALLOCATE is legal. Apparently a block is returned with a length of zero. At first sense this makes not much sense. Is it intentional? What are circumstance where one would want to do that? Groetjes Albert

An idea for forth?

Postby jacko » Thu, 21 Apr 2011 04:39:08 GMT

 http://www.**--****.com/ 

Re: An idea for forth?

Postby John Passaniti » Thu, 21 Apr 2011 06:29:14 GMT



You should factor your Usenet posts.

As I just wrote, the only value I see this kind of thing having is as
a warning to the programmer about repetitive sequences of code.  I
would expect that the benefit for Forth would only be for bad Forth
programmers, or possibly uncoordinated Forth projects where you had
multiple programmers working on one body of code with little
communication or review of that code.

Re: An idea for forth?

Postby jacko » Thu, 21 Apr 2011 07:48:10 GMT

Google advised repost as they were having a version revision issue with groups beta. "Not clever" well I'd say premature factorization is the root of all evil, and the software tool should display common factors, and ask for potential function or word names. The particular algorithm suggested is optimal in space, though not in time execution. Except perhaps for inserting 'non consequential nop sequences' to extend the maximal coverage of a factor..

Cheers Jacko

Re: An idea for forth?

Postby John Passaniti » Thu, 21 Apr 2011 10:49:09 GMT



Opinions are nice.  Examples to support the claim are better.
Factoring-- at least as Forthers use the word-- is replacement of
repetitions of code behind a (hopefully) meaningful name.  Given that
a factor removes repetition, it's hard to imagine anything but
incredibly narrow corner cases where this is either "premature" or
where it could lead to metaphorical "evil."  The cost of a factor is
at worst a call to a subroutine and at best nothing as the expansion
of a macro.


Yes, as I wrote, I would favor this technique not being used for
automatic factoring, but rather as a code analysis tool to identify
possible factors.


So?  Those who value the algorithm are likely trading off the time
they would have spent factoring the code against the dramatically
shorter time for an algorithm to do the work for them.  Even replacing
BWT with the slowest brute-force method is likely at *least* an order
of magnitude faster than the programmer investing the time to identify
and implement the same factors.  That being said, the primary value of
factoring isn't reduction of executable code size; it's increasing the
comprehension of the code by simple abstraction.  This optimization
provides no benefit towards that since it works on the final object
code, which is why I don't find much value in it.  And as I wrote
before, this kind of optimization obviously has very little benefit on
code that is well-factored already.  So the value it has to
experienced programmers is minimal.

So, as an "idea for Forth," it certainly seems like a bad idea.  It
doesn't improve source code, and only has benefit for poor programmers
who don't factor, or for poorly managed projects with multiple
programmers who don't communicate.  At best, the value would be to get
back an objective number of how many bytes of code could be factored.
That could serve as a crude metric of the programmer's skill in
factoring.

Re: An idea for forth?

Postby jacko » Thu, 21 Apr 2011 11:24:14 GMT

and a REVERSE ( n -- ) word to not execute the previous n words (not including return, would allow a greater coverage of factors to apply when they had a common beginning, and so even more compact code. I don't see ANY programmers using this space technique to reduced MB/s in heavy cache systems, do you? (sarcasm)

Cheers Jacko

Re: An idea for forth?

Postby John Passaniti » Thu, 21 Apr 2011 11:59:14 GMT



Unnecessary.  If you understand how BWT works and how it would apply
to this optimization, reversing doesn't give you anything more.


No, I don't.  For all the reasons I stated before.  A good programmer
naturally factors the code well, and any automatic factoring
optimization isn't going to find much if anything to operate on.  A
programmer who cares about fitting code in a cache is likely more
sophisticated and more likely to *design* their code to do what they
want up-front.  A programmer who just banged on the keyboard and hoped
that a auto-factorization tool would somehow convert their code into
something that met their requirements is already lost.

Still interested in a defense of your statement that "premature
factorization is the root of all evil."  The usual adage is that
premature *optimization* is the root of all evil, and that statement
has plenty of support.  But factorization isn't an optimization.  At
least, it's not treated as an optimization in modern software design
and engineering.  It's more properly thought of as a tool to reduce
complexity and increase comprehension of code.  It has a useful side
effect that it reduces code size (at the expense of a small amount of
increased execution time), but that's not the primary goal.

Re: An idea for forth?

Postby jacko » Thu, 21 Apr 2011 12:11:07 GMT

: aword dup 2 * 4 + ;

: bword 10 aword + ;

: cword 24 aword 1 reverse ;

=> : cword-is 24 dup 2 * 4 ;

if aword occurs 47 times as a natural factor but 66 times with various reverses then the factor gain is (66-47)*some other numbers. In a system where the reverse can be a speculative execution cutback, the effective MB/s/MIPS can be reduced to a lower I cache load. That's my point. Calculation of reversals is best automated.

Cheers Jacko

Re: An idea for forth?

Postby John Passaniti » Thu, 21 Apr 2011 23:20:41 GMT



As usual, understanding your messages seems to require either a secret
decoder ring that I never got in my morning cereal, or some private
context that exists between your ears.

So let me see if I understand this:  Your idea is that programmers
don't do any factoring, because factoring would interfere with
automated attempts to identify factors.  Indeed, your approach would
work best if the programmer went out of their way to minimize the
number of definitions-- ideally only one--  and just write all
programs as huge monolithic words with as many repeated sequences as
possible.  After all, definitions get in the way of automated
factoring.

So, did I get that right?

Here's a better idea:  Instead of treating the code compiled by the
Forth compiler as sacrosanct, how about the Forth compiler generating
a representation of code that can be maximally expanded so as to
exploit the tiny fractions of larger derived factors you believe are
possible.  That way, the programmer doesn't have to write the poor-
quality code that your brilliant idea requires for maximum benefit of
this optimization.  The programmer can instead write high-quality code
that can then later undergo analysis for larger factoring patterns the
programmer may have missed, saving a fraction of a percent of
instruction cache pressure.  (sarcasm)

Here's an even better idea:  Let's take some corpus of Forth code--
code written by both novices and those who are experienced-- and
actually test the value of your idea on real code.  To test this, we
have the Forth compiler emit the stream of primitives that make up a
definition.  So for the following definitions ...

: square dup * ;
: cube dup square * ;
: test 3 cube ;

.... we follow the path the inner interpreter would take executing our
top-level definition.  So "test" becomes:

dup dup * *

We can then take this expansion of the top-level definition and then
use automation to search for factors.

If you're right, you expect that there will be many novel factors that
programmers miss.  If I'm right, I expect that in average to expert
code, few if any novel factors will be found and that the effort
behind this optimization would be a waste; it would be far better to
train programmers to write better code in the first place.

Re: An idea for forth?

Postby Albert van der Horst » Fri, 22 Apr 2011 02:57:38 GMT

In article < XXXX@XXXXX.COM >,



Factoring doesn't merely reduce the size of the executable code.
It also reduces the size of the source. This increases the reliability
of code as it is well known that the errors/line is reasonably
independant of the type of code or language.

Furthermore it is my take that code that is used differently and from
several places is less likely to contain bugs, especially for code
that lacks comprehensive unit tests. Not only gets it more coverage
but the interface gets more attention.

Groetjes Albert



Re: An idea for forth?

Postby John Passaniti » Fri, 22 Apr 2011 03:26:52 GMT

On Apr 20, 1:57m, Albert van der Horst < XXXX@XXXXX.COM >



Well yes, that's part of my argument here-- that the primary benefit
of factoring isn't that it reduces executable size, but that it makes
the source more comprehensible.  So tools that automatically factor
code only provide limited value.  And yes, factoring increases
reliability, at least in so far as that abstracting common sequences
of code allows you to test them easier and have higher confidence in
the reliability of the code that reuses factors.  And that again is
why tools to automatically factor code have limited value.

Re: An idea for forth?

Postby jacko » Fri, 22 Apr 2011 04:02:15 GMT

n Wednesday, 20 April 2011 15:20:41 UTC+1, John Passaniti wrote:

No, write readable code, simple.


And all the common factors would be in a dll right?


No but the expansion in this case was better to do. But in any case it's not just about factoring, but adding the possibility of more than one entry point to a factor, and also more importantly for the future more than one exit point without if tests within the factor, buy using transactional memory ideas across the boundary of exit with multiple commit styles. As this could back prune many OoO instructions (whose results aren't needed is this path), each of which may have been speculative.

This idea can be extended to ALL instructions in hardware can be made to have multiple speculative meanings (each run in parallel) a subset of which can be committed by future dependent instructions. Achieving lets say greater than 1 functional unit execution path using only 1 instruction stream.

Cheers Jacko

Re: An idea for forth?

Postby Mat » Fri, 22 Apr 2011 07:27:43 GMT



Can I understand "1 reverse" as lisp alike macro compilation of
"aword" ? If that is the case, why not implement something like this:

24 'aword :cword

' :- copy code of prior defined word
: :- compile 'exit and add new dictionary entry

If that look cryptic, I'm sorry but it's late and I need some sleep
maybee

Re: An idea for forth?

Postby jacko » Fri, 22 Apr 2011 11:07:49 GMT

it's not a code generation macro, it's a don't complete last n words in a speculative execution.

Re: An idea for forth?

Postby John Passaniti » Fri, 22 Apr 2011 13:52:09 GMT

n Apr 20, 3:02m, jacko < XXXX@XXXXX.COM > wrote:

But by definition, writing readable code (in part) requires
factoring-- and that factoring gets in the way of the kind of static
analysis needed to automatically create factors. You don't seem to
value defending your own words, but that seems to have been the point
of your "premature factorization is the root of all evil" comment--
that programmers who factor will reduce the ability of automated tools
used to optimally identify factors. Or something.


A DLL is an operating system specific technology for encapsulating
code so that it can be dynamically linked with other code. I hope you
don't mean DLL in the operating system specific sense and instead mean
it in the generic functional sense. In that case, the answer is no,
the common factors need not be in a DLL. Certainly if you are running
code on an operating system that provides such dynamic linking
capabilities already, you can save yourself a lot of effort by reusing
that plumbing. But no, nothing either you or I have written requires
dynamic anything. All this could be done statically.

But *AGAIN*, I believe the effort involved in this particular
optimization is a complete waste. The gains you'll get on well-
written code will be minor, and those gains will do nothing to
increase the readability or comprehension of the code. Forth has long
had a tradition of eschewing complex optimizations in favor of putting
the responsibility of writing quality code on the programmer. That
approach is somewhat debatable for certain classes of optimizations.
Certainly Forth, Inc. and MPE both think that there are some classes
of optimizations that do have value. But this particular
optimization-- where the programmer's fundamental responsibility of
writing high quality (and thus, well-factored) code? I would be very
surprised if either company would find much value in that. And I
would be even more surprised to find many Forth programmers who would
find it valuable as well.

The only value I see for this optimization is as a tool to assist the
programmer in identifying factors. And in fact, there are tools that
already do this to a degree for other languages. Tools like SONAR
(which is primarily used with Java) has the ability to find repeated
sequences of code and warn the programmer that some factors should
probably be made. I think a tool like that Forth might be useful.


I think you missed a few potential buzz-phrases in there. Would you
like to try again, citing other {*filter*}a that will help demonstrate the
law of diminishing returns?

I've seen nothing concrete here that suggests that significant
performance gains would be the result of this optimization, except in
the case of really awful programmers who haven't learned to factor.
One can keep layering on potential optimizations and speculate about
how they might save a byte here or a cache line there. Or instead of
speculation, one could do as I suggested and do some rough experiments
that replace speculation with cold hard numbers that may not give a
perfect answer, but which would put an upper bound on the performance
gains that are possible. As an engineer, I don't need to waste my
time implementing every possible idea and then seeing how well they
work. I can study fragments of a proposed solution and see early on
if the approach I have in mind has potential. You can do the same.


Have you c

Re: An idea for forth?

Postby jacko » Fri, 22 Apr 2011 14:47:05 GMT

n Thursday, 21 April 2011 05:52:09 UTC+1, John Passaniti wrote:

I suppose you had to factor my speech into such a falsehood to enjoy your perfection. Factoring for code readability is not premature, but to considerit in all cases as perfection is ...


Need not be is not the same as could be. And I've certainly written things which needed dynamic DRAM.


Eschew all you need, but when C compilers start turning out better factored machine code than forth compilers...


Your one of the folks who still fancies himself against big blue at a nice game of chess.


How about one factor per core.


I never asked you to implement it, the post was titled with a question. I was not asking about the potential for the idea, as the gcc seem not to be so poo-poo, but only asked if this was a good idea for forth, so as to perhaps demonstrate the technical discussion or advancement which seems to be lacking in this thread. Your accusation of speculation on the one off effort of optimization of a compile, versus the multiplicity of fractions of a percent times millions of instances of code execution times microwatts per instuction, shows you have shares in some battery, nuclear and or oil company, and do not wish to see their value drop.


I see no reason to imagine the many universes explanation to be true. But the knowing that two instructions could be executed out of order, and deciding which way round to compile them to express a side channel of information to another decode engine is interesting...


Don't waste my time then making something specific, which you have not tested enough to be able to do anything more than speculate about it, just write something down like I had, and make some more cash to pay up the bills to increase the value of your shares, so obtaining real results for you?

Cheers the financially challenged space monkey

Similar Threads:

1.IDE Idea, was Forth in 3D, Say Hello, ...

2.An idea for forth?

3.Writing a journal article - Forth ideas

4.What would be people's ideas on a Forth spreadsheet

I have been looking at text-userland lately, and one thing that has
annoyed me is that the most common open source spreadsheet is "sc", and
the versions I have found are Y2K buggy --- the date functions do not
work with the new millenium.

Of course a text-userland spreadsheet written in an open forth would
also provide the opportunity to extend the functions in forth, which is
on the shopping list for any spreadsheet.

And if it is more compact than "sc", it would also provide a greeting
card for forth in the MinisculeLinux space (on top, of course, a
text-userland suduko problem generator, entry, "hand" solver, and
automatic solver toolkit, where so much progress has been made on the
latter part at least).

How do you get started on a Forth spreadsheet?  I think it is safe to
target it to general linux term / ansi.sys type console functionality
to get into both the OpenDOS and FloppyLinux spaces.

5.Math article / Forth ideas

6. [personal] Only Forth also Ideas

7. Only Forth also ideas

8. Nested conditional expressions ---- good idea/bad idea?



Return to forth

 

Who is online

Users browsing this forum: No registered users and 58 guest