00:32:24 -!- Corun has quit (Remote closed the connection). 00:32:39 -!- Corun has joined. 00:41:26 -!- optbot has set topic: the entire backlog of #esoteric: http://tunes.org/~nef/logs/esoteric | oh ok. 00:43:45 -!- Corun has left (?). 01:36:17 -!- Slereah_ has joined. 01:36:21 GUBMENT 01:36:22 JEWS 01:36:27 RON PAUL 02:26:11 -!- Sgeo has joined. 02:45:06 -!- GreaseMonkey has joined. 02:46:34 -!- Slereah has joined. 02:52:57 Slereah_: DAH GUBMENT JEWED MY RON PAUL? 02:54:01 You know how the gub is 03:00:37 RON PAUL AND DENNIS KUCINICH IN 2012 03:01:35 RON PAUL AND FIDEL CASTRO'S REANIMATED CORPSE IN 2012 03:01:53 RON PAUL AND RON PAUL IN 2012 03:02:02 Can you nominate yourself as vice president? 03:02:29 ron paul will be senile by 2012 03:02:42 Ron Paul is functionally no better than senile already. 03:10:02 -!- Slereah_ has quit (Read error: 110 (Connection timed out)). 03:36:21 -!- warrie has joined. 03:36:46 Without objection, I intend to ratify the following report: "#esoteric is about politics." 03:37:43 I object. 03:38:31 -!- Sgeo_ has joined. 03:38:39 You can't object, you're not a player. 03:38:59 Register, then you'll be able to object. 03:39:44 I object to your suggestion that I must register to object. 03:40:45 It's not a suggestion, it's a rule. 03:41:25 I'm not playing your game, and as such I am not following your rules. Since I am not following your rules, I may object to anything you say for any reason. Since I'm not playing by your rules, my objections have no bearing on anything. 03:41:39 Oh. Darn. 03:43:31 I object to your motion to darn. 03:43:45 -!- cmeme has quit (Read error: 60 (Operation timed out)). 03:44:55 I object to your interpretation of my interjection. 03:47:58 I object to your objection of the interpretation of your interjection leading to my objection of your response to my assertion defying your declaration arguing against my objection of your complaint at my objection. 03:49:08 I object to everything. 03:49:13 -!- Sgeo has quit (Read error: 110 (Connection timed out)). 03:49:32 I OBJECT TO NOTHING!!! 03:50:30 Well, that was fun :P 03:51:35 Very. 03:51:56 Let us now take pictures of skulls among junk. 03:52:31 "Only one store has been a part of your life for 150 years." 03:52:38 That line in this commercial is so stupid :P 03:52:44 It is literally not true of /anyone/. 03:53:48 * warrie sends the picture, which, presumably, puts it somewhere 03:55:15 I wish this phone had a "what the heck does that flashing icon mean" button. 03:59:00 Well, that didn't work. 03:59:06 * warrie tries to plug his phone into his computer 04:00:14 * warrie's computer explodes 04:01:23 What's that in Spanish? "calavera"? 04:03:46 I'll take your silence as meaning "Yes, Master." 04:09:16 -!- calamari has joined. 04:09:26 hi 04:09:43 saw this on slashdot: http://slashdot.org/comments.pl?sid=1019609&cid=25649459 04:10:33 Ello. 04:12:48 Almost certainly not turing complete, no unbounded loops or recursion. 04:16:11 -!- Leonidas_ has joined. 04:16:25 no recursion? hmm .. you may be right 04:21:42 Also, 'find' isn't really useful in it unless you can create files and directories, for which you need mkdir and (something akin to) touch. 04:24:00 so if we changed things.. sh and ; can help with recursion 04:27:29 -!- Leonidas has quit (Read error: 110 (Connection timed out)). 04:27:40 GregorR: so does Facebook still make you sick? 04:28:18 calamari: It has one (1) useful feature. 04:28:33 wasting time? 04:29:07 I was referring to the event planning :P 04:35:10 -!- Sgeo_ has quit (Remote closed the connection). 04:41:40 -!- sebbu2 has joined. 04:42:46 -!- Slereah has quit (kornbluth.freenode.net irc.freenode.net). 04:42:46 -!- sebbu has quit (kornbluth.freenode.net irc.freenode.net). 04:42:47 -!- sebbu2 has changed nick to sebbu. 04:48:22 -!- Slereah_ has joined. 04:55:20 -!- calamari has quit ("Leaving"). 04:57:32 -!- warrie has quit (Read error: 104 (Connection reset by peer)). 05:42:06 what did he mean? that it's tc to pipe them? because that's basically max(map(computational_power,["find","xargs","grep"])) 06:13:46 -!- ab5tract has joined. 06:17:20 -!- Judofyr has joined. 06:32:29 -!- ab5tract has quit. 06:35:35 -!- Judofyr has quit. 06:41:26 -!- optbot has set topic: the entire backlog of #esoteric: http://tunes.org/~nef/logs/esoteric | cheap!. 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:09:14 -!- oerjan has joined. 08:18:13 morning 08:18:30 good moaning 08:22:04 Re the stack things, of course it's trivial to do the guard pages portably, with mprotect; didn't realize (I blame tiredness) it can set individual pages out of a larger mapping. 08:26:58 fizzie, heh 08:31:12 Currently I'm wondering why the underflow handling seems to work even though I've only implemented one half (resetting ESI correctly), not the other (setting to zero the target register). It might be just luck, those target registers might be zero at that time anyway. Also, 1+\..a,@ prints out "1 0 " instead of "0 1 ", but that seems to be a bug in the generated code already. 08:35:15 -!- GreaseMonkey has quit ("Unisex."). 09:13:26 fizzie, how would that part work on other platforms? 09:13:35 I mean sure I can see how you could port the code generation 09:13:46 but I'm not so sure about the segfault handling 09:13:54 it seems extremely fragile 09:15:22 I'm sure something similar is implementable on most archs; if not, then the code generation can generate plain old explicit checks for underflow. 09:15:30 ah 09:15:50 fizzie, by the way I tested open64, it can compile cfunge 09:15:53 I just think most architectures have something to handle dynamic stack-enlargening in Real Programs (tm). 09:17:11 I just spent more than a minute wondering why "00g.a," printed out 48 instead of 32, before I realized that the space isn't empty at start, there's that program inside it. "Heh." 09:18:03 hah 09:18:22 fizzie, does it handle wrapping? 09:18:44 Sure, in the tracing code. Don't think I have tested it at all, though. 09:18:56 hm mycology will test it 09:19:13 fizzie, what about a _ at the edge then? 09:19:37 I don't see anything special about _ at the edge. 09:19:41 hm ok 09:19:45 The next trace will start at the edge and wrap. 09:19:49 (Hopefully.) 09:20:02 fizzie, right, how far does it get in mycology now? 09:20:21 fizzie, oh and I suppose \ is turned into a single XCHG or something like that? 09:21:04 Actually in most cases \ just changes the registers used by later instructions; I don't keep things on stack unless I have to. 09:21:26 But a plain old \ by itself currently does pop+pop+push+push; I'll think about optimizations later on, maybe. 09:22:38 fizzie, it could be turned into a single XCHG I believe 09:22:41 (Basically a trace containing only a \ will automagically generate stack loads into virtual registers r0, r1; then the \ instruction just changes the order of those in a list; and hitting the end of trace will generate those two push instructions because it needs to flush things back on stack. 09:23:24 Sure, although I'm not completely sure how my stack underflow thing will survive it. 09:24:50 fizzie, heh 09:24:55 Still, I can special-case a bit depending on the opcode that caused the underflow. 09:25:13 What I really don't see is why this underflow thing stubbornly keeps working even though I haven't really implemented it completely. 09:25:48 fizzie, heh 09:26:44 I have 9 in ecx; then I do a "mov ecx, [esi]" which causes a segfault; when I restore the context, ecx automagically seems to be zero, even though I don't mangle the saved context at all. 09:27:20 I'm not sure how well-defined things like that are. Should probably read some processor manuals to find out. 09:28:11 hah 09:28:27 fizzie, could depend on OS too? 09:28:55 Also if I do a "lodsd" instruction (which does ax <- [esi] and auto-post-decrements esi), and the read from [esi] causes a fault, I'd like to know whether esi is still decremented. 09:28:55 fizzie, since a segfault would go through the kernel 09:28:59 pretty sure it would 09:29:21 Sure, it's the kernel who packages the context up and sends a signal. 09:29:32 fizzie, what about out of order execution? 09:29:40 that could probably mess up this a lot 09:29:47 since modern CPUs reorder instructions 09:31:07 fizzie, or? 09:31:08 Well, I don't think they're allowed to do that too much so that observable semantics change. 09:31:49 Admittedly the exact happenings on a page fault are a bit of a border case. 09:31:56 fizzie, well "not for normal use", but I think a fault isn't that 09:32:04 indeed 09:32:48 fizzie, if it didn't matter instructions such as MFENCE wouldn't exist 09:36:48 I'm hoping a page fault will do the sensible things re flushing/serializing stuff. Will worry about the details later. 09:49:08 -!- jix has joined. 10:00:27 What I'm not quite sure is to have to deal with a self-modifying 'p' while retaining the "constant-location-g/p access is as fast as variables" behaviour. On code-generation time, I can't be sure if that particular location will later become part of something executable. I guess I could keep a list of all constant-p references to any cells, and when tracing, invalidate those pieces of compiled code that need changes. 10:00:36 s/have/how/ 10:25:47 -!- jix has quit ("CommandQ"). 10:32:29 Curious, after "GOOD: 8*0 = 0" I now get an infinite number of newlines from mycology. 10:32:45 Yesterday it correctly printed out "GOOD: # < jumps into <". 10:33:09 fizzie, well the way you do that stuff it won't be easy to debug 10:35:51 Indeed. Well, I could dump out the generated code every time it traces things, to see if that helps any. It will probably generate quite a lot of output, though. 10:37:27 fizzie, you could insert trace calls or something? 10:37:48 I mean, on the fly 10:38:07 I guess I could, reasonably easily even. 10:38:15 may not help a lot though 10:39:25 fizzie, for scripted interpreters I found that doing something such as having a known good implementation dump traceoutput 10:39:35 then your new one dump trace in the same format 10:39:38 diff the output 10:39:39 compare 10:39:45 err s/scripted// 10:39:53 but for JIT that may not help a lot 10:40:15 fizzie, anyway the point is diffing trace output and see where it begins to differ 10:41:09 fizzie, for example cfunge at -t 4 should work for that 10:41:14 tix=0 tid=0 x=0 y=0: 9 (57) 10:41:14 tix=0 tid=0 x=1 y=0: 1 (49) 10:41:14 tix=0 tid=0 x=2 y=0: + (43) 10:41:14 tix=0 tid=0 x=3 y=0: " (34) 10:41:26 (tid and tix are got threads so ignore that) 10:41:50 The constant-folding part will make that a bit difficult; of course I could dump some trace output already before code-generation, but at that point I don't have the stack available. But I would get the "where did the IP go" trace, at least. 10:42:06 ah 10:42:15 fizzie, for stack in cfunge you would want -t 9 10:42:30 shows top 5 elements iirc 10:42:44 tix=0 tid=0 x=0 y=0: 9 (57) 10:42:45 Stack is empty. 10:42:45 tix=0 tid=0 x=1 y=0: 1 (49) 10:42:45 Stack has 1 elements, top 5 (or less) elements: 10:42:45 9 10:42:45 tix=0 tid=0 x=2 y=0: + (43) 10:42:47 Stack has 2 elements, top 5 (or less) elements: 10:42:49 1 9 10:43:27 fizzie, anyway diffing trace output to "known" good have helped me a lot when working on efunge 10:44:56 It seems to end up in a >:#,_ print loop, printing infinite newlines. I'm guessing it might even be finally the stack undeflow thing not returning zero; but I'd like a bit smaller test case than mycology for that. 10:45:21 right 10:45:34 well that helps you somewhat at least :) 10:46:55 Hey, yay. A single a"yay">:#,_@ loop will also print infinite newlines; after popping that a, it seems to pop and pop and pop and pop. 10:47:15 heh 10:49:12 once you pop, you can't stop 10:49:16 haha 10:50:47 Hmph, I don't know gdb enough to make a breakpoint inside an overloaded C++ operator. Maybe the line number will work. 10:50:58 fizzie, file.cc:554 10:51:01 for example 10:51:03 should work 10:51:44 Yes, seems to. 10:52:40 only issue if you have two files with the same name, then gdb always manage to interpret it as the other file, not the one you wanted 10:53:08 (this can happen if you built some library with debugging info for example) 10:53:39 Heh. 10:53:44 (gdb) disassemble 0xf7ee8023 10:53:44 No function contains specified address. 10:53:55 Right, I just want them bytes. 10:54:16 hm? 10:54:27 I guess the two-argument form will disassemble for me without finding a function. 10:54:28 fizzie, change language mode to asm or such 10:54:31 I think that may work 10:54:36 or that 10:55:24 fizzie, btw how do you jump into the generated code? 10:55:35 Cast to a function pointer and call it. 10:55:43 ah, right 10:56:07 hm that is a sure way to confuse any debugger I can think of... 11:01:21 fizzie, do you think it will build as a Position Independent Executable (PIE)? 11:01:30 hm it does 11:01:47 which I didn't expect 11:01:58 Sure, since the compiler doesn't know about the code-generation part, and the addresses and such are known at the time when it actually does the code-generation. 11:02:03 ah 11:02:36 fizzie, thought the pie offset thingy register would have messed up for you 11:05:07 Oh, founded the bug. There's a "peek" instruction (I combine a pop+push into a peek) which reads from below the stack; the segfault handler accidentally increments the stack pointer there too, even though it wasn't actually decremented. 11:05:26 fizzie, hm possible to fix? 11:05:55 heh while valgrind may work, it seems mudflap doesn't 11:06:00 over 1000 warnings 11:06:56 ah MUDFLAP_OPTIONS="-heur-proc-map" makes it work 11:12:12 -!- oerjan has quit ("leaving"). 11:24:26 Phew, fixed that bug. Now it looks at the opcode which caused the stack fault and sets the target register to zero; and also at the next opcode to avoid decrementing the stack pointer after resetting it. 11:26:37 -!- Corun has joined. 11:35:25 -!- Leonidas_ has changed nick to Leonidas. 12:41:26 -!- optbot has set topic: the entire backlog of #esoteric: http://tunes.org/~nef/logs/esoteric | Reloaded.. 12:44:35 -!- Jiminy_Cricket has quit (Read error: 110 (Connection timed out)). 12:57:40 There is the self-modifying 'p', although I guess it's a bit buggy still. Mycology doesn't complain about "p doesn't modify space" now, but "BAD: 900pg doesn't get 9" even though running "900pg.a,@" does print out 9. 13:05:10 fizzie, nice, updated the snapshot? 13:08:18 Did now, but don't expect much to work yet either. 13:09:33 src/interp.cc: In constructor 'jitfunge::Stack::Stack()': 13:09:34 src/interp.cc:159: warning: missing initializer for member 'sigaction::__sigaction_handler' 13:09:34 src/interp.cc:159: warning: missing initializer for member 'sigaction::sa_mask' 13:09:34 src/interp.cc:159: warning: missing initializer for member 'sigaction::sa_flags' 13:09:34 src/interp.cc:159: warning: missing initializer for member 'sigaction::sa_restorer' 13:10:27 http://rafb.net/p/LDH6i265.html is all the warnings 13:10:36 fizzie, hm nice 13:11:40 fizzie, nice I don't know how you manage to mess up mycorand so much... 13:11:46 ? was met 1 times 13:11:48 heh 13:12:07 I don't think I implement ? at all. Not sure. 13:12:14 fizzie, it thinks it was ^ 13:12:32 but afaik mycorand should loop until it had at least one of each direction 13:12:33 Hi fizzie . 13:12:35 -!- Corun has quit ("This computer has gone to sleep"). 13:12:38 hi ehird 13:13:05 900pg 9-!| leaves down instead of up. That's a nice bug too. Debugging this isn't very pleasant. 13:13:11 ehird: Hello. 13:18:05 fizzie, where is the debug output generated? 13:25:11 Ooh: "GOOD: 900pg gets 9", "GOOD: p modifies space". Then it hangs up. 13:25:22 hangs up? 13:25:31 Well, an infinite loop is my guess. 13:25:41 trace? :) 13:30:45 At (5,17), heading left. Maybe a wrapping issue or something. It seems to bounce off the edge for some strange reason: it sees two $s and an _, instead of wrapping. 13:31:12 The debug output isn't written anywhere just yet, it's just one line I've been commenting/uncommenting. I'll add a command-line flag for it in the next revision. 13:31:26 I think I'll try to get the wrapping right first, though. 13:33:35 fizzie: Can I test it on OS X again? 13:33:35 :P 13:34:11 ehird, did it work last time? 13:35:45 -!- Corun has joined. 13:35:47 I haven't removed the mremap or changed the hashmappery, so I doubt it'll work any better. 13:38:12 Oh, it wraps just fine, it's just the \r\n newlines of mycology leaving a \r there, which it reflects from. 13:38:20 fizzie, hashmappery? 13:38:38 fizzie, then you need to fix your loading ;) 13:40:35 There was some C++ template error from my use of on OS X. 13:41:00 Loading is fixed, but mycology crashes at the same point: "unrecognized opcode in stack underflow". 13:41:04 That's a curious one. 13:44:26 fizzie, hm what gcc version did you say you used? 13:44:44 4.3.2, I think. 13:44:51 Hmm, it's a stack underflow when pushing. That's creative. 13:45:10 fizzie, underflow when pushing, how did you manage that? 13:46:40 fizzie: let me know when it's ready to implement fingerprints 13:46:41 :-P 13:51:54 Oh, right. A $ does not read from the stack (because it's a useless memory read), it just decrements the stack pointer reg; so the next push will cause the stack underflow check to fire. Well, that's... somewhat easy to fix. I think. 13:56:15 fizzie, depending on the program this faulting instead of checking bounds could be a lot slower 13:56:17 or faster 13:56:46 I think most programs do not do stack underflow much. At least my programs, anyway. 13:56:50 -!- Corun has quit ("This computer has gone to sleep"). 13:57:18 Yay: Befunge-98 detected. GOOD: wraparound works, GOOD: a pushes 10, GOOD: b-f push 11-15, GOOD: [ turns left, GOOD: ] turns right, GOOD: instructions between ; are skipped, UNDEF: # across left edge hits easternmost cell in file, UNDEF: # across left edge hits easternmost cell on line, BAD: k reflects 13:57:32 Well, it's again few steps further. 13:57:53 Haven't done 'k' yet; it will probably not be very pleasant, at least to get all the corner cases right. 14:00:23 -!- Slereah_ has quit (Read error: 113 (No route to host)). 14:03:08 -!- Corun has joined. 14:07:06 -!- Corun has quit (Client Quit). 14:10:56 fizzie, cfunge have a bunch of test programs for k 14:11:05 for the stuff mycology doesn't test 14:11:27 fizzie, uploaded a new snapshot? 14:12:11 Now, yes. 14:12:34 You can run it as "jitfunge file.b98 -d" to make it dump the traces it generates. 14:12:38 (To stderr.) 14:12:59 I'll add getopt'd command line arguments when I have something that actually works. 14:13:50 oh god jitfunge 14:15:39 fizzie, hm it seems slower than profile feedback compiled cfunge at life.bf 14:15:59 oh wait I can't compare 32-bit to 64-bit 14:17:01 What, do you mean it actually runs life.bf? 14:17:10 fizzie, yes it does 14:17:26 That's really strange. 14:17:31 output seems correct as far as I can tell 14:17:38 fizzie, why? 14:17:51 it is b93 14:17:56 and you pass that section you said 14:18:11 since you get to k 14:18:30 though it is fast on life.bf 14:18:49 Yes, but even the ()-parsing part of underload.b98 (which doesn't involve any fingerprints) has some infinite-loopy bug. 14:19:13 there is no ( or ) in life.bf 14:19:32 fizzie, it fails at prime.bf however 14:19:33 with: 14:19:35 error: FIXME register spill 14:19:41 I mean the underload (). 14:19:56 Heh. 14:20:17 pi2.bf -> floating point exception 14:20:26 divide by zero? 14:20:32 do you handle that correctly 14:20:44 No, I don't. 14:20:49 fib.bf cause 14:20:50 unexpected SIGSEGV; dying... 14:20:50 Aborted 14:21:07 fizzie, but yes it somehow manages life.bf 14:21:08 -!- jix has joined. 14:21:53 I see. Heh. 14:22:01 wumpus.bf cause infinite loop I think 14:22:13 it just locks up 14:23:31 fizzie, oh nice you don't do error checking on input, I typoed and ran it on a directory 14:23:37 it seemed to actually try to execute that 14:24:14 fizzie, oh and if I run it under valgrind it fails at life.bf 14:24:23 I think it just executes some empty space in that case. 14:24:31 (The directory-as-input one, that is.) 14:24:39 just dots for output and lots of valgrind errors 14:24:47 so valgrind affect the behaviour too there 14:25:18 in fact it breaks under valgrind all the time 14:25:23 like stack underflow 14:25:26 That's not terribly surprising. 14:25:47 fizzie, hm valgrind is useful for debugging, but I guess you will solve that in some other way 14:26:09 -!- Corun has joined. 14:27:44 fizzie, um mycouser.b98 says it handles division by zero 14:27:58 or is that just the constant folder? 14:28:46 Yes, that part does it correctly. 14:29:15 fizzie, inputting a newline to the char test in mycouser acts oddly 14:29:19 as in just pressing enter 14:29:29 first it says 10, right, but then it waits for another newline 14:29:35 wait *checks with cfunge* 14:29:50 ah no 14:29:55 it is mycology's "fault" 14:36:03 (build/jitfunge life.bf > life.txt &); sleep 20 ; killall jitfunge ; ls -l life.txt generates around 8.5 megabytes of output, compared to ~2.7 megs from cfunge (32bit, -O3, no fancy flags), here. I'm not sure jitfunge is in a benchmarkable state yet, though. 14:37:08 fizzie: are you making something like a befunge compiler? 14:37:28 oklopol: It's an interpreter which does just-in-time compilation to native x86 code. 14:37:50 oh to x86? you use like gcc or smth? 14:38:01 No, I just write some bytes. 14:38:07 cool 14:38:38 The generated code is quite non-optimal, though. 14:39:11 fizzie, here I get around 5.2 MB from each 14:39:21 64-bit cfunge 14:39:26 with 32-bit fungespace 14:39:37 profile feedback compiling 14:39:59 gcc 4.1.2 14:40:15 Right, the cfunge build I did is probably 64-bit too, I just turned USE_64BIT off. 14:41:44 fizzie, hm ok 14:42:15 fizzie, well for me both generates around 5 MB, sometimes slightly more for cfunge, sometimes more for jitfunge 14:42:17 very even 14:42:28 but that is profile feedback so... 14:44:12 fizzie, with just plain -O3 for both I get results close to your 14:44:49 5 mb from jitfunge, around 1.8 from cfunge 14:45:10 fizzie, however I don't know how large setup time jitfunge needs. cfunge have quite a bit of setup time 14:45:18 GCC is pretty good at the optimization game, compared to my code generation. 14:45:29 oh yes it is 14:45:38 hmm optimization game => the game => i just lost it :( 14:45:40 hm icc wouldn't help this is amd... 14:45:57 jix: agh, ditto 14:46:10 fizzie, oh and my build ifdefs out tracing there ;) 14:46:32 yesterday my gf made me lose the game 5 times... :( 14:46:39 fizzie, and also disables threads, another speedup 14:50:36 There's quite a lot of small code snippets generated for life.bf, increasing the overhead there. Every time there's a branch or a merging of two code paths, jitfunge splits the code to separate functions there. 14:51:31 you try to jit compile befunge? 14:51:44 fizzie, you may want to do superblock optimising 14:51:51 jix, he isn't trying, he is doing it 14:51:54 I'm not sure "try" is the right verb here, since it already does life.bf. 14:51:55 seriously 14:52:09 -try then :) 14:52:26 "you to jit compile befunge"? 14:52:33 maybe -to as well 14:52:37 yeah -_- 14:54:40 It would be better to generate longer pieces of code, and jumps into them, but that's trickier. 14:55:20 fizzie, heh 14:55:33 fizzie, better get it working properly before you start optimising like that? 14:58:08 Probably, yes. 14:59:59 Although I would probably get significantly longer snippets of code simply by always assuming either the true or false branch from an if, and continuing the trace that way. 15:00:19 Given that it's JIT, I should probably be collecting some statistics and doing branch prediction that way. 15:02:44 fizzie, or compile it to code with a jump in? 15:03:15 hey jix 15:03:17 THE GAME 15:03:45 -!- Corun has quit ("This computer has gone to sleep"). 15:03:58 fizzie, I mean, compile both paths with a compiled jne instruction or such at the | 15:04:05 or je 15:06:11 Then I would really have to think harder when recompiling parts of code, since it would not be a distinct function I could just discard. 15:06:31 But sure, a single generated mess of code with jumps around would have less overhead. 15:06:57 fizzie, you may have to discard several ones already 15:07:12 fizzie: how fast is it? :p 15:07:26 fizzie, for example suppose one cell is hit with two different deltas. then a p changes the value there 15:07:38 then you have to discard multiple ones 15:08:31 ehird: nargh 15:11:36 Yeah, sure, but I can discard them easily and let the interpreter recompile when it notices it doesn't have code for that part. 15:11:55 fizzie, hm ok true 15:12:08 Ohh, fizzie HASN'T been monologuing this whole time 15:12:23 That makes things less confusing 15:14:04 fizzie, if you discard some jitted code, and the jitted code is placed in a mmaped region, how do you allocate new ones, try to find the first hole large enough? 15:14:06 or? 15:15:16 Away for a while. 15:15:20 cya 15:52:27 -!- Corun has joined. 15:52:35 -!- Corun has quit (Client Quit). 16:04:17 [[ 16:04:17 Mind Control 16:04:18 Doctors from the Association of American Physicians and Surgeons have stated that Obama uses techniques of mind control in his speeches and campaign symbols. For example, one speech declared, "a light will shine down from somewhere, it will light upon you, you will experience an epiphany, and you will say to yourself, 'I have to vote for Barack.'"[19] The doctors observe that "Obama's logo is noteworthy. It is always there, a small one in the middle of the pod 16:04:19 ]] 16:04:21 -- Conservapedia 16:04:36 [[If elected, Obama would likely become the first Muslim President, and could use the Koran to be sworn into office.]] - also conservapedia 16:15:16 makes liberal conspiracy theories seem almost tame 16:18:00 -!- Corun has joined. 16:20:02 also from that site, "World Bank Group.s computer network has been compromised by cybercriminals" 16:20:40 their book section is full of real winners too 16:21:00 "HMOs are not "free market" alternatives, but rather an unholy partnership of government and corporate interests seeking monopolistic government protection to eliminate competition while changing the ethics of medicine from a Hippocratic ethic to a false corporate morality" 16:21:12 dun dun DUUUUUUUUUNNNNNNNNNNN 16:22:53 -!- jix has quit ("CommandQ"). 16:22:59 there was this awesome group last month running around in circles convincing themselves both candidates were Manchurian Candidates 16:23:03 awesome to watch, at least 16:25:47 -!- Corun has quit ("This computer has gone to sleep"). 16:33:59 -!- Jiminy_Cricket has joined. 16:46:01 i missed bfbasic 16:46:08 that's nift 16:46:22 -!- Corun has joined. 16:47:35 -!- ab5tract has joined. 16:56:13 hm? 16:58:25 -!- Hiato has joined. 17:05:03 -!- oklokok has joined. 17:06:35 -!- Hiato has quit ("Leaving."). 17:08:01 -!- Hiato has joined. 17:08:14 -!- comexk has joined. 17:09:25 -!- comex has quit (Read error: 104 (Connection reset by peer)). 17:09:29 -!- oklokok has quit (Client Quit). 17:11:31 -!- oklopol has quit (Read error: 145 (Connection timed out)). 17:24:54 -!- Sgeo has joined. 17:40:49 -!- Corun has quit ("This computer has gone to sleep"). 17:41:00 -!- oklopol has joined. 17:41:53 -!- Hiato has quit ("Leaving."). 17:44:23 -!- Corun has joined. 18:17:41 -!- oerjan has joined. 18:21:11 wee l4d demo is fun 18:27:58 -!- Corun has quit ("This computer has gone to sleep"). 18:33:56 -!- olsner has joined. 18:34:22 -!- Mony has joined. 18:37:55 plop 18:37:59 hi Mony 18:38:11 hi ais523 18:41:26 -!- optbot has set topic: the entire backlog of #esoteric: http://tunes.org/~nef/logs/esoteric | ^bf ++++++[->++++++<]>>+[<.>[[[[[][][][][][][][][][][][][][][][][][][][][][][][]]]]]]. 18:42:03 optbot! 18:42:04 -!- optbot has set topic: the entire backlog of #esoteric: http://tunes.org/~nef/logs/esoteric | cool page: http://www.angio.net/pi/piquery. 19:01:26 Meh, sensiblized the code generated by jitfunge, and managed to cut life.bf performance into 4 % (variant 1) or 30 % (variant 2) of what it used to be; the new system does generate longer pieces of code, but it ends up recompiling something all the time. I need a figure out a less complicated test case for the issue, though. 19:01:53 fizzie: can you beat cfunge yet? 19:02:43 ais523: Well, the previous version was faster at life.bf with my setup; apparently with the right magical GCC flags (profile-guided optimization?) the life.bf speeds were just about even. 19:03:06 ah, interesting 19:04:07 At least this current code-generation can turn >:#,_ into a function that actually does loop, instead of having a single function that is called (by the interpreter part) repeatedly for each character. 19:06:36 -!- Corun has joined. 19:09:36 -!- kar8nga has joined. 19:17:52 -!- KingOfKarlsruhe has joined. 19:34:34 -!- kar8nga has quit ("Leaving."). 19:41:05 ais523, those magical flags included -fwhole-program -combine and -fprofile-use 19:41:09 which explains a lot 19:41:24 and it was x86_64 vs. x86 19:41:31 which isn't fair really 19:46:17 whoo I shaved another 0.10 seconds of mycology run time in cfunge. I think I may do even better 19:46:29 * AnMaster tries to rewrite the loop to make it easier to vectorise 19:47:30 I probably will be slow as heck in mycology, since I guess there's not much repeatedly executed stuff there. 19:50:14 well mycology is where I'm really really really fast 19:50:36 oh and very fast for an interpreter elsewhere 19:53:46 * AnMaster waits while -ftree-vectorizer-verbose=10 spews output 19:53:52 -!- KingOfKarlsruhe has quit (Remote closed the connection). 19:54:20 -!- Corun has quit ("This computer has gone to sleep"). 19:55:33 AnMaster: is that a gcc or icc option? 19:55:46 -!- KingOfKarlsruhe has joined. 19:55:58 ais523, gcc 19:56:24 it is interesting to see that gcc detects some possible vectorisations that icc doesn't as well as vice verse. 19:56:30 spelling... 19:56:51 "versa" 19:57:29 yep 19:57:58 oerjan, at least in Swedish, but aspell doesn't like it in English 19:58:00 hm 19:58:13 ais523, oh and it needs -ftree-vectorize to do anything 19:58:22 it's latin 19:59:31 oerjan, hm it is spelled vise versa in Swedish 19:59:36 not vice versa 20:04:51 ais523, oh and GCC generates faster programs on AMD64 20:04:59 icc is faster on intel though 20:05:03 no surprise there 20:05:08 yep, not really surprising at all 20:05:47 but icc is still useful on AMD, because it points out different issues and so on 20:07:32 real 0m0.051s 20:07:32 user 0m0.037s 20:07:32 sys 0m0.011s 20:07:33 whoo 20:07:57 -march=k8 -msse3 -O3 -funroll-loops -DNDEBUG -fweb -ftracer -frename-registers -ftree-vectorize 20:08:06 no I don't claim it is sane 20:08:17 AnMaster: where are you directing the output, BTW? 20:08:23 /dev/null 20:08:27 ok 20:08:42 have you optimised cfunge to detect output going to devnull and not output it? 20:08:47 with output to konsole it is 0m0.087s 20:09:29 ais523, hm I have, as far as I know, not added any stuff that would make one or the other slower as an effect of making the other one faster 20:09:35 I try to check using both anyway 20:09:46 but I run the timings I report to /dev/null 20:09:58 they vary less 20:10:06 so easier to compare with 20:10:40 I mean with stdout the spread is about +/- 0.020 seconds but with /dev/null it is about +/- 0.010 20:13:13 real 0m0.043s 20:13:15 nice 20:13:20 that is a profile feedback build 20:15:08 and if I run with env -i PATH=/bin:/usr/bin TERM=$TERM it is reduced to around 0.025 seconds 20:20:13 I don't get this; I changed completely unrelated things, but now it doesn't have the life.bf "causes recompilations all the time" issue, and does 10.6 megabytes of life.bf output in 20 seconds. 20:20:25 fizzie, these latest changes should help a lot for fungot, string handling was sped up a lot by reorganising pushing to allow gcc to vectorise the push loop 20:20:25 AnMaster: i believe that is a very original thought....are you a poet? so.....you like atlanta? what color are your eyes? 20:20:35 they aren't committed yet 20:21:12 and they need you to use the relevant -march to take advantage of it, and -O3 and -ftree-vectorize 20:21:20 SSE2 at least I believe 20:22:12 anyway it helped a lot for y in the HRTI test 20:22:53 $ env | wc -c 20:22:54 5815 20:23:00 UNDEF: T after M pushed 3 and a second T, after 675 ys, pushed 10899 20:23:49 oh and I seriously want memrcpy() which would be like memcpy() but would reverse (byte by byte) the entire thing 20:24:04 if I had such a thing and it was fast this could get even faster 20:24:17 alternative would be to resign funge stacks to grow downwards 20:24:19 I guess 20:24:25 redesign* 20:24:32 but that would be a pain to grow 20:25:05 -!- Corun has joined. 20:25:20 at least without being unportable 20:25:34 The jitfunge stack grows up, but that's pretty arbitrary. 20:25:57 don't resign. stacks should grow up dammit! 20:25:59 fizzie, yes but I would need to copy stuff around instead of just reallocing if I were to do that 20:26:16 fizzie: use Fungus as your processor and make the stack grow sidewats 20:26:19 *sideways 20:26:22 const size_t top = stack->top + len; 20:26:22 for (ssize_t i = len; i >= 0; i--) 20:26:22 stack->entries[top - i] = str[i]; 20:26:22 stack->top += len + 1; 20:26:37 that is how my push 0"gnirts" look like now 20:27:00 well it preallocates to make sure there is enough room before that of course 20:27:48 ais523, that fungus emulator is superslow 20:28:00 AnMaster: obviously, you'd have to build the hardware and run on there 20:28:23 ais523, and how fast would it be compared to a high end AMD or Intel CPU? 20:28:38 it would depend on how fast the chip you'd built was 20:28:56 the type of typical chip that students use has a clock cycle of a few tens of nanoseconds 20:29:02 so about 500 MHz or so 20:29:13 less, 100 MHz or so 20:29:22 so probably not competing with high-end CPUs 20:29:46 ais523, even though it could potentially run funge more natively? 20:29:50 err spelling 20:30:05 yes, I think so 20:30:48 fizzie, how far out in negative funge space does the ul stack go on ^ul (::^):^ 20:30:48 ? 20:31:21 -!- comexk has quit ("Caught sigterm, terminating..."). 20:31:32 -!- comex has joined. 20:31:32 Depends on the stack limit. 20:31:47 i recall some discussion on implementing special chips for functional languages or something - the mainstream chips are just too fast to compete with even for such a special design 20:32:00 oerjan, lisp machines 20:32:03 (i think it was on Lambda the Ultimate) 20:32:14 AnMaster: that was _decades_ ago 20:32:22 oerjan, but same concept 20:32:36 In fungot currently, cd*:* so it goes to X=-24336 before complaining. 20:32:37 fizzie: i would need to involve nec page, so that's ok. well... x-chat doesn't. instead of " new code" do you mean? what kind of module system is quite nasty too: 20:32:47 the point was, the mainstream chips improve so fast that they will be better than yours before you get it out to market 20:32:58 or something like that 20:33:20 oerjan, indeed 20:34:21 ok I can't do static space for that 20:34:27 would require 32 mb ram 20:34:33 for the static array 20:34:44 to keep power of two nice 20:35:01 I would have to use 4096x1024 20:35:03 with offset 20:35:16 oh wait even more 20:35:25 I missed a digit 20:36:04 ok... more than 190 MB 20:38:37 ^bf +[] 20:38:42 ...out of time! 20:38:46 If you need a long-running benchmark, (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ takes pretty damn long before finally giving an "out of time" message. 20:39:01 fizzie, not really long running, I was using gprof 20:39:13 * AnMaster was looking at callgraph 20:39:45 i'm pretty sure we're going to be programming DNA in some analogy of bfbasic soon 20:39:46 ^source 20:39:47 http://zem.fi/~fis/fungot.b98.txt 20:39:52 fizzie, last version ^ 20:39:53 ? 20:39:58 I'm not sure how new it is. Let's diff... 20:40:14 tell me when you have the last one 20:40:30 Seems to be the latest, diff reports no changes. 20:40:49 Haven't done much to it lately. 20:41:03 This week I've been mostly writing jitfunge. :p 20:41:08 -!- testthingy has joined. 20:41:18 %ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 20:41:27 ^ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 20:41:51 Took me some 90 seconds last time. 20:41:53 ah 20:41:58 lets wait 20:42:04 fizzie, how comes it is so slow there? 20:42:32 It builds a long string and then repeatedly swaps it around. 20:42:47 well pushing string on stack is what I made faster 20:42:51 as y does 20:42:57 ...out of time! 20:43:00 +ul ^ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 20:43:01 ...^ out of stack! 20:43:03 ...out of time! 20:43:06 hm 20:43:07 that's odd 20:43:10 It's a 16-kilobyte string. 20:43:14 +ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 20:43:15 specs on your system? 20:43:18 AnMaster: I typoed the program 20:43:28 I mean... fizzie's system 20:43:35 it's obviously a bit faster 20:43:41 1.4 GHz Pentium-M is that fungot box. 20:43:41 fizzie: today's ( one of scheme48, you can implement syntax-rules with it. 20:43:47 fizzie, hrrm 20:43:52 wait 20:43:57 64-bit build 20:43:58 -!- testthingy has quit (Remote closed the connection). 20:43:58 And 32-bit cells, of course. 20:44:09 ...out of time! 20:44:10 It's not a x86-64 platform, after all. 20:44:10 fizzie, concurrency? 20:44:21 Probably enabled if it is by default. 20:44:27 it is on by default 20:44:31 anyway this worries me 20:44:48 testthingy should have been faster 20:44:49 it wasn't 20:46:51 * AnMaster builds old one to test 20:47:21 -!- testthingy has joined. 20:47:27 %ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 20:47:29 ^ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 20:47:31 +ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 20:48:02 which bot is using % as its character? 20:48:06 testthingy, 20:48:11 which is my copy of fungot 20:48:16 ok, presumably that's fungot on optimised cfunge? 20:48:25 ...out of time! 20:48:28 ais523, it is on old pre-last-change cfunge 20:48:38 last change made mycology a lot faster 20:48:38 well, thutubot won 20:48:46 but I want to know if it slowed down fungot or not 20:48:59 ...out of time! 20:48:59 AnMaster: that's quite a lot of doors for people with prior programming experience?' the answer to your question is that 20:48:59 ais523: ( that second one is horizontally displaced by 1 pixel with the hardware directly. :p)) for f(n-1) 2*f(n-2) 20:48:59 AnMaster: we are asked to enter a player's name, but forget about the c2bf2c step 20:49:10 sped it up by the look of it 20:49:13 ...out of time! 20:49:22 hm I guess other stuff running on my system is to blame 20:49:46 for why my 2 GHz x86_64 is slower than that 1.4 GHz pentium M that fungot runs on 20:49:46 AnMaster: in one article then. my ass was saved by moore. i know. it just doesn't look right 20:50:37 43:03 - 41:17 vs. 49:13 - 47:27 20:50:54 anyone wants to do the messy modulo 60 calcs for me? 20:51:26 no one? 20:52:25 ok speed up by 20 seconds 20:52:42 which even on a single run should be enough to be significant 20:52:45 very nice 20:52:55 -!- testthingy has quit (Remote closed the connection). 20:57:36 damn running that with gprof output on takes forever 20:57:52 well I'll check on that when I get back 21:00:05 ah no not 20 21:00:06 10 21:00:46 ok interesting 21:02:27 that stack 21:02:33 where does it go fizzie ? 21:02:49 I mean, how far into negative space 21:03:40 because the main issue is that it seems to work a lot on outer fungespace 21:04:46 -!- Mony has left (?). 21:09:02 The one in that test? Well, 16k cells that way, obviously. 21:10:18 * AnMaster allocates a 128 MB large static array 21:10:40 * AnMaster waits 21:11:29 fizzie, ok I got it down to 41 seconds 21:11:31 using this: 21:11:35 #define FUNGESPACE_STATIC_OFFSET_X (32768-1024) 21:11:35 #define FUNGESPACE_STATIC_OFFSET_Y 64 21:11:35 #define FUNGESPACE_STATIC_X 32768 21:11:35 #define FUNGESPACE_STATIC_Y 512 21:11:55 actually you probably want later Y 21:12:17 fizzie, anyway I believe that is 64 MB 21:12:29 with 32-bit cells 21:13:44 fizzie, thanks to linux allocating that lazily it won't take as much ram in fungot as that 21:13:44 AnMaster: how would you know? 21:13:59 optbot! 21:13:59 -!- optbot has set topic: the entire backlog of #esoteric: http://tunes.org/~nef/logs/esoteric | it's quite loaded and quite popular. 21:14:24 -!- jix has joined. 21:18:59 still it went far into non static space 21:22:12 * AnMaster makes it dump edges 21:24:07 fizzie, err you grow something into positive space: 21:24:09 Coords: {-16395,-20} {16384,2000} 21:24:24 that looks very very strange 21:25:04 fungal growth 21:27:36 fizzie, ok I got it down to 10 seconds with this mad one: 21:27:43 #define FUNGESPACE_STATIC_OFFSET_X (32768/2) 21:27:43 #define FUNGESPACE_STATIC_OFFSET_Y 32 21:27:43 #define FUNGESPACE_STATIC_X 32768 21:27:43 #define FUNGESPACE_STATIC_Y 2048 21:27:48 around 250 MB ram I believe 21:28:13 fizzie, but please try to grow only in one direction 21:28:15 ;P 21:30:11 -!- Sgeo has quit (Connection timed out). 21:31:20 Oh, right. 21:31:44 That 16384 comes from the fact that it writes the string at x=0,y=10 for temporary storage when swapping it on in the stack. 21:31:55 fizzie, so it writes it positive too? 21:31:59 well that messes up 21:32:05 you can get either easily but not both 21:32:16 try to write them all in the same direction 21:32:46 It's not that easy, since STRN can only write in one direction. Of course I could use the current stack-top 'x' coordinate for the temporary storage too, I guess. 21:32:54 -!- jix has quit (Read error: 104 (Connection reset by peer)). 21:33:17 fizzie, don't you use STRN in both cases? 21:33:26 so why does one go positive and the other one negative? 21:33:43 Because the other one is a stack of strings; it's easier to grow that to the negative direction. 21:34:05 well why does the other one go positive then? 21:34:15 Otherwise it's quite difficult to find how long the string is below the positive-stack-pointer. 21:34:46 With the stack growing to the negative direction, I can just G at the current top-of-stack and I get the topmost string. 21:35:11 And the other one grows to the positive direction because it's not a stack; when you P a string to temporary storage, that's the direction it writes to. 21:35:23 fizzie, well, you can't get both, I recommend trying to put both in the same direction 21:35:36 I'm not sure I'm going to bother. 21:35:41 hm ok 21:36:03 fizzie, well by making one huge 512 MB static array I got execution time down to less than 10 seconds for it 21:36:10 The temporary storage start coordinate could follow the top of stack, but that's just extra work. 21:36:34 -!- testthingy has joined. 21:36:39 %ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 21:36:39 ^ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 21:36:39 +ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 21:36:48 ...out of time! 21:36:58 thutubot will be next 21:37:32 ...out of time! 21:37:53 well predicted 21:38:09 ...out of time! 21:38:28 fizzie, however why does it go to positive 2000? 21:38:30 in y 21:38:31 I mean 21:38:55 you could make this reasonable, 64 MB for 32-bit funge, if you didn't go that far 21:39:56 fizzie, hope that will teach you something or whatever 21:40:34 point is the less area you use for the static stuff the less memory you will waste and the more static you can use 21:42:33 There is no point in a Befunge irc-bot, really, no matter how much you'd like there to be. 21:42:48 I did what was convenient to code, not what was optimized for maximum efficiency. 21:42:53 heh ok 21:42:54 :) 21:43:05 fizzie, but why do you use 2000 y? 21:43:18 So that there's room for 1900 lines of code, of course. 21:43:20 There is no point in a Befunge irc-bot, really, no matter how much you'd like there to be. <--- wrong, you wouldn't have made one otherwise 21:43:36 However, you don't really need to have the static space go that far down. 21:43:48 It's only used for storing the programs; for execution, they're copied to y=8. 21:44:00 fizzie, oh? 512 is enough? because then I could actually recommend it on x86 21:44:22 Source code length + 100 is enough. 21:44:48 fizzie, how do you feel about 128 MB RAM? 21:45:04 since it should be power of two 21:45:10 and 512 is not enough 21:45:18 for source code length + 100 21:45:24 so 1024 is next step 21:45:51 -!- testthingy has quit (Remote closed the connection). 21:46:45 luckily the "fill with spaces" code is vectorised 21:46:48 so that is quite fast 21:47:15 -!- omniscient_idiot has quit (Read error: 113 (No route to host)). 21:47:38 -!- Jiminy_Cricket has quit (Read error: 113 (No route to host)). 21:47:51 -!- testthingy has joined. 21:47:55 %ul (xxxx)(~:*:*:*:*~):^:^(~~:^)~^:^ 21:48:04 ...out of time! 21:48:12 AnMaster: where does that particular test program come from, btw? 21:48:19 ais523, fizzie pasted it 21:48:35 as one that took a long time 21:48:48 anyway this array size is way too big for normal usage 21:49:06 if you got 128 MB RAM and/or swap to waste however: 21:49:08 #define FUNGESPACE_STATIC_OFFSET_X 16396 21:49:08 #define FUNGESPACE_STATIC_OFFSET_Y 64 21:49:08 #define FUNGESPACE_STATIC_X 32768 21:49:08 #define FUNGESPACE_STATIC_Y 1024 21:49:37 how does thutubot out of time ais523? 21:49:38 a non-rectangular shape would be a LOT faster 21:49:42 how can string rewriting languages know time. 21:49:54 ehird: it counts the number of times round the main loop it goes 21:50:01 in a number system which vaguely resembles binary but isn't 21:50:10 ah 21:51:04 -!- testthingy has quit (Remote closed the connection). 21:51:13 i accidentally the time 21:52:10 well, don't the time again 21:52:42 well i can't really, i accidentally the WHOLE time 21:52:55 also, i will have to your salary 21:53:50 i think i'm gonna this book now. 21:56:43 oklopol: the WHOLE book?! 21:57:28 no i'll prolly only like 20 pages more 22:03:04 -!- Corun_ has joined. 22:05:27 -!- KingOfKarlsruhe has quit (Remote closed the connection). 22:09:56 -!- Corun has quit (Read error: 110 (Connection timed out)). 22:10:51 fungot's out-of-time check is also just a count of loop iterations, which is why it takes 90 seconds to time out with that program, but only a few for the standard infinite loop. 22:10:52 fizzie: is it just personal preference?, 22:11:04 ^ul (:^):^ 22:11:04 ...out of time! 22:11:23 fizzie: I'm counting the main loop of my Thutu program, not the main loop in the Underload program 22:11:37 ^ul (::^):^ 22:11:37 ...too much stack! 22:12:08 Well, fungot counts the Underload interp loop, so it's pretty close to the amount of underload instructions actually executed. 22:12:08 fizzie: you have 1 message. riastradh says: actually, it would be 22:12:16 ^ul (::^^)::^^ 22:12:17 ...too much stack! 22:12:29 fungot: Do you have a messaging service now too? 22:12:29 fizzie: he annoyed the communist govt and was sent there. 22:12:55 hm 22:13:27 poor riastradh 22:14:51 fizzie, I'm working on improving STRN 22:14:54 #scheme's sarahbot had a feature where you could say "later tell ", and it would repeat that sort of message when next spoke. That's where the quote is from. 22:15:03 however as a side effect of this it won't cast to char in between 22:15:14 at least for P 22:15:20 it may do it for G, not sure 22:16:38 STRN improvements should help the underload interp. Although the Funge code could do with some optimization too. 22:16:57 well I noticed no difference for STRN really here 22:17:04 In the beginning, accidentally a universe. 22:17:14 fizzie, thing that would help: knowing how much you actually are going to push/pop 22:17:22 keeping a counter for that 22:28:39 -!- Corun__ has joined. 22:30:46 -!- Corun__ has changed nick to Corun. 22:31:40 -!- Corun_ has quit (Read error: 60 (Operation timed out)). 22:32:12 real 0m0.048s 22:32:12 user 0m0.032s 22:32:12 sys 0m0.012s 22:32:14 for mycology 22:32:16 \o/ 22:32:19 ais523, ^ 22:32:31 that is profiled build 22:32:40 profile-feedback* 22:32:41 I mean 22:39:03 -!- oklokok has joined. 22:40:28 -!- oklopol has quit (Read error: 104 (Connection reset by peer)). 22:45:35 -!- Sgeo has joined. 23:13:05 -!- Sgeo_ has joined. 23:15:16 -!- Sgeo has quit (Read error: 110 (Connection timed out)). 23:17:40 -!- Corun has quit ("This computer has gone to sleep"). 23:19:16 -!- ab5tract has quit. 23:25:06 -!- oerjan has quit ("Good night"). 23:25:53 -!- olsner has quit ("Leaving"). 23:57:01 -!- optbot has quit (kornbluth.freenode.net irc.freenode.net). 23:57:02 -!- psygnisfive has quit (kornbluth.freenode.net irc.freenode.net). 23:58:21 -!- optbot has joined. 23:58:21 -!- psygnisfive has joined.