| 00:10:00 | NimBot | Araq/Nimrod d1be69e Araq [+0 ±1 -0]: fixes a performance regression for json handling |
| 00:10:00 | NimBot | Araq/Nimrod 48a2d66 Araq [+0 ±1 -0]: support for LuaJIT |
| 00:21:14 | * | q66 quit (Quit: Quit) |
| 00:51:12 | * | XAMPP-8 joined #nimrod |
| 02:25:38 | * | XAMPP_8 joined #nimrod |
| 02:27:13 | * | XAMPP quit (Ping timeout: 245 seconds) |
| 02:27:24 | * | XAMPP-8 quit (Ping timeout: 252 seconds) |
| 02:30:32 | * | XAMPP-8 joined #nimrod |
| 02:32:00 | * | XAMPP_8 quit (Ping timeout: 276 seconds) |
| 03:05:41 | * | XAMPP joined #nimrod |
| 03:19:32 | * | fowl quit (Quit: Leaving) |
| 05:29:29 | * | XAMPP_8 joined #nimrod |
| 05:33:23 | * | XAMPP-8 quit (Ping timeout: 248 seconds) |
| 05:59:29 | * | XAMPP_8 quit (Quit: Leaving) |
| 06:37:00 | * | XAMPP_ joined #nimrod |
| 06:40:58 | * | XAMPP quit (Ping timeout: 245 seconds) |
| 10:48:47 | * | fowl joined #nimrod |
| 11:24:03 | * | Araq_ joined #nimrod |
| 11:37:59 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]) |
| 12:56:38 | * | q66 joined #nimrod |
| 13:28:14 | * | libMAN is now known as libman |
| 13:42:44 | * | libman quit (Quit: leaving) |
| 13:44:10 | * | libman joined #nimrod |
| 14:42:58 | * | Araq_ joined #nimrod |
| 14:45:57 | * | Araq_ quit (Client Quit) |
| 15:44:59 | * | libman quit (Read error: Operation timed out) |
| 17:34:18 | * | gradha joined #nimrod |
| 17:49:48 | * | FreeArtMan joined #nimrod |
| 18:48:55 | gradha | ugh, math.randomize doesn't allow a specific seed value? |
| 18:51:57 | dom96 | hrm, indeed. Seems to simply use the current time. |
| 18:52:47 | * | FreeArtMan quit (Remote host closed the connection) |
| 18:59:38 | gradha | meh, can't add a default "invalid" parameter to randomize since srand48 accetps longs, so there are no wasted values for the int/clong type |
| 19:00:00 | gradha | maybe simply add an overloaded proc randomize(seed: long)? |
| 19:02:46 | dom96 | that would work, yes. |
| 19:03:11 | dom96 | at first I was thinking maybe use -1 as a value which means "use the current time" but then -1 can be a seed too I guess. |
| 19:41:49 | gradha | any idea why the interface for srand48 accepts a cint instead of a clong? the manpage for srand48 says it uses a long instead of an int |
| 19:49:29 | dom96 | maybe the wrapper is simply wrong? |
| 19:51:03 | gradha | hmmm... when you don't specify a type in C isn't the default type int? |
| 19:51:21 | gradha | manpage says srand(unsigned seed), which would implicitly be int |
| 19:51:52 | gradha | and int == long on my machine, so even the normal srand(cint) wrapper would be incorrect, since cint maps to int32, not int |
| 19:53:24 | gradha | maybe srand should accept a csize and srand48 a clong |
| 19:59:14 | gradha | yay, manpage about srand() says it copies the "32 bits of the seed value". So maybe when long was 32bits (did that ever happen?) |
| 19:59:33 | gradha | but more importantly: why am I caring so much about this instead of going on with life? |
| 20:33:05 | gradha | does nimrod have a syntax where you can call a proc with a tuple and the tuple is unpacked into the single parameters? |
| 20:33:22 | gradha | I only found tuple unpacking for return values |
| 20:43:39 | Araq | gradha: no, it's on my (theimaginery part of) todo list |
| 20:44:30 | Araq | your json file was evil btw but it's not slightly faster than the python version on my machine :P |
| 20:44:37 | Araq | *now |
| 20:44:54 | gradha | I know, it's all evilness coming from a python script |
| 20:48:18 | gradha | at some point the whole python script will be implemented in nimrod, for now only serialization will do, and the json is the dump between python/nimrod |
| 20:48:41 | Araq | well the json parser is now on par with python's |
| 20:49:05 | gradha | on my machine now both clock on the "I don't care" scale, so that's enough |
| 20:49:22 | gradha | in the future I plan to pit nimrod's json against the fastest json parser for objc on ios |
| 20:49:42 | Araq | it's 0.05s vs 0.04s |
| 20:50:22 | dom96 | hrm, is Python's implemented in C? |
| 20:50:29 | gradha | your machine is then three times faster than mine |
| 20:51:38 | Araq | dunno if the 0.04s was a debug build :P |
| 20:51:54 | Araq | I would hope python's is implemented in C ... |
| 20:52:24 | Araq | I still didn't get why the nimrod version was that slow |
| 20:52:51 | Araq | it spent most of the time in memset()'ing 2MB strings or something |
| 20:53:09 | Araq | definitely something we can optimize away |
| 20:54:56 | Araq | but I still don't get why it's so much slower, must be some GC weirdness too |
| 20:55:42 | gradha | it looks that way, that's when macs grind to a halt, when they page swap |
| 20:56:05 | gradha | btw, I don't know if it was related, but the system monitor showed the system to be using 20GB of swap, so had to reboot to regain normal use speed |
| 20:56:23 | gradha | could it be that the gc was allocating strings and not freeing them because of a tight loop? |
| 20:59:11 | Araq | not on my 64 bit machine |
| 20:59:20 | Araq | well ... hm |
| 20:59:56 | Araq | perhaps yes |
| 21:00:34 | gradha | it may have been just bad luck too, I'm always torrenting/video encoding in the background, so maybe one of those was the culprit |
| 21:01:12 | Araq | nah I think you're right; it's recursive and there are likely some stack locations that look like pointing to the old strings |
| 21:01:32 | Araq | so indeed it couldn't free and all hell breaks lose then |
| 21:02:15 | Araq | I don't get how anybody can seriously use an imprecise GC |
| 21:02:32 | Araq | nimrod's is only imprecise for the stack and even that already causes problems |
| 21:03:45 | Araq | oh well we'll get it completely precise with C++ codegen or other tricks :P |
| 21:52:54 | * | gradha quit (Quit: Leaving) |
| 23:37:53 | * | XAMPP-8 joined #nimrod |