00:00:00 --- log: started forth/09.08.28 00:05:15 --- join: f[x] (n=user@95.132.11.129) joined #forth 01:03:10 --- quit: f[x] (Read error: 145 (Connection timed out)) 01:17:42 --- join: GeDaMo (n=gedamo@212.225.115.96) joined #forth 01:33:07 --- quit: nighty^ (Excess Flood) 01:33:37 --- join: nighty^ (n=nighty@x122091.ppp.asahi-net.or.jp) joined #forth 03:01:39 --- join: f[x] (n=user@95.132.184.206) joined #forth 04:31:02 --- quit: GeDaMo ("Leaving.") 05:03:51 --- join: skas (n=skas@ppp59-167-58-9.lns1.cbr1.internode.on.net) joined #forth 05:08:33 --- quit: skas (Client Quit) 05:27:12 --- quit: nighty__ (Remote closed the connection) 05:30:19 --- nick: tgunr_away -> tgunr 06:31:38 --- quit: aguaithefreak (Read error: 110 (Connection timed out)) 07:38:45 --- join: aguaithefreak (i=aguai@114-24-241-161.dynamic.hinet.net) joined #forth 07:42:15 --- quit: impomatic (Read error: 110 (Connection timed out)) 07:58:28 --- join: w7tek (n=w7tek@70.103.91.98) joined #forth 08:00:19 --- quit: w7tek (Client Quit) 08:09:27 --- join: DrunkTomato (n=DEDULO@ext-gw.wellcom.tomsk.ru) joined #forth 08:42:05 --- join: GeDaMo (n=gedamo@212.225.115.96) joined #forth 09:22:01 --- quit: mathrick ("HULK ANGRY! HULK DISCONNECT!") 09:22:24 --- join: mathrick (n=mathrick@users177.kollegienet.dk) joined #forth 09:46:20 --- quit: Quartus` (Read error: 110 (Connection timed out)) 09:53:20 --- join: impomatic (n=John@nat65.mia.three.co.uk) joined #forth 09:53:35 --- join: froth (n=t@adsl-71-137-10-185.dsl.sndg02.pacbell.net) joined #forth 09:55:18 Hi! I have a noob question for you, forth programmers: is the execution of forth programs faster when they are batch compiled than when they are interpreted? 09:56:03 Depends on the implementation 09:57:21 What would be the fastest one? GForth or SPF? 09:57:44 Never heard of SPF 09:57:53 spf.sf.net 09:58:48 --- join: jauaor (n=araujo@190.38.49.150) joined #forth 09:59:04 apparently it's an optimizing compiler that's only ~3 times slower than optimized C, but I'm wondering if I get that only when batch compiling 09:59:15 first i have heard of it 09:59:41 down load both and run some tests :) 09:59:52 let's assume I was talking about Gforth then 10:00:43 Forth benchmarks are hard to come by, and I don't know the language enough to write them. 10:00:59 I might be wrong but I don't think GForth generates native-code 10:06:50 GeDaMo: you are probably wrong. I found this: http://dada.perl.it/shootout/moments.html . I don't think you can get so close to C without generating optimized machine code, but (again) I'm wondering if such speed is available for code generated at runtime as well (think "self-modifiable code") ??? 10:12:49 ... I have to step out for ~20 min, but I'll check back to read the answers (if any - thanks in advance!) 10:13:09 "Gforth uses GCC to compile a fast direct or indirect threaded Forth" 10:27:00 compiled forth code is way faster than interpreted forth code -- interpretation costs time, looking up words in the dictionary is the biggest cost, but the other overhead is non-negligible as well 10:31:42 segher, a sufficiently small forth system could conceivably outperform a poorly compiled forth program, if the former were able to fit into L2 (or even L1) cache too small for the latter. 10:31:52 That's a pretty contrived example, though. 10:32:37 well duh. my interpreter on a 970 will outperform your compiled code on a 8032 10:33:29 and it's pretty bloody hard to grow out of L2, heh 10:36:12 A Forth interpreter doesn't look up words in the dictionary while executing 10:36:27 Well, unless it's using words like ' 10:36:40 no, it has to look up every single bloody word you use 10:36:58 Er ... what? 10:37:18 say you type cr .( Hello, World!) 10:37:24 it first looks up cr 10:37:29 and executes it 10:37:34 then it looks up .( 10:37:36 Yes 10:37:38 and executes it 10:37:44 it parses for ) 10:38:18 That's the outer interpreter, not the inner interpreter on a direct or indirect threaded sytem 10:38:29 yes 10:38:35 it's "the interpreter" 10:38:48 "inner interpreter" is a misnomer 10:39:24 If I define a word : test a b c ; it doesn't do dictionary lookups for a b c when I run test 10:39:33 yes 10:39:34 Only when test is compiled 10:39:41 yes 10:39:51 that's exactly what i was saying, no? 10:40:12 But if it's a direct or indirect threaded system, it hasn't generated native code 10:40:22 so what? 10:40:29 the primitives are native code 10:40:39 So when you run test, it's still "interpreted" 10:40:43 no 10:40:47 it is "threaded" 10:41:09 So what do you call the part that "executes" the threaded code 10:41:10 ? 10:41:26 the primitives do that, usually 10:41:34 it's not a separate part 10:41:47 That part is traditionally called the inner interpreter 10:41:53 if you call that "interpretation", most of a C++ program is "interpreted" as well 10:42:03 only conceptually 10:42:42 if you have a central NEXT , you could call that the "inner interpreter", although it is only part of it 10:42:54 also, it's only 1 to 5 machine insns or so 10:43:45 GeDaMo, a good optimizing native-code generating Forth ought to do some pretty aggressive inlining to produce branch-light, cache-friendly code. 10:43:57 Yes 10:44:15 Also to remove or reduce stack shuffling 10:44:32 and register allocation 10:45:11 after that, it's hard to improve 10:46:13 There's always room for improvement :P 10:46:51 but how much room 10:49:21 Good question. How much improvement in efficiency can you get from your work on the compiler? 10:50:27 inlining, register allocation, and of course peepholing, help a lot, whether generating native code or not 10:52:48 Cache usage has become more important on modern desktop processors 10:54:09 that's the main reason that forth systems that compile to native code, and dtc forths, frequently underperform itc forths 10:54:30 --- join: OoS (n=John@nat65.mia.three.co.uk) joined #forth 10:54:40 You can fit all of the actual machine code into the instruction cache 10:54:46 yes 10:55:39 also, most CPUs suck at predicting code flow for most forth code 10:55:49 so forget about automatic prefetch 10:57:06 and then there is stuff with CPUs that are picky about branch target alignment (mostly intel cpus) 11:07:40 --- quit: impomatic (Read error: 110 (Connection timed out)) 11:11:51 --- nick: OoS -> impomatic 11:41:00 --- join: froth_ (n=t@adsl-71-136-238-28.dsl.sndg02.pacbell.net) joined #forth 11:45:04 --- join: GoNoGo (n=GoNoGo@cro34-3-82-236-93-215.fbx.proxad.net) joined #forth 11:47:20 --- join: ams (n=ams@94.246.125.250) joined #forth 11:57:56 --- quit: froth (Read error: 110 (Connection timed out)) 12:15:04 --- quit: ams (Remote closed the connection) 12:16:43 --- join: ams (n=ams@94.246.125.250) joined #forth 12:24:56 --- quit: jauaor () 12:41:46 --- quit: froth_ (Read error: 104 (Connection reset by peer)) 12:46:50 --- quit: ams (Remote closed the connection) 12:53:27 --- join: Qcoder00 (n=chatzill@212.225.126.223) joined #forth 12:53:32 Hi 12:53:39 Quick question? 12:53:46 Can Forth be described by itself? 12:57:03 You mean can it be implemented in itself? 12:57:52 geDaMo: Well can you describe Forth to ET? 12:57:54 XD 12:58:17 I.E Can you build basic Forth from logic equations? 12:58:38 I haven't the foggiest idea :P 13:37:46 --- join: xjrn (n=jim@c-69-181-126-252.hsd1.ca.comcast.net) joined #forth 13:55:24 --- quit: xjrn (Remote closed the connection) 13:58:30 --- quit: f[x] (Read error: 110 (Connection timed out)) 14:00:36 --- quit: GoNoGo (Remote closed the connection) 14:05:00 --- quit: tgunr () 14:14:13 Qcoder00, answering that question demands that Forth itself have a strict, mathematical definition, and unfortunately this is not strictly the case. 14:15:09 If you mean building a Forth-*like* language directly from logic equations, perhaps in some formal state transition form, then you may want to investigate Joy and its derivatives, and also read Koopman's "Stack Machines: the New Wave" textook. 14:15:16 "textbook", rather. 14:16:54 http://www.ece.cmu.edu/~koopman/stack_computers/index.html 14:21:08 good evening 14:21:13 hi crc 14:25:58 --- join: froth (n=t@adsl-71-136-238-28.dsl.sndg02.pacbell.net) joined #forth 14:26:08 --- part: Qcoder00 left #forth 14:27:39 I think we all agree that Froth can be as fast as compiled languages (as GForth demonstrates), but is this type of speed available at runtime, for runtime generated code? 14:28:39 GForth is one of the slwer Forths out there, the commercial systems are much faster 14:54:07 I had this link earlier: http://dada.perl.it/shootout/moments.html , which shows Gforth to be as fast as anything else on that problem. It would be hard to outperform that. But I'm wondering about the speed of the code that's generated at runtime. How good is it, compared to C, for different implementations? Are there benchmarks, comparisons, etc.? 15:06:18 --- quit: DrunkTomato () 15:10:06 froth, if you look at the log file for gforth at the link you have posted, you can see that this is in fact runtime performance. 15:10:41 In fact, not only does the benchmark measure the runtime of the forth program, it also appears to be measuring the startup and compilation speed of gforth, since it is not loading a pre-compiled image file. 15:10:57 You may be interested to read the further notes on performance in the GForth manual over at http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Performance.html#Performance 15:11:39 --- quit: GeDaMo ("Leaving.") 15:12:27 If you inspect the log file for the gcc, bcc and delphi programs, you can see that tehy are all compiled beforehand, this time is presumably discarded, and then the benchmarks are actually run against the compiled programs. 15:13:43 The gforth version, on the other hand, is compiled and run then from scratch each time. So this [meaningless] micro-benchmark is in fact comparing "runtime interpreted" GForth code against natively compiled applications; and it is lumping GForth's compilation time in with its run time; and GForth is *still* posting impressive performance numbers. 15:15:20 They may be unfairly adding compilation time to Gforth's timings, but that's not the question though. 15:18:16 I don't know if the concept of "EVAL" from LISP translates well into the Forth lexicon. Suppose your program IS RUNNING ALREADY and then you decide that you need a function with a particular source code. (In Lisp, at least) you can compile it into the running program. Can you do that in Forth, and will THAT CODE (!) be as fast as C? 15:21:15 the speed of compiled code will depend on the implementation 15:21:35 you can add new words to a forth system whenever you like 15:24:56 crc: are you talking about "compiled" as opposed to "interpeted"? 15:25:24 forth words are compiled into some form before being run 15:27:02 crc: I'm confused: 10:27 < segher> compiled forth code is way faster than interpreted forth code -- interpretation costs time, looking up words in the dictionary 15:27:11 the form compiled code takes is implementation dependent; it does not have to be actual machine language 15:28:03 you can manually call words using the interpreter, or compile them into new definitions 15:28:41 since in most forths you can pass strings to the evaluator at runtime, the issue of compile time -vs- runtime becomes somewhat moot 15:28:57 crc: when you compile them into new definitions (in a program that's already running), is the compiled machine code / byte code exactly the same as if you were using a batch compiler? 15:29:49 that would depend on the forth, but should be generally true if I understand the question correctly 15:30:30 (I'm unaware of any forth that is specifically designed as a "batch compiler") 15:31:01 crc: as I understand it (I'm a noob), gforth compiles via C, which would pretty much make it a batch compiler 15:33:30 gforth is written in c, but does not compile to c 15:38:19 gforth is an interpreter 15:38:30 crc: are you saying that the code I type into a running GForth should be as fast as the one that it reads from a file? 15:38:42 froth: yes 15:41:08 crc: thanks for clarifying things for me 15:41:54 Does anyone have experience with SPF. Is it faster than GForth? 15:45:11 I honestly don't worry about speed of the forth systems I use; benchmarks are overrated 15:48:06 I don't care about 2-fold performance differences, but some languages/implementations are seriously slow. e.g. Python is 200 times slower than C for many things I've written in both languages. Sometimes speed is important 16:01:21 3.14 f. 16:01:50 am I using floating point incorrectly? 16:04:53 * crc is preparing to build gforth... 16:05:31 I figured that one out: 3.14e0 is the correct syntax. 16:14:29 I do very little work with floating point 16:14:58 forths tend to be unoptimized for floating point 16:59:03 Gforth seems to do well on some of those old benchmarks with floating point 16:59:37 ... of course, it's possible to be fast in one task, and extremely slow at everything else, if the implementors specifically optimized that one thing 17:00:03 well, moving floats to and from an FP stack in memory is never good 17:01:31 Seems to work for Gforth, at least in "moments" and "matrix multiplication", etc. 17:12:41 --- quit: froth ("leaving") 17:34:55 --- join: drhodes (n=none@209-20-72-61.slicehost.net) joined #forth 20:07:11 --- join: MisterN_ (n=MisterN_@p5B2FC4F7.dip.t-dialin.net) joined #forth 20:07:40 is point-free code a usual subject of discussion in this channel? :) 20:09:43 --- nick: MisterN_ -> MisterN 20:26:57 heh, not really 20:27:28 we talk about Forth here, a language known for its various efficiencies 20:27:38 we don't usually talk about pointless style 20:27:43 (har har) 20:29:01 also, while there certainly are analogies between Forth and functional programming, in Forth you usually programming in a purely imperative way, not functional at all 20:29:44 you can try #haskell, there is lots of talk about pointfree there 20:32:29 segher: oh, i was saying in #haskell that in most places, talking about point-free code would be considered bizarre (not in #haskell of course) 20:33:08 segher: somebody then said that forth people might talk about it too 20:33:48 you can only do point-free if you have partial functions 20:34:08 this isn't something usual in Forth 20:34:19 of course you _can_ do it in any language, heh 20:35:10 oh, wait. you could say something like : squared dup * ; is point-free, i suppose 20:36:53 we don't usually consider it that way though 20:37:37 segher: you just write it because it happens to be concise? 20:38:34 _any_ function in Forth takes there arguments just because they happen to be there on the data stack at the right time 20:39:13 parameters are never "bound" to a function 20:39:52 like in postscript, eh? :> 20:39:54 so in a sense all Forth programs that don't reference global state are point-free 20:40:16 sure, like postscript 20:55:22 --- quit: MisterN ("Verlassend") 21:01:51 mistern postscript is loosly based on forth 21:02:30 oh he left :P 21:46:04 --- join: froth (n=t@adsl-71-136-238-28.dsl.sndg02.pacbell.net) joined #forth 22:03:23 What's the bestest Froth implementation for AMD64 (fast, etc.) ? 22:04:25 iforth? 22:33:03 --- quit: froth ("leaving") 22:57:51 --- join: jauaor (n=araujo@190.38.49.150) joined #forth 22:58:51 hello 23:13:01 --- join: f[x] (n=user@134-48-133-95.pool.ukrtel.net) joined #forth 23:24:54 --- quit: segher (Read error: 110 (Connection timed out)) 23:59:59 --- log: ended forth/09.08.28