Conversation with #inferno at Mon Apr 18 05:29:26 2011 on powerman-asdf@irc.freenode.net (irc)
(05:41:49) food left the room (quit: Remote host closed the connection).
(09:54:31) mjl-: powerman-asdf: ☺
(10:30:01) robot12 [~KAZZhilki@proxy10.ts.fujitsu.com] entered the room.
(17:18:45) anth_x [~a@adsl-99-40-132-132.dsl.bcvloh.sbcglobal.net] entered the room.
(17:51:14) powerman: I've benchmark C version of code which create hierarchy of JValue adts similar to one generated while parsing json.
(17:51:27) powerman: And results are really sad.
(17:52:30) powerman: It looks like it took about 0.025 seconds on my system to allocate 100_000 structs (like List* or JValue*) on heap.
(17:53:55) powerman: And my typical data struct (hash with ~13 fields, most strings, one array) require about 56 structs allocated on heap (List*, Array*, String*, JValue*).
(17:54:35) powerman: All that mean just allocating them in heap took about 1.4 sec, without even trying to do real work (parse json).
(17:57:25) uriel: have you tried Go?
(17:57:49) powerman: I can try to optimize this by caching String* using sort of LRU cache. In best case this can lower amount of heap allocations from 56 to 30, i.e. from 1.4 sec to 0.75 sec. But cache housekeeping will took some time, so actual timing will be worse in any case.
(17:58:13) powerman: Yeah, I've tried Go. It's about twice faster than Limbo, but still unexpectedly slow.
(17:58:52) powerman: I've asked on #go-nuts about this, and people confirm they also think json in Go is unexpectedly slow and probably needs to be optimized.
(18:07:11) robot12 left the room (quit: Ping timeout: 240 seconds).
(19:59:51) KillerX [~anant@nat/mozilla/x-icwevzytowitxuwh] entered the room.
(20:15:55) Fish [~Fish@9fans.fr] entered the room.
(21:08:34) KillerX left the room (quit: Quit: KillerX).
(21:08:55) KillerX [~anant@2620:101:8003:200:21b:63ff:fea5:86ee] entered the room.
(21:44:49) KillerX left the room (quit: Quit: KillerX).
(22:07:32) uriel: powerman-asdf: by the way, I think the json code in Go uses reflection extensively, and that is an area that is getting some optimizations at the moment
(22:07:38) uriel: (as in, during the last few hours)
(22:10:52) powerman: uriel: I don't think I'll be using Go in next ~year. I'll wait until it core modules API become more stable.
(22:13:56) uriel: I have not found that to be an issue, and gofix makes it even easier to update stuff when apis change
(22:21:54) powerman: I'm spending nearly all my time developing code for production. Current situation with Go is looks more like bleeding edge, which is usually bad for production. I don't see any issues with using Go right now for own side projects or for learning and experimenting, but usually there no time left for this. :(
(22:29:01) powerman: Go is faster than Limbo and doesn't require special complex runtime environment. That's good. But it doesn't much faster (I think it's about 2-3 times, no more) to make this really critical. And I already have Inferno's runtime installed on all my servers, with ready deploy procedures for Limbo code, so this isn't important for me too.
(22:29:01) powerman: Go is more concise than Limbo, but it's also more complex and flexible. And I tend to think that's not really good, but that's depends and in general doesn't really important.
(22:29:01) powerman: Go is running in standard Linux environment, with all POSIX shit like signals etc, while Limbo run in simple Inferno environment. And that's make developing in Go more complex than in Limbo.
(22:30:14) powerman: uriel: So, for me, if there are no problems with deployment Limbo code, Limbo looks much better than Go.
(22:30:31) powerman: But I didn't researched Go in depth, so I may be wrong.
(22:31:16) anth_x: that's roughly right. it's a great language, but it's *just* the language.
(22:33:33) uriel: powerman-asdf: I find Go way more stable and reliable than Inferno, and bugs get fixed way more promptly
(22:33:43) uriel: the documentation is in better state too
(22:37:31) anth_x: that may all be true, but it's not a useful direct comparison. go's a language; inferno's an OS.
(22:38:33) powerman: uriel: I didn't had any reliability issues with Inferno for a long enough time. Yeah, I had to use patches for issues 122 and 147 (just increment some constants), but that's it.
(22:39:56) powerman: I know there open issue with crashing GUI because of X11-something error, but I use it only occasionally for wm/deb, so it's not a problem for me.
(22:42:06) powerman: All network services implemented in Limbo works very reliably. Probably, only issue I've with them - needs to increase amount of heap memory when starting emu-g, or they may crash because of too low default limits.
(22:43:01) powerman: But that probably much better than default Perl behaviour which just tend to eat _all_ available memory. :)
(23:13:49) fgudin [~none@2a02:a80:0:3010::42] entered the room.
(23:39:12) fgudin left the room (quit: Ping timeout: 248 seconds).
(00:54:31) Fish left the room (quit: Quit: So Long, and Thanks for All the Fish).
(03:15:41) base2design left the room (quit: Quit: base2design).
(03:28:34) perdix [~mkhl@sxemacs/devel/perdix] entered the room.
(03:29:58) perdiy left the room (quit: Ping timeout: 246 seconds).
(05:29:58) The account has disconnected and you are no longer in this chat. You will be automatically rejoined in the chat when the account reconnects.