[00:00] hehe ... I like that idea [00:00] Maybe I should give each version a codename [00:01] So version 0.1.0 will be the "Vaporware" version :) [00:01] *sigh* [00:02] why? [00:03] too much sarcasm today [00:03] lol [00:05] hm [00:05] corewarcompiler ;) [00:06] but which target to we choose? [00:06] x86 asm would kind of boring [00:07] I would like to vote for brainfuck or whitespace :) [00:07] especially whitespace would be a very nice language [00:08] easy to read and print [00:10] ok, time to get some sleep [00:11] * Fluffy waves [00:11] Part: Fluffy left #corewars [00:12] MSG: Quit: humhum [00:33] hrm [00:34] Join: johnkw joined #corewars [00:38] hello [00:39] hi [00:40] soar, whenever i look at you nickname, "highsoar" comes to my mind [00:40] which is from Master of Orion [00:40] heh, :) [00:40] never played that game [00:41] but at least it gets some recognition :) [00:52] MSG: Ping timeout: 252 seconds [01:13] MSG: [01:47] Join: pkhuong joined #corewars [02:48] Join: johnkw joined #corewars [03:11] MSG: Ping timeout: 252 seconds [04:16] * soarkalm is away: I'm busy [04:29] Join: pkhuong joined #corewars [05:12] Part: soarkalm left #corewars [10:58] MSG: Read error: Operation timed out [11:25] Join: Mizcu joined #corewars [11:28] Join: Core29 joined #corewars [12:12] Join: fiveop joined #corewars [12:49] Join: Roy joined #corewars [13:02] hi R [13:02] hello [13:14] Join: pak21 joined #corewars [13:47] MSG: Quit: Trillian (http://www.ceruleanstudios.com [14:31] Join: pkhuong- joined #corewars [14:31] MSG: Read error: Connection reset by peer [14:51] MSG: Ping timeout: 252 seconds [15:42] Join: Metcalf joined #corewars [15:42] Hi [15:43] Hi JM [15:43] h [15:43] Found a prime yet Roy? [15:44] What is speedierscanner? [15:46] Speedierscanner is a ReZoom scanner (pk's making one) [15:46] No, no big prime, you? :) [15:46] 23523*2^101388 is biggest yet [15:46] Not been home yet, so I don't know :-) [15:46] Hrm, maybe 23523*2^102882 (bit bigger) [15:47] Tomorrow I will let you know the exact ranges I have searched for K=1143, 2667 and 3039 [15:47] Do you think there are any other Corewar numbers familiar enough to search? [15:47] 8000? :P [15:47] http://corewar.co.uk/numbers.htm [15:47] Can't do even numbers :-( [15:47] I know :) [15:48] Maybe Recons step, I quite like that one [15:48] It would just become 125 and N would increase by 6 [15:48] Are the Koth hills down? [15:49] Are they? (goes have a look) [15:49] MSG: Ping timeout: 252 seconds [15:49] Seems to work just fine here (haven't send anything) [15:49] Aww...the queue! [15:50] time to spam someone [15:50] Maybe a fight is going on on the multiX hill... [15:50] Sometimes it doesn't show right when its fighting [15:50] No, look at the time submitted [15:51] Ups, that was the only thing I looked at, 16:23, not that DATE! [15:58] MSG: [15:58] I really can't wait until I have a big prime... boy o boy, my machines (2) are running non-stop currently 24h a day [16:00] I have 6 running 24h per day, but 4 are searching for primes big enough to be in the top 200. [16:01] Heh, and that is a bit hard :) [16:01] Top 5000 is my first aim ;-) [16:02] But, as said before: Its also a bit of luck, you could get the biggest prime ever the first number you try [16:03] The first prime I had found was already on the list :-( [16:04] Thats also a risk you have [16:05] Not any more. [16:05] No, there are no primes starting with 2667 ;-) (no big primes) [16:05] Now I ensure I don't search a range which anything has previously been discovered in [16:06] But discovered/searched is something different [16:06] Did I point you to the Prothsearch site yesterday? [16:06] Uhm...no? [16:06] It lists searched ranges for K from 3 to 1199 [16:06] .net? [16:07] Yes :-) [16:07] k [16:07] Ah yes, you did point that out [16:09] But I just choose a very big K, doesn't hurt the crunching or something right? [16:10] With proth, a larger K won't slow it down. [16:10] If you use LLR, it will [16:11] How many potential primes are you testing in 24 hours? [16:11] Erhm...about 3000? no idea [16:11] Not values sieved out, but actually tested values [16:11] Ohw hmm, don't know [16:12] I think one prime will take about 10/15minutes now [16:13] You should be able to tell from Proth.log [16:14] On my 1.4GHz machine I am testing one prime in 5 minutes using LLR [16:15] Hmm, I should be faster (faster machine) [16:15] I will give you a link in a minute [16:15] Proth is easy to use [16:15] LLR requires the range to be pre-sieved [16:16] newPGen.. [16:16] Yes :-) [16:16] I tried that, it can sieve with multible K's [16:17] LLR is in here ftp://mersenne.org/gimps/ [16:18] Possibly file llr362.zip [16:19] Sieve with k.2^n+1 with K fixed. [16:20] Choose a range for N of about 100000, and leave it for about a day. [16:20] (or until is only removes one candidate every minute or two) [16:20] The feed the output to LLR [16:21] Yeah, they also suggested newPGen -> PRP -> Proth [16:21] Much quicker if you intend to seach for a length of time. [16:22] When I last tested, LLR was as fast as PRP [16:23] Ok, so it doesn't matter.. I'll try LLR this time [16:25] I pointed Proth out to you to begin with, because it is quick and easy to set up. [16:26] My advice would be to spend a little bit of time with Newpgen and LLR - you'll get results much sooner. [16:27] Nice, NewPGen, is running now [16:27] By the way, you need to test on average 3000 candidate primes to find a prime. At 5 minutes each this should take about 10 days [16:29] With LLR, when K reaches about 245000, it uses a bigger FFT and slows down by about 50% [16:30] Other prime search programs slow down for the same reason. I'm not sure at which K the next FFT size increase is after 245000 [16:30] Ohw, thats a nice limit :) [16:31] SOrry, I meant N in the last couple of things I said, not K [16:33] Ohw yeah, I read it as N [16:34] For N=1200000 I am taking two hours to test a candidate on a machine which took five minutes for tests with N=220000 [16:34] Well yeah, the higher the N, the more time you need. Thats the reason there aren't bigger primes yet [16:35] But your not looking for Mersenne primes right? The price for the big prime is only for a Mersenne prime [16:36] No, the prize is for any prime over 10 million digits. [16:36] If it is a Mersenne prime, you will have to share the prize [16:36] Howver, if I find a prime with N=1200000 it won't be anywhere near big enough [16:37] Join: Fluffy joined #corewars [16:37] hey guys.. how's it going/ [16:37] :) [16:37] Hi Fluf [16:38] I've just installed my new NSLU2 :) [16:39] JM: times 0,30103 right, so you'll have about 1/3th [16:39] works quite nice, especially after I've replaced the original firmware [16:39] Hi Jens [16:39] :) [16:39] whatcha got fluffy/ [16:39] Hi Bvowk, it's going quite well. [16:40] Does anyone have access to the original U.S.A. issues of Scientific American containing the Core War articles? [16:40] I won't have access till the tech library in my building is open again john.. should be on the third [16:41] :-) [16:41] bvowk: http://www.linksys.com/servlet/Satellite?childpagename=US%2FLayout&packedargs=c%3DL_Product_C2%26cid%3D1115416906769%26site%3DUS&pagename=Linksys%2FCommon%2FVisitorWrapper with http://www.nslu2-linux.org/ :) [16:41] new router eh? [16:41] running linux? [16:42] not a router, a NAS [16:42] yes, it runs linux [16:42] at nslu2-linux.org you can find several replacements for the original firmware [16:43] you should be able to run anything, you want, on it [16:43] I've already replaced the original crappy SMB with NFS [16:58] hmm .. that is nice, I can run bittorrent client on it [17:06] The nano hill is quite recently :-/ [17:07] * Metcalf thinks it is too tough for the evolvers now [17:14] Metcalf is trying to shake the evolvers ready :) [17:14] ready->awake [17:15] No, I think the time of nano evolvers is over [17:16] 7th and 9th are evolved warriors.. [17:17] Likely not for much longer [17:32] hey. [17:32] don't you get all uppity old man.. [17:32] Roy, I think bvowk means you [17:33] heh [17:33] * Metcalf thinks it is too tough for the evolvers now [17:34] I only say old man because while you're only slightly older than me.. you've been at corewars far longer :) [17:34] Join: Core29 joined #corewars [17:34] Hi [17:35] that and I couldn't think of a better comeback :( [17:36] * bvowk heads for food to contemplate the mighty comeback of the evolvers... [17:37] This is why I am asking about the copies of Scientific American http://en.wikipedia.org/wiki/Talk:Core_War [17:45] Join: johnkw joined #corewars [17:46] Hi JKW [17:46] JKW: koth is broken, but it wasn't me, honest [17:53] MSG: Ping timeout: 252 seconds [18:04] When I think of JM I also imagine a old wise man :) [18:04] Hmmm... [18:04] You just act like one! [18:04] And I'm not making friends today... [18:05] Do I look old? http://myweb.tiscali.co.uk/corewar/me1large.jpg [18:07] You look drunk [18:08] I'm not! [18:08] No... you look like you are sleeping [18:08] ZzzzzZzz [18:08] Actually, you look english [18:08] No, I'm looking at a printout. It was sunny, so I couldn't see very well. [18:09] I am not drunk, sleeping or English! [18:09] You are not? [18:09] (not English?) [18:09] Nope [18:09] But your arms glow in the dark like English people, and I think you become like a tomato in the sun [18:14] So, where are you from then? [18:14] Ireland..? [18:21] Yes [18:21] Well actually I am half Irish ;-) [18:22] Okay, time to go [18:22] * Roy waves [18:23] Good luck with the primes etc :) [18:23] Something to add to the date debate http://groups.google.com/group/net.mag/msg/551d358b723e8eff?dmode=source&hl=en [18:23] * Metcalf waves [18:23] MSG: Quit: mov.i #1,1 [18:36] Join: Mizcu joined #corewars [18:48] MSG: [19:29] Part: Fluffy left #corewars [19:49] Join: johnkw joined #corewars [20:52] Join: pkhuong joined #corewars [21:08] MSG: [22:28] Join: Fluffy joined #corewars [22:29] :) [22:29] hmm ... problems with koth.org :( [22:30] just finished another bout of hacking on my ~parser generator. [22:30] *blinks* [22:30] Hi pkhuong :-) Which language do you use? [22:30] common lisp [22:30] :( [22:31] I designed a recursive-descent parser DSL [22:31] (with backtracking) [22:31] I should really read on packrat parsers to see how to make it [time] O(n) [22:31] why? [22:31] I'm looking for a good parser generator for Python ... because I don't want to write a parser for warrior files [22:32] for pymars? [22:32] yes, but it has a new name [22:32] PyCorewar now [22:32] how much of the preprocessor do you want to support? [22:32] all [22:32] :/ [22:32] google PYacc or something ;) [22:33] Have already worked with it? [22:33] no, but I'm guessing it exists [22:33] That is the problem. There are too many parser generators for Python [22:33] re the parser generator, it's a bit annoying that I basically rewrote a PEG while knowing PEGs existed but without seeing I was doing that [22:34] hehe [22:34] I've done the same for PyCorewar [22:34] I wanted to have a MARS with a decent Python interface. I've taken a quick look at exhaust [22:34] for my defense, though, I was coming from the angle that it can parse arbitrary graphes [22:34] and started to write the MARS [22:35] which is a bit more complex than strings. It just so happens that, when used on strings, it is recognizes PEGs. [22:35] :/ [22:35] -is [22:35] -is [22:35] erh [22:35] and does your pg now work? [22:35] yeah, has been for a while. [22:35] I'm just adding features, etc. [22:36] :) [22:36] which isn't too hard since I'm always sticking to the DSL or pure CL, without having to play in its innards w/ exposed continuations, etc. [22:37] Haven't done any decent project with CL ... [22:39] I'm prototyping stuff for the math contest in CL, and writing that pg, beginning a concurrent calculus VM. [22:39] (anything rather than reviewing calc) [22:41] How about writing a new warrior? [22:42] hmm ... on the other hand koth.org has problems so it wouldn't be fun without getting result [22:42] *results [22:43] argh [22:43] Again it is time to announce, that I'm stupid! [22:43] oh, trying to fix my version of speedscanner [22:43] (the scan w/o attacking part) [22:44] think it'll have to cost 1 extra line... [22:44] The whole day I've been working on an idea for PyCorewar. I've rewritten and debugged the MARS. And for what? [22:45] Nothing! It isn't even a tiny bit faster than the old version :( [22:45] it's in python. [22:45] with some C [22:46] Except for the parser [22:46] The MARS itself is a C-module to get some speed [22:48] k [22:48] Still not faster than fmars :( [22:48] what mpu? [22:48] and by how much [22:48] cpu? [22:48] *mpu? [22:49] yes, on what cpu are you testing? [22:49] Dual-Celeron, 500 MHz [22:49] Join: Roy joined #corewars [22:49] actually only on one processor [22:49] Hi Roy! [22:50] Hiya [22:50] eep. [22:50] Want me to have a look at the C core? [22:50] pkhuong: pMARS - 4.0 MIPS, fmars: 10.5 MIPS, PyCorewar - 9.3 MIPS [22:51] not bad [22:51] but it is only icws '88 [22:51] '94 shouldn't be much worse [22:51] No, not bad at all..! But he always wants to be the best [22:51] or different actually [22:51] ofc. [22:52] '94 might be a problem [22:52] You might want to test on something mmore modern [22:52] For '88 I've created a big switch on opcode/a-mode/b-mode [22:52] the perf specs are totally different from an C500 [22:52] that's what you want to do. [22:52] Except possibly direct function pointers/computed gotos instead of a switch [22:52] * Roy found a new (small) prime [22:53] Roy: How do you know, that it is new? [22:53] pkhuong: Yes, that's what fmars does [22:53] Erhm because uhm... [22:53] I don't actually, but I found it anyway :) [22:53] And how do you know, that it is prime? [22:53] The change anybody else found it is pretty small [22:54] * Roy checked and double checked it with two prime-finding programs [22:54] 6557*2^102991+1 (31008 digits long) [22:54] pkhuong: Yes, I have to test it on a newer machine, but for now a C500 is enough, because it is all, I have [22:56] i think joonas and I discussed dispatching tricks a couple months ago. [22:56] on rgc? [22:56] on #cw [22:56] :/ [22:56] and the logs are gone :( [22:56] And on the wiki [22:56] (right?) [22:56] possibly [22:57] ISTR writing a quick summary [22:57] There where some (draft)tricks explained there [22:57] pkhoung: How is the scanner going? ;-) [22:57] looks like I'll have to add a line [22:57] and I may lose my invisible line too [22:58] so that'd be 9 full insns [22:58] :/ [22:58] 9 is a bit much.. that'll become +/- 13 lines with a decent clear [22:58] yes :/ [22:59] pm? [22:59] you might have a better idea [22:59] -13 would be really nice :) [23:02] so yeah... tricks [23:02] smartEiffel likes binary search trees instead of memory indirect jumps for message dispatching. [23:02] http://www.pvk.ca/tiki/tiki-index.php?page=ImplementationTricks [23:02] I'll paste the link here too ;-) [23:03] The fact that search trees are more easily optimised away seemed to be a reason, but they said it also acted like a pseudo hardware inline cache [23:05] hmm ... at the moment I'm thinking about your very first idea [23:05] no idea what you're talking about [23:05] follows the link [23:05] hey I can write that fast [23:05] one mo [23:05] :) [23:06] fmars does: while (...) goto( functable[insn]) [23:06] why not your idea: while (...) goto insn [23:07] not a big difference. [23:07] It shoulnd't make that much difference to implement the last one, if you can do the first one [23:07] yeah [23:07] but it would remove one table lookup [23:07] fmars does goto(functable[])? [23:07] yes [23:07] wow. use computed gotos to their fullest [23:08] store them directly in the instructions' field ;) [23:08] yes, I still can compare instructions. There is no difference in comparing a function pointer or a constant (for the given insn/amod/bmode) [23:08] yup [23:09] :around, :before and :after methods coming to ruby2... [23:10] actually. no [23:10] skip that too [23:10] and what then? [23:10] ok. [23:10] Let's do what steele did in RABBIT [23:10] ? [23:10] no automatic var in the instruction code. [23:10] jump at the end of each opcode [23:10] that's what most forths do. [23:11] Skip the trampoline, make sure you don't use stack space in each instruction's code and tailjump to the next instruction to execute [23:12] But how do I know, which instruction to execute next? [23:12] It is all in the process queue and not at the instruction, I'm currently executing [23:13] or do I miss sth? [23:13] TELEPHONE ... [23:13] BED... [23:13] :) [23:13] just inline the dispatch sequence at the end of each instruction's code. [23:14] * Roy waves, not following the hightechtalk anyways [23:14] nite! [23:14] MSG: [23:14] that'd be good for now... If you do want to try and have multiple dispatch points to take advantage of periodicity, you'd have to change that, but not for now... [23:23] Thanks for the nice ideas :) [23:26] meh [23:27] You might think it is all old stuff, but for me it is sth. I would have never thought about [23:27] inlining the dispatch is likely to have much more effect on the C500 than on a modern x86 [23:27] (newer x86s have return prediction, I'm not sure the celly does) [23:28] don't know either [23:30] pretty sure it doesn't actually [23:30] Do you have any idea of how to take advantage of the different opcode frequencies? [23:31] (with the goto(insn) version) [23:32] depends on the cost of a conditional branch mispredict [23:32] (relative to an indirect jump) [23:33] which probably depends on the cpu, you are using [23:33] still, a rough figure. [23:45] naw, doesn't look like there's any difference. [23:45] might want to try and dispatch for both warriors at the same time... [23:46] since there doesn't seem to be any easy way to improve the prediction [23:50] I've just started the "big" comparison between pmars and pycorewar, i.e. run a lot of fights (with all warriors from '88 Koenigstuhl) and compare the results of pmars and pycorewar [23:50] good [23:50] I hope I won't find any differences in the results [23:51] mm., yeah, so the best thing we got so far is to try and dispatch on n instructions [23:54] Then I know, what I will try [23:54] which is? [23:54] goto(insn)? [23:55] I think, I really should start to write, what I think, not assume,t hat everybody knows ;-) [23:55] ;) [23:55] yes, first goto(table[insn]), then goto(insn) [23:55] k. [23:55] And inline that at the end of each instruction. [23:55] yes, right! [23:56] then you'd pretty much have what fmars has [23:56] except, that I don't have to recompile it every time [23:57] But when I'll implement '94 it will become a problem, because writing a "function" for each opcode/modifier/amode/bmode might produce too much code [23:58] doubtful. [23:58] or even if it does, you could have 2 fields [23:58] dispatch and additional info [23:59] It doesn't matter now. At the moment I still have to do a lot for '88 :)