Re: [Factor-talk] Factor-talk Digest, Vol 42, Issue 10
On Tue, Oct 13, 2009 at 10:04 PM, Hugh Aguilar wrote:
> I said in the book that Factor makes an excellent prototyping language for
> Forth. The programmer can get a prototype working in Factor, and only
> concern himself with the integer-overflow issue when he is porting it to
> Forth for the production version. This is better than trying to write a
> program from scratch, which involves a lot of high-level thinking, while
> simultaneously dealing with a lot of low-level issues --- as done in Forth
> right now.
One nice thing is that in Factor you can write high-level arithmetic
code that still performs fast, because the compiler performs type
inference as well as take advantage of various arithmetic identities
to eliminate unneeded generality.
For example, suppose you have this piece of code:
255 bitand 300 * 17 +
Naively, it would need to do dispatch between bignums and fixnums in
'bitand', '*' and '+', and * and + would have overflow checks.
However, the compiler knows that the output of '255 bitand' is in a
fixnum in the range 0..255, and the rest follows:
( scratchpad ) [ 255 bitand 300 * 17 + ] optimized.
[
255 >R >fixnum R> fixnum-bitand 300 fixnum*fast
17 fixnum+fast
]
Notice that the 'optimized.' word rewrote the high-level Factor code
into something that still looks sort of like Factor, but seemingly
uses low-level words whose names suggest they are primitive operations
of some sort.
These low-level words map more or less to machine instructions, but
not before some more optimization passes which use registers instead
of the stack. We can ask the optimizer to go down a level and show us
the code after conversion to register-based form.
( scratchpad ) [ 255 bitand 300 * 17 + ] test-mr.
=== word: ( gensym ), label: ( gensym )
_label 0
_prologue T{ stack-frame { total-size 32 } }
_label 1
##load-immediate RAX 2040
##inc-r 1
##replace RAX R 0
_label 2
##call >fixnum
_label 3
##peek RAX D 0
##peek RCX R 0
##and RAX RAX RCX
##mul-imm RAX RAX 300
##add-imm RAX RAX 136
##inc-r -1
##replace RAX D 0
_label 4
_epilogue T{ stack-frame { total-size 32 } }
##return
_spill-area-size 0
There is a subroutine call to convert the first input to a fixnum (the
##call instruction), but the rest of the operations are done with
machine instructions without even touching the stack, except to load
input values and store the result. Intermediate values are in
registers and the constants are immediate operands.
Those ##instructions are not bytecode for an interpreter or anything;
they map more or less to x86 or PowerPC instructions:
( scratchpad ) [ 255 bitand 300 * 17 + ] disassemble
00010f0aa8e0: 49b8e0a80a0f0100 mov r8, 0x10f0aa8e0
00010f0aa8ea: 682000push dword 0x20
00010f0aa8ef: 4150 push r8
00010f0aa8f1: 4883ec08 sub rsp, 0x8
00010f0aa8f5: 48b8f807 mov rax, 0x7f8
00010f0aa8ff: 4983c708 add r15, 0x8
00010f0aa903: 498907mov [r15], rax
00010f0aa906: e8d59cdbfecall 0x10de645e0
00010f0aa90b: 498b06mov rax, [r14]
00010f0aa90e: 498b0fmov rcx, [r15]
00010f0aa911: 4821c8and rax, rcx
00010f0aa914: 4869c02c01imul rax, rax, 0x12c
00010f0aa91b: 4881c08800add rax, 0x88
00010f0aa922: 4983ef08 sub r15, 0x8
00010f0aa926: 498906mov [r14], rax
00010f0aa929: 4883c418 add rsp, 0x18
00010f0aa92d: c3ret
You were concerned about the efficiency of 2bi in your book. Compare
this code that uses 2bi:
( scratchpad ) [ [ + ] [ * ] 2bi ] test-mr.
=== word: ( gensym ), label: ( gensym )
_label 0
_prologue T{ stack-frame { total-size 32 } }
_label 1
##peek RAX D 1
##peek RCX D 0
##inc-r 2
##replace RAX R 1
##replace RCX R 0
_label 2
##call +
_label 3
##peek RAX R 1
##peek RCX R 0
##inc-d 2
##inc-r -2
##replace RAX D 1
##replace RCX D 0
_label 4
_epilogue T{ stack-frame { total-size 32 } }
##jump *
_spill-area-size 0
With the same expression with 2dup/-rot:
( scratchpad ) [ 2dup + -rot * ] test-mr.
=== word: ( gensym ), label: ( gensym )
_label 0
_prologue T{ stack-frame { total-size 32 } }
_label 1
##peek RAX D 1
##peek RCX D 0
##inc-d 2
##replace RAX D 1
##replace RCX D 0
_label 2
##call +
_label 3
##peek RAX D 2
##peek RCX D 1
##peek RDX D 0
##replace RDX D 2
##replace RAX D 1
##replace RCX D 0
_label 4
_epilogue T{ stack-frame { total-size 32 } }
##jump *
_spill-area-size 0
In the next example, there's no stack operations inside the loop at
all, despite the fact that 'times' is a library word implemented in
terms of dozens of quotation-constructing and quotation-consuming
words -- they all get optimized down into a loop by the compiler:
( scratchpad ) [ 1 10 [ 17 + 29 * ] times >fixnum ] test-mr.
=== word: ( gensym ), label: ( gensym )
_label 0
_label 1
##load-immediate RAX 8
##load-immediate RCX 80
##load-im
Re: [Factor-talk] Factor-talk Digest, Vol 42, Issue 10
Hugh Aguilar wrote: > largely because it supports mixed-precision arithmetic. Even in the 1980s > when Forth was compiling to threaded code and C was compiling to > machine-code, Forth still beat C in speed when used in applications that > involved a lot of arithmetic (nowadays most Forth systems compile to > machine-code and often beat C on all manner of applications). Most of the benchmarks the Forth compiler vendors post don't make that claim. Usually they claim to produce a more maintainable system while still achieving high speed and extremely small image size. > I said in the book that Factor makes an excellent prototyping language for > Forth. The programmer can get a prototype working in Factor, and only > concern himself with the integer-overflow issue when he is porting it to > Forth for the production version. This is better than trying to write a > program from scratch, which involves a lot of high-level thinking, while > simultaneously dealing with a lot of low-level issues --- as done in Forth > right now. Now, that's an interesting perspective. When doing that, one should be aware of two things: first, that's not what Chuck Moore would do, and second, that's not what Slava would do. Slava doesn't really have a Forth background, so Factor often has some very primitive differences which would make a port painful. Chuck, of course, would practice what he calls "thoughtful programming"; one of the first practices is to use your programming language as a notation system, both to clarify your thought and to clarify your notation. Switching languages in mid-problem doesn't seem like a strong practice in that respect. Aside from that, it's risky to port from a language with garbage collection to a language that prefers static memory structures (and that's only the start of the differences). > It seems to me that Factor is tied to Forth because you decided to use a > Forth-like syntax (rather than a Lisp-like or Java-like syntax) --- and the > only reason for using Forth-like syntax was to support Factor/Forth ports. I'm certain you're mistaken here. Slava wasn't imitating Forth. He did not use a Forth-like syntax; if anything, he used a Joy-like one. > When Factor diverges too far from Forth syntax however, then Factor betrays > the very purpose of Factor. Factor can be a super-Forth, that supports > dynamic-OOP and garbage-collection and other niceties that Forth doesn't > provide (because they would be too slow), but it should still continue to be > a Forth. As a Forth programmer FAR more than a Factor programmer, I know that this is not an accurate or useful characterization. Factor is NOT a super-Forth; it's not even a superset of a partial Forth. It's a completely different language running on a completely different machine model. The only thing it shares in common with Forth is the general idea of a concatenative language, and at that, Forth was never meant to be a concatenative language. > Even if you like Joy, with its DIP and all that, this is immaterial > to the main purpose of programming, which is to write hella-fast programs. > That is what the customer wants. There's more than "hella fast" to a programming language; if that were all, we'd never have left assemblers. Heck, my customer wants Java (sigh). -Wm -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor-talk Digest, Vol 42, Issue 10
> Message: 1 > Date: Sat, 10 Oct 2009 17:33:37 -0700 > From: "William Tanksley, Jr" > Subject: Re: [Factor-talk] "Factor Versus Forth" --- the book > To: factor-talk@lists.sourceforge.net > Message-ID: > <37d01e670910101733i544198f9hc42107dd9ee9d...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Doug, I see your purpose and appreciate it; I think you explained well > why Factor separates data flow from operators. However, Forth's */ > operator has one additional purpose; it's really merely to be able to > avoid typing a space between star and slash. It's actually a scaling > operator which uses a double-length intermediate result, so that as > long as your final answer fits into a single-length integer, there > will be no overflow. In Forth, at that time, that's a very significant > guarantee. > > Factor doesn't need that; it has other ways to avoid integer overflow. I agree that Factor is easier to use than Forth in regard to arithmetic, because the programmer doesn't have to worry about integer overflow and other such low-level concerns. On the other hand though, Forth is hella-fast largely because it supports mixed-precision arithmetic. Even in the 1980s when Forth was compiling to threaded code and C was compiling to machine-code, Forth still beat C in speed when used in applications that involved a lot of arithmetic (nowadays most Forth systems compile to machine-code and often beat C on all manner of applications). I said in the book that Factor makes an excellent prototyping language for Forth. The programmer can get a prototype working in Factor, and only concern himself with the integer-overflow issue when he is porting it to Forth for the production version. This is better than trying to write a program from scratch, which involves a lot of high-level thinking, while simultaneously dealing with a lot of low-level issues --- as done in Forth right now. It seems to me that Factor is tied to Forth because you decided to use a Forth-like syntax (rather than a Lisp-like or Java-like syntax) --- and the only reason for using Forth-like syntax was to support Factor/Forth ports. When Factor diverges too far from Forth syntax however, then Factor betrays the very purpose of Factor. Factor can be a super-Forth, that supports dynamic-OOP and garbage-collection and other niceties that Forth doesn't provide (because they would be too slow), but it should still continue to be a Forth. Even if you like Joy, with its DIP and all that, this is immaterial to the main purpose of programming, which is to write hella-fast programs. That is what the customer wants. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] "Factor Versus Forth" --- the book
> > Message: 4 > Date: Mon, 12 Oct 2009 01:07:47 +0200 > From: Samuel Tardieu > Subject: Re: [Factor-talk] "Factor Versus Forth" --- the book > To: factor-talk@lists.sourceforge.net > Message-ID: <87iqelcyws@willow.rfc1149.net> > Content-Type: text/plain; charset=us-ascii > > Hugh> A more modern microprocessor such as the PIC18 is also pretty > Hugh> simple, and would be another reasonable choice. > > PIC18 with their unique work register are pretty awful to work > with. Trust me, I've written a Forth compiler for this architecture... Actually, after I suggested the PIC18 I realized that it would be a bad choice. It doesn't really have any addressing modes. There is no indexed addressing like in the 65c02 --- the programmer is expected to simulate addressing modes by writing macros. It is "pretty awful." A much better choice would be the 8-bit AVR. That is a hella-fast modern processor that people would be interested in from a practical standpoint (unlike both the 65c02 and the 8080), and it has a fairly straightforward architecture complete with addressing modes. If this book is going to be read by Forth programmers, then it is going to have to discuss real-word programming --- meaning micro-controllers --- because that is what they care about. P.S. for Chris Double --- I will read up on that Joy link that you provided. Maybe then I can come to grips with DIP and all that, which largely confuse me right now. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] new blog post: adding CAS instruction to factor's compiler
Hi Slava, Hi everyone, I've written a post about adding an atomic CAS instruction to the Factor compiler: http://phildawes.net/blog/2009/10/13/factor-compiler-adding-instruction/ The code isn't ready for merging yet (e.g. no PPC implementation) but I wanted to knock out the blog post while I was still motivated. @Slava: if you get a chance could you please take a look at this for any glaring factual errors. I've checked the markup this time so you shouldn't have to debug my blog for me! Many thanks, Phil -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Bootstrap and Build time - 6 month view
On Tue, Oct 13, 2009 at 8:22 AM, Adam wrote: > Talking in #concatenative last night with Slava about graphing the > bootstrap and load-all times lead to this graph I thought I'd share > with the list: > http://content.screencast.com/users/hiatoms/folders/Jing/media/812d23fa-c7e0-45e4-bf38-ba7e985ed226/2009-10-13_0500.png > > Pretty nice to see everything stabilize and load-all times go way down. > That might be easier to see on a log scale. The outlier is squishing the rest of the data, possibly hiding some useful shapes. -- Darrin -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Bootstrap and Build time - 6 month view
Talking in #concatenative last night with Slava about graphing the bootstrap and load-all times lead to this graph I thought I'd share with the list: http://content.screencast.com/users/hiatoms/folders/Jing/media/812d23fa-c7e0-45e4-bf38-ba7e985ed226/2009-10-13_0500.png Pretty nice to see everything stabilize and load-all times go way down. -Adam -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] html.streams
Hey Slava, The fix is in my "ui" branch at git://github.com/klazuka/factor.git It is a single commit with SHA: 5932d2e8a125f201f1d81c7f347781ead00a8182 -keith -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] question about SIMD and alien arrays
On Mon, Oct 12, 2009 at 9:51 PM, Ed Swartz wrote: > Hi, > > Is there any support currently, or a plan to support, vector words using > SIMD on alien arrays? This is planned. The first step is to get the SIMD primitives worked out, after that we can start writing higher-level libraries taking advantage of them. Using SIMD for vector ops on specialized arrays is high on the list. For another example of what is possible by building on top of the SIMD support, take a look at the math.matrices.simd vocabulary; it provides efficient 4x4 matrices. Slava -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] some doc issues with SIMD
Thanks. I've fixed all the issues you reported.
Slava
On Mon, Oct 12, 2009 at 9:41 PM, Ed Swartz wrote:
> Hi,
>
> I have noticed the recent work in SIMD vectors and noticed some docs
> issues in the git head.
>
> -- The SIMD: page says "type" is a scalar C type, which is right, but it
> references the "SIMD vector types" page which mentions the vectorized
> types (e.g. float-4). This causes a little confusion since one may
> attempt to enter, e.g., "SIMD: float-4" instead of "SIMD: float".
>
> -- Other pages in the SIMD category, like "Writing efficient SIMD code",
> don't use the SIMD: word in the examples, so it's unclear initially why
> float-4{ ... } or double-4{ ... } don't exist.
>
> -- Also, on that page, it seems like some backslashes have gotten lost
> in the example code. E.g., in one of the interpolate examples, the line
> should read "\ interpolate optimizer-report.". Other backslashes seem
> to be missing, e.g. in "M\ actor advance optimized." and "M\ actor
> advance test-mr mr."
>
> Thanks,
>
> -- Ed
>
>
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
