| 00:27:16 | * | Trixar_za is now known as Trix[a]r_za |
| 00:39:38 | reactormonk | Araq, found anything? |
| 00:45:53 | * | q66 quit (Remote host closed the connection) |
| 03:13:07 | * | SirKronos joined #nimrod |
| 03:13:14 | SirKronos | good night people |
| 03:13:25 | SirKronos | good night Dom, Araq |
| 03:14:49 | SirKronos | hey dom, I've just posted a new reply on the aporia thread |
| 03:36:18 | * | SirKronos quit (Quit: Page closed) |
| 03:53:37 | * | Roin quit (*.net *.split) |
| 03:55:42 | * | Roin joined #nimrod |
| 05:21:59 | * | FreeArtMan joined #nimrod |
| 07:19:01 | * | gour joined #nimrod |
| 07:31:07 | * | fowl quit (Read error: Connection reset by peer) |
| 08:00:50 | gour | dom96: morning...didn't have time yesterday...in regard to why mirror nimrod on BB (instead of GH), i tend to agree with linus (https://github.com/torvalds/linux/pull/17#issuecomment-5654674) that why not using git's pull-request...at the moment it looks that majority of DVCS users use their system just like a polished svn :-( |
| 08:09:37 | Zor | Araq: poke |
| 08:26:41 | * | Araq_ joined #nimrod |
| 08:43:11 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344]) |
| 09:09:31 | * | gour quit (Disconnected by services) |
| 09:09:32 | * | gour_ joined #nimrod |
| 09:19:06 | * | fowl joined #nimrod |
| 12:48:24 | * | xcombelle joined #nimrod |
| 13:44:21 | * | FreeArtMan quit (Ping timeout: 252 seconds) |
| 13:48:40 | * | xcombelle quit (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.) |
| 14:18:11 | * | gour_ is now known as gour |
| 14:59:48 | * | q66 joined #nimrod |
| 16:17:13 | * | FreeArtMan joined #nimrod |
| 17:00:08 | * | xcombelle joined #nimrod |
| 17:51:58 | Araq | Zor: ping |
| 17:59:51 | Zor | Araq: pong |
| 18:03:03 | Araq | well? |
| 18:12:18 | Zor | oh, right |
| 18:12:23 | Zor | what do you use for EH? |
| 18:12:50 | Araq | C++'s native mechanism for C++ codegen, setjmp for the C target |
| 18:14:51 | Zor | ah, speaking of which, is compiling to C++ considerably slower than C? (i.e. does compiling the resulting C++ take much longer?) |
| 18:15:21 | Araq | hrm good question |
| 18:15:31 | Araq | let me check |
| 18:17:13 | Zor | I've been wondering if the relative slowness of C++ compilers is mostly related to the way typical C++ code is written, and not so much just the fact that it's C++ |
| 18:17:42 | Zor | if this is the case, C++ emitted by a compiler should be fast enough to compile |
| 18:17:52 | Zor | I've just never gotten around to testing it |
| 18:22:11 | Araq | my config is broken currently, but I remember it was significantly slower |
| 18:22:47 | Araq | but then Gnu C++ is not famous for its compile times anyway |
| 18:23:04 | Araq | on visual C++ there is no difference iirc |
| 18:23:18 | Araq | but that may only be because they don't care for C support anymore |
| 18:23:24 | Zor | mmm |
| 18:23:53 | Zor | ok, so back to the original question: how exactly do you insert the sjlj code? |
| 18:24:02 | Zor | I'm not intimately familiar with how sjlj is typically used for EH |
| 18:24:27 | Araq | a 'try' statement is expensive, it translates into a setjmp |
| 18:25:30 | Araq | 'raise' becomes longjmp |
| 18:26:11 | Araq | plus there is some code that handles a linked list of jmpbufs |
| 18:26:44 | Araq | however, there is nothing else involved, for instance ordinary function calls have no overhead over C calls |
| 18:26:56 | Araq | no need for hidden argument passing etc. |
| 18:30:29 | Araq | the linked list of activation records is kept on the C stack, the top of the stack is in thread local storage |
| 18:30:54 | Zor | can I read the code for that somewhere? |
| 18:31:49 | Araq | it's spread over the stdlib and the code generator |
| 18:32:07 | Araq | and it's incredibly hard to get all the details and the supported nesting right ;-) |
| 18:32:24 | Araq | better you translate some Nimrod examples and look at the produced C instead |
| 19:17:26 | * | exhu joined #nimrod |
| 19:18:39 | Araq | hi exhu |
| 19:19:46 | exhu | hi Araq, i wonder if it's possible to "precompile" i.e. preparse sources and store them in cache as parse trees, so as to speed up compilation (like PPU in freepascal). |
| 19:21:32 | Araq | exhu: --symbolFiles:on do something like that; zahary broke them ;-) |
| 19:22:10 | Araq | but they used to work; it's hard to get them stable though as debugging them is such a pita |
| 19:22:18 | exhu | so it should be possible to implement in the future. |
| 19:22:27 | Araq | most of it is implemented |
| 19:22:30 | Araq | only bugs remain |
| 19:22:34 | exhu | good |
| 19:24:09 | exhu | and i have not found how to make gcc compile several files and give each file output name |
| 19:24:32 | Araq | why is that important? |
| 19:25:04 | exhu | it seems gcc startup time makes compiling slow |
| 19:27:21 | exhu | but i'm not sure, maybe it's just C is so slow -) |
| 19:27:42 | Araq | get a multi-core cpu |
| 19:29:15 | Araq | or maybe nimrod detects a wrong number of cpus for you |
| 19:29:48 | * | FreeArtMan quit (Read error: Operation timed out) |
| 19:29:54 | exhu | well it bootstraps nimrod for reasonable time, don't worry. |
| 19:30:07 | exhu | i just enjoy how fast fpc is -) |
| 19:31:52 | exhu | every time i think i should throw away my core2duo 1800 mhz desktop (2006 year) i launch lazarus and postpone -) |
| 19:32:21 | Araq | fair enough ;-) |
| 19:32:24 | gour | exhu: do you still program in fpc/lazarus? |
| 19:32:33 | Araq | FPC flies indeed |
| 19:33:07 | exhu | gour, no i don't program anything, just testing some small stuff, play with new features, experiment. |
| 19:33:16 | exhu | gour, in lazarus/fpc |
| 19:33:46 | gour | exhu: so, now you do program in nimrod, right? |
| 19:34:25 | exhu | gour, i write a single app in nimrod, it's a files database, uses sqlite |
| 19:34:36 | exhu | gour, it's faaaaar from being useful |
| 19:35:00 | gour | exhu: are you happy with sqlite & nimrod? i plan to use it as app's storage format |
| 19:35:03 | exhu | gour, because i learn nimrod using it |
| 19:35:17 | gour | exhu: cool. all the best! |
| 19:36:24 | exhu | gour, i have tried several designs to map objects to db tables etc. (first tried to do simple ORM using type info), then decided to use templates and compile-time features. I don't need ORM any more, i use tuples. |
| 19:38:24 | gour | exhu: i also do not plan to use ORM, but relational algebra, if possible |
| 19:38:51 | exhu | gour, don't know what relational algebra means, here what is ready https://github.com/exhu/Palitsa/tree/master/nimrod |
| 19:39:09 | exhu | gour, but it can change completely several times, if i find a feature in nimrod that suits me better -) |
| 19:42:01 | Araq | exhu: actually delphi used to compile an order of magnitude faster than FPC IME |
| 19:43:15 | exhu | delphi was win32-centric |
| 19:43:59 | gour | nimrod is not at all slow guy, isn't it? |
| 19:45:11 | exhu | i remind good old times when delphi was fast on then AMD K5-PR90 (pentium 90 mhz - like) with 8 megabytes and win95 was about 60 megs on hdd -) |
| 19:45:31 | Araq | speed is a feature, gour, can't be fast enough for IDE support |
| 19:45:32 | exhu | gour, nimrod is not slow |
| 19:46:07 | exhu | gour, but i can't forget delphi/fpc's compilation speed =) |
| 19:46:13 | * | gour hopes to be happy staying with emacs |
| 19:46:32 | * | gour remembers turbo-pascal being nice one as well |
| 19:46:41 | Araq | they got but reports their "compile" button did nothing :D |
| 19:46:55 | exhu | turbo-pascal 5.5 was also lighting fast on 80286 640 kb machine |
| 19:47:43 | Araq | *bug reports |
| 19:48:45 | exhu | modern applications feel sluggish even on my i5 sandy bridge laptop |
| 19:50:14 | exhu | and i saw latest photoshop star up on desktop i5 3570 with 8 gb ram, SSD, it is amazingly slow app for such hardware. |
| 19:52:49 | reactormonk | Araq, I assume you didn't find the --def stuff yet |
| 19:53:25 | Araq | reactormonk: it worked for me after I figured my /tmp doesn't contain what yours does ;-) |
| 19:54:22 | reactormonk | Araq, huh? |
| 19:54:30 | reactormonk | oh. |
| 19:58:35 | Araq | exhu: "software is getting slower more rapidly than hardware becomes faster." |
| 19:59:29 | reactormonk | Araq, :D |
| 20:01:50 | exhu | i wonder what big crap did ms put into win vista etc, so that it occupied 20+ gigs on drive and can do nearly nothing compared to 2 gb default ubuntu installation with office, gimp etc |
| 20:03:29 | reactormonk | /dev/sda3 28G 24G 3.1G 89% / |
| 20:05:00 | exhu | reactormonk, too many updates in the cache probably -) |
| 20:05:16 | reactormonk | 839M/var/cache |
| 20:05:17 | exhu | reactormonk, don't forget to remove old kernels |
| 20:05:30 | reactormonk | 29M/boot |
| 20:07:51 | Araq | and a 2gb ubuntu is not small either ;-) |
| 20:09:45 | exhu | du -hc /home |
| 20:09:57 | reactormonk | /dev/mapper/home on /home type ext4 (rw,relatime,commit=600,data=ordered) |
| 20:10:24 | exhu | amazing |
| 20:11:57 | exhu | i have xubuntu on 5 gigs |
| 20:12:27 | * | xcombelle quit (Remote host closed the connection) |
| 20:12:47 | exhu | 26G /home 26G total /dev/sda6 38448788 33033876 3461788 91% / |
| 20:13:20 | exhu | i have gits, netbeans and a lot of stuff in my home |
| 20:14:14 | reactormonk | exhu, I think that's the SSD degrading... |
| 20:14:35 | reactormonk | because I used about ~ 15G according to du |
| 20:16:21 | exhu | i don't have ssd on my linux computers |
| 20:19:08 | exhu | i have ssd and sata drives at work and i don't feel any difference when compiling big project on ssd or on hdd. imho, SSD makes sense for laptops when used in cars/city buses. |
| 20:54:17 | * | exhu quit (Quit: Leaving) |
| 21:32:48 | Araq | ping Zor |
| 21:33:12 | Zor | pong |
| 21:34:39 | Araq | do you know what - for instance - the JVM's GC does in order to prevent full collections when the program's working set keeps growing? |
| 21:35:22 | Araq | I can think of a few heuristics for a generational GC, but I don't know what is used in state of the art GCs |
| 21:36:26 | Araq | if you don't have generations it looks like its a very common worst case |
| 21:37:38 | Araq | a mark and sweep GC would constantly re-scan the whole graph (scenario is that the mutator produces no garbage) |
| 21:42:52 | * | gour quit (Quit: WeeChat 0.4.0) |
| 21:46:45 | Zor | sorry, I'm not too familiar with the JVM's GC strategies |
| 21:47:16 | Zor | (or the JVM in general - I only vaguely know the type system and instruction set) |
| 21:47:38 | Araq | replace JVM with .NET/Mono then ;-) |
| 21:47:55 | Araq | actually I can't find anything about this in papers |
| 21:48:41 | Zor | I think there is some documentation on SGen on the mono wiki |
| 21:48:53 | Zor | it might have what you're looking for |
| 21:49:16 | Araq | hmmm I read that before |
| 21:49:30 | Araq | I don't think it contains anything about the topic |
| 21:51:52 | Araq | but you got what I mean, right? |
| 21:53:17 | Zor | 21:51:28 < alexrp> kumpera: does sgen currently do any heuristics to avoid redundant scanning when a program appears to just be expanding its working set rapidly (i.e. producing no garbage)? |
| 21:53:21 | Zor | 21:52:10 < kumpera> alexrp: no |
| 21:53:23 | Zor | 21:52:22 < kumpera> well, sort of |
| 21:53:26 | Zor | 21:52:41 < kumpera> it does have an heuristics on to how to expand the major heap |
| 21:53:29 | Zor | 21:53:02 < kumpera> in that it expands it faster if the suvivor rate is bigger |
| 21:54:09 | Araq | that's not what I mean, even primitive m&s GCs do this |
| 21:54:16 | Araq | but thanks :D |
| 21:54:41 | Zor | er? |
| 21:55:06 | Araq | it *is* what I meant, sorry |
| 21:55:32 | Araq | but "in that it expands it faster if the suvivor rate is bigger" is no valid solution ;-) |
| 21:56:07 | Zor | right |
| 21:57:44 | Araq | so ... if I have a growing working set N, a tracing GC performs O(N) work, manual memory management O(1) |
| 21:58:03 | Araq | (there are O(1) allocators around) |
| 21:58:22 | Araq | how come nobody talks about that? |
| 21:59:49 | Zor | maybe it hasn't been a huge problem in practice? |
| 21:59:55 | Zor | what kind of program are you having this problem in? |
| 22:00:31 | Araq | compilers ;-) |
| 22:01:06 | Araq | if you do whole program compilation the AST keeps growing and you can't do much about it |
| 22:01:51 | Araq | especially if you need to keep all the function bodies around as they may be invoked at compiletime as possible in Nimrod's case |
| 22:03:22 | Zor | one (rather terrible) way you could deal with it is just disable collections while you're allocating all the AST nodes |
| 22:03:32 | Araq | it's not a problem for nimrod's GC though as it doesn't trace in the first place ;-) |
| 22:04:26 | Araq | but it made me wonder how other GCs can deal with it |
| 22:08:15 | Zor | how do you actually deal with cycles? |
| 22:09:42 | Araq | it's based on this paper: http://www.google.de/url?sa=t&rct=j&q=bacon03pure.pdf&source=web&cd=1&ved=0CDMQFjAA&url=http%3A%2F%2Fresearcher.ibm.com%2Ffiles%2Fus-bacon%2FBacon03Pure.pdf&ei=CIQuUeyeEMnftAb_mIGwAw&usg=AFQjCNELErgZBRbzBdOeZEvFeVyPOQL8IQ&bvm=bv.42965579,d.Yms&cad=rja |
| 22:10:03 | Araq | but beware the paper's algorithm is buggy ;-) |
| 22:21:12 | * | JStoker is now known as JStoker2 |
| 22:28:54 | reactormonk | Araq, so the idetools work on your machine even for the compiler? :-/ |
| 22:32:16 | Araq | reactormonk: your example works, but there are other examples that don't work for me |
| 22:32:42 | Araq | but I'll look into it later, I'm improving the overloading resolution instead |
| 22:32:57 | Araq | so we'll get back $ for object soon ;-) |
| 22:34:31 | reactormonk | \o/ |
| 22:34:35 | reactormonk | I'm all for that |
| 22:47:55 | Araq | Zor: g++ runs as fast as gcc on most produced files |
| 22:48:25 | Zor | interesting |
| 22:48:25 | Araq | except it freezes on 3 of them :-/ |
| 22:48:53 | Araq | so I can't time it properly |
| 22:49:11 | Zor | that is...unfortunate |
| 22:49:42 | Araq | hmm forget what I said |
| 22:50:22 | Araq | it fails on every file |
| 23:08:32 | Araq | Zor: btw wtf is "Kotlin"? who cares about it? ditto for Groovy? |
| 23:09:13 | Araq | Russel lives in a weird alternative universe ... |
| 23:09:22 | Zor | I don't know ... |
| 23:09:39 | Zor | groovy seems to be popular as an embedded language for java apps |
| 23:11:48 | Araq | "Why types on the right? |
| 23:11:50 | Araq | We believe that it makes the code more readable. Besides, it enables some nice syntactic features, for example, it's easy to leave type annotations out, and Scala has proven pretty well that this is not really a problem." |
| 23:12:12 | Araq | I see, so Scala was the first language to actually "prove" it works :O |
| 23:12:40 | Araq | never mind pascal did it in the 70ies ... |
| 23:18:13 | fowl | nope, scala was the groundbreaker here |
| 23:18:31 | Zor | clearly |