Conversation with #inferno at Wed Jul 29 04:44:53 2009 on powerman-asdf@irc.freenode.net (irc)
(05:34:48) xjrn [n=jim@astound-69-42-10-25.ca.astound.net] entered the room.
(05:38:08) underspecified [n=eric@walnut.naist.jp] entered the room.
(05:38:15) xjrn: is there any copmarison articles of vm's that include inferno?
(05:53:00) underspecified left the room (quit: ).
(06:11:16) underspecified [n=eric@walnut.naist.jp] entered the room.
(07:38:35) underspecified left the room (quit: ).
(07:41:00) underspecified [n=eric@walnut.naist.jp] entered the room.
(08:55:48) vsrinivas [i=me@rose.makesad.us] entered the room.
(09:02:06) underspecified left the room (quit: ).
(09:02:39) j123m left the room (quit: Read error: 104 (Connection reset by peer)).
(09:05:16) j1m [n=j1m@unas-228.rsity.ru] entered the room.
(09:06:27) j1m is now known as j123m
(09:09:18) uriel: xjrn: I think this is the only thing I know of: http://doc.cat-v.org/bell_labs/timing_trials/
(09:09:47) underspecified [n=eric@isa7-dhcp-116-204.naist.jp] entered the room.
(09:10:17) uriel: xjrn: but it is rather ancient, and not too centered on the VM aspects of the comparison
(09:10:50) mjl-: reading about other vm's, so i can reasonably compare them (perhaps in an article to be written) is on my todo list...
(09:10:54) mjl-: but many things are :)
(09:13:32) mjl-: xjrn: is there anything in particular you're interested in?
(09:16:39) xjrn: i have this metaprogramming concept in a C-like dialect of java i write.   im assessing what amounts to a jit with pointer operations 
(09:17:48) xjrn: in java, i avoid the vm heap on most occasions by programming on top of nio ByteBuffers, the application is a sort of exploration of how to assimlate the Cyc reasoning KB into a far smaller graph representation 
(09:18:01) xjrn: without reosrting to outright c++ (not straight away at least)
(09:19:52) mjl-: why do you need to avoid the heap?
(09:20:14) mjl-: anyway, sounds like a project with many interesting facets :)
(09:20:31) mjl-: inferno's vm & jit(s) should be a useful example
(09:20:47) mjl-: the code is small & readable too
(09:20:51) xjrn: when i was profiling an algorithm once i discovered that if you basically write C functions against large heaps of bytes and ints, you get very good performance, vs. having discrete Object lifecycles
(09:20:53) uriel: xjrn: I assume you have read the Dis papers?
(09:21:00) mjl-: i assume you've read the papers on the dis instructions and vm?
(09:21:09) uriel: (they do have some comparasons with other vm designs...)
(09:21:47) uriel: and resorting to c++? why would anyone ever use c++ for *anything*?
(09:22:24) xjrn: i went to the point of the absurd and have refashioned vtables and lispish type inference systems, in pure java language, but readability does not come close to what is lost in the translation
(09:23:15) xjrn: i should read up on Dis, it may have beenmore than a decade since the last pass i went over inferno
(09:24:19) uriel: xjrn: http://doc.cat-v.org/inferno/4th_edition/dis_VM_design
(09:24:25) xjrn: uriel: the graph operation primitives in boost graph lib are respectable, but not exactly VM 'able
(09:24:41) uriel: boost? /me gags
(09:25:04) xjrn: point being, im not using c++ right now, get it?
(09:25:10) mjl-: xjrn: if you want to read the papers on inferno, download a copy, and read the pdf's in /doc
(09:25:32) uriel: xjrn: my point being: even considering to ever use c++ is wrong
(09:25:50) mjl-: xjrn: bypassing the vm heap, because objects are too slow, i suppose that just indicates that that vm is not for you?
(09:26:28) mjl-: i'm not sure inferno's dis can help with any vtable-like things btw.  would be interested to learn that it does.
(09:27:45) xjrn: uriel: enough already, bjarne worked for bell labs and even on plan 9.   mjl- it was just a profiling exploration.  if i say '30x' performance improvement from removing heap objects, it's not exactly beleivable, let's just say some algorithms might go well in the jit where the object lifecycles are thought through to become pure functional
(09:28:15) mjl-: xjrn: the vm/jit code is in libinterp/ btw.  eg libinterp/comp-386.c is the 386 jit.  das-*.c are instruction disassemblers.  some files are for built-in modules (eg keyring.c), and most others are for pure-c dis instruction impelmentations
(09:34:29) xjrn: this is not bad for C code http://code.google.com/p/inferno-os/source/browse/limbo/limbo.h 
(09:35:39) mjl-: yeah, inferno (and plan 9) is about the sanest c code i have ever seen
(09:35:50) xjrn: i really recognized i was reinventing vtables and sort of took a step back from the whole effort (to make some income) 
(09:37:39) xjrn: lots of nice enums.
(09:42:16) xjrn: has there been attempts to build inferno with llvm jit ?
(09:42:49) mjl-: not that i know of
(09:43:17) mjl-: i put llvm on my list of things to read & learn about.  for comparison with inferno's jit
(09:43:44) xjrn: i have a rusty set of aliases i use to port projects to use llvm-gcc 
(09:44:12) xjrn: the link time optimization, and otherwise live jit, show promise for c based vms' hosted on a vm :)
(09:45:46) xjrn: on the p7zip source tree, on macosx, using llvmgcc -O4 (LTO), vs. gcc-42, my test case was 3 out of 7 seconds quicker 
(09:46:32) mjl-: oh, that is pretty impressive
(09:46:34) xjrn: again, its so good as to be debatable
(09:47:16) mjl-: do you know if llvm's jit-code generation is fast?
(09:48:07) xjrn: it's not seen as a copmetition for the jvm, if that's what you mean
(09:48:25) xjrn: it doesnt support on-stack replacement, whatever that means
(09:48:58) mjl-: well, i don't even know how fast/slow the jvm jit is :)
(09:49:13) xjrn: what's elegant about it is that it is a graph normalization toolkit, code is just a parsed graph.  end of story.  stdin ->  graph -> opt ->  stdout 
(09:49:23) mjl-: but i can understand it doesn't support the things required by a jvm (though the amount of people available for working on it might one day change that)
(09:50:49) xjrn: the thing i worry about in using the jvm or most vm's for large scale distributed work is whether they can possibly respect buswidth and context switch avoidiance with so many kludges working in tandem
(09:52:33) xjrn: that's a euphamism for C++ ftw Uriel
(09:52:40) mjl-: hehe
(09:53:08) mjl-: at least the design goals of the dis vm were in part to keep that sane
(09:53:37) mjl-: (memory bandwidth by not using a stack machine)
(09:54:16) mjl-: what is the problem with context switches?  executing too small threads of executiong at a time?
(09:55:37) xjrn: oh specifically in terms of the java vm, when your object graphs get huge, there is no more pleasant benefits to having a gc system 
(09:56:25) xjrn: when Cyc reaches 100 million KB fact assertions the gc runs ina  degenerative fashion to induce uneccessary swapping
(09:56:46) xjrn: the fix, is to fool it into thinking there's a few extra gigs before it has to kick off gc
(09:57:03) mjl-: yeah, jvm is purely mark & sweep right?  or what's it called.  not reference counted at least
(09:57:23) xjrn: depends on whether it's sun or valinux
(09:57:34) mjl-: depending on your objects being cyclic or not if you'll run into that with the cyc kb on eg dis
(09:57:45) mjl-: ahh, there is a ref counted jvm?
(09:58:16) xjrn: i think the workings of iced-tea and i know for certain gcj and boehm are ref counted but also static copmilation
(09:59:35) xjrn: cyc is a lisp interp with expert system features performing inference, everything is cat/cda
(09:59:48) xjrn: circular references are common
(10:01:41) xjrn: s/cat/cdr/
(10:03:48) xjrn: Cycorp bases the comparison of gcc-3.2 debug binaries against jdk 6 performance and declares java the winner. they turned me down to rebuild the c version in llvm .. but the binary executable they give out has 80000 nm entries
(10:07:10) xjrn: in this instance, they provie what amounts to a lisp program-generated c codebase that is built without the benefit of a devirtualization pass on the lisp translations, even though its a good percentage macros, it still uses a lot of function vectors 
(10:09:20) xjrn: i beleive i already ported my plan9 darwinports to llvm-gcc, but i don't know whether i got past the linker differences
(10:09:55) ***xjrn away sleep
(10:18:25) npe [n=npe@195.207.5.2] entered the room.
(10:22:48) underspecified left the room (quit: ).
(10:32:22) uriel: 06:27 < xjrn> uriel: enough already, bjarne worked for bell labs and even on plan 9. 
(10:32:38) uriel: xjrn: that might be true, but most (all?) of the Plan 9 team *hate* C++
(10:32:44) uriel: and for very good reasons
(10:34:46) underspecified [n=eric@walnut.naist.jp] entered the room.
(10:35:24) Onime [n=omppu@dsl-104-246.netplaza.fi] entered the room.
(10:35:26) Onime left the room (quit: Client Quit).
(10:39:09) xjrn: uriel: though they lean hevily on enums, i see
(10:39:29) xjrn: might as well be my c++ from the 90's
(10:47:00) xjrn: (waiting for melatonin to kick in) the feature of a jit that draws me away from c++ is portability.  jit's come with vm's.  i like jit'd c++, see the above p7zip mention
(10:48:00) xjrn: what i like are 24 bit objects, and the like, which is hard to do if the vm is inerfering with object overheads that more than blow the cache lines 
(10:49:05) xjrn: c++ has no issue with small objects, it just doesn't copmile very portable bytecode, for lack of being a vm spec
(11:06:10) uriel: c++ has an issue with causing server brain damage
(11:16:23) Onime [n=omppu@dsl-104-246.netplaza.fi] entered the room.
(11:16:45) Onime left the room (quit: Client Quit).
(11:48:13) Fish [n=Fish@AVelizy-152-1-81-1.w86-217.abo.wanadoo.fr] entered the room.
(13:00:35) mjl-: are enums a c++ invention?
(13:06:28) mjl-: hmm, calls of pctl(Sys->FORKNS, nil) seem to be hanging...
(13:15:48) mjl-: fun, i'll debug that after lunch :)
(13:34:35) mahjadin [n=maht@87.84.137.35] entered the room.
(13:36:44) mahjadin: http://maht0x0r.blogspot.com/2009/04/build-your-own-inferno.html   I updated the compile instructions to match todays checkout - it still needs some manual intervention
(13:40:33) mjl-: mahjadin: on devtab and oldauth.dis, i think forsyth might just have fixed those
(13:41:47) uriel: 10:00 < mjl-> are enums a c++ invention?
(13:41:49) uriel: no
(13:42:10) mjl-: mahjadin: i think that on linux/amd64, you'll need a mk nuke inbetween makemk.sh and mk install, makemk.sh didn't use -m32 last time i checked, so mk install will try to link all -m32 object files against the few amd64 libs that makemk.sh created.
(13:42:18) mjl-: but i'll have to check that.
(13:42:33) mjl-: uriel: ok, that sounded a bit strange.  but well...
(13:48:49) mahjadin: oh right, ok , dont have a amd64 running to test it with but I'll add your comment
(13:51:15) mjl-: this is the error:
(13:51:27) mjl-: /home/mjl/inf.test/utils/iyacc/yacc.c:1218: warning: the use of `mktemp' is dangerous, better use `mkstemp'
(13:51:27) mjl-: //usr/bin/ld: warning: i386:x86-64 architecture of input file `/home/mjl/inf.test/Linux/386/lib/libbio.a(bgetc.o)' is incompatible with i386 output
(13:51:53) mjl-: (minus one of the two leading slashes on the second line)
(13:52:33) mahjadin: k, I added that to my page
(13:52:46) mjl-: and fwiw, in one of the issue tracker issues charles posted a list of directories that need creation, and a shell script to create them.
(13:53:11) mjl-: too bad they aren't in the hg repo.  but i bet he's thinking of some better way to do it (or consider it an annoyance that one can live with)
(14:03:10) mjl-: hah, that pctl(FORKNS, nil) hang was my own fault, though it's a bit tricky
(14:04:40) mahjadin: k, I added the mkdirs script too now, thanks
(14:05:06) mjl-: the program is zipfs (for reading zip files).  i mounted a zip file, went to some subdir of the hierarchy, cat'ed a file.  the styx read messages caused by that were handled needed on pctl(FORKNS, nil), which caused a walk to dot, ie a styx walk message, which wasn't yet read because the first styx message wasn't done yet
(14:08:03) gualteri: i was after the idea of directly extracting the missing dirs from a proto(8) file: http://inferno-os.googlecode.com/issues/attachment?aid=5524573460061292589&name=hgedir
(14:09:14) mjl-: gualteri: the annoying part is that some of the dirs are required to even build inferno...
(14:09:30) mjl-: so it must be possible to create those dirs with a minimum of bootstrap tools
(14:10:07) mjl-: i still wouldn't mind .hgdicks files.  the previous svn checkouts had junk files _everywhere_ in the tree... the file enumeration argument doesn't really hold too much.
(14:12:24) gualteri: yes, there'll be less .hgdicks files than .svn files around
(14:19:14) gualteri: i've tried to use the minimum of tools, but i'd prefer to have the missing dirs into the repo instead of creating them externally
(14:22:03) mjl-: yeah, me too.  now with every hg clone you make you have to recreate those dirs.
(14:27:13) mahjadin: mkdir OpenBSD/arm; mkdir `{hget 'http://inferno-os.googlecode.com/issues/attachment?aid=-8986372491888485913&name=empties'}; chmod 555 mnt/* n/client/* n/*; chmod 755 n/client; chmod 555 prof
(14:27:54) mahjadin: you've got to get the fonts too
(15:13:28) mjl-: mahjadin: i would recommend getting the tgz snapshot from vita nuova, which includes the base hg repo, the fonts and the missing dirs.
(15:13:38) mjl-: do you have openbsd/arm btw? :)
(15:15:19) mahjadin: no, just without that bit you get OpenBSD/arm/{bin, lib} no such file or directory
(15:15:44) mahjadin: as they are present in the empties file
(15:15:46) mjl-: ah, for mk nuke or something?  or when buildling too?
(15:16:01) mjl-: ah
(15:23:09) j123m left the room (quit: "Leaving.").
(15:27:23) j1m [n=jim@unas-228.rsity.ru] entered the room.
(16:26:32) j1m left the room.
(16:30:52) j1m [n=j1m@unas-228.rsity.ru] entered the room.
(16:31:28) j1m is now known as j123m
(16:31:53) j123m left the room (quit: Client Quit).
(16:32:05) j123m [n=j1m@unas-228.rsity.ru] entered the room.
(16:47:11) underspecified left the room (quit: ).
(16:50:27) underspecified [n=eric@walnut.naist.jp] entered the room.
(16:51:14) underspecified left the room (quit: Client Quit).
(17:37:31) xjrn: uriel> c++ has an issue with causing server brain damage.  
(17:37:54) xjrn: uriel: i'm sorry for your lost server but you seems to be a might bit too trollish on the matter 
(17:41:25) uriel: maybe, but then the people that wrote this 'interview' might also be considered trolls: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
(17:41:59) stu9: and he meant severe.
(17:42:07) uriel: (I can't say who actually wrote it, other than to mention that the author(s) were responsible for big chunks of Plan 9 and Inferno)
(17:42:26) uriel: stu9: that was obvious, he was just ridiculing my bad typing skills
(17:42:32) stu9: oh
(17:42:34) Fish: I thought it was brucee
(17:42:47) ***uriel can't say anything...
(17:46:31) xjrn: you send me the hoax as rhetoric to help me share your opinion of c++ ?
(17:51:46) powerman: xjrn: the 'cat -v considered harmful' subculture can be advocated in different ways
(17:52:07) powerman: uriel does it in his own way
(17:52:44) powerman: other people try to be more polite (i.e. every tool is good for some tasks, there no bad tools, etc.)
(17:53:25) uriel: powerman-asdf: bullshit, there are plenty of bad tools
(17:53:26) powerman: many doesn't even try to advocate it at all and just quietly use it
(17:53:49) powerman: I've tried all these ways in last years.
(17:53:49) uriel: "Object Oriented design is the roman numerals of computing" seems like a rather clear statement to me
(17:54:57) uriel: there are some tools that I find it very hard to understand any justification for any technical and logical reasons to use them
(17:54:59) powerman: Personally, I also think all such polite things it's a bullshit. But if your end-goal is have people listening to you and trying tools/ideas you speak about...
(17:55:13) uriel: powerman-asdf: you are certainly right
(17:55:32) xjrn: i respect c++ as c with templates.  virtual inheritance is pretty much a mistake, imho, but type inference is 'worth doing.'
(17:56:09) uriel: but again, others do things in polite ways, and I'm not sure they are much more sucessful than me (well, in some contexts I'm sure they are, but in the context of promoting Plan 9 / Inferno technologies and disuading people from using crap, I'm not very sure anyone has had much sucess)
(17:56:19) xjrn: inheritance is a macro for ** afaic 
(17:56:37) uriel: inheritance is a macro for commiting intellectual suicide
(17:57:52) xjrn: having c++ implementation of enums _reach me_ before there were C implementations helped me write better code in the early 90's 
(17:59:54) xjrn: i have a huge appreciation for the source tre i've looked at to date, enums make a jit's life easy
(18:00:07) xjrn: sounds like hg is a handful tho
(18:00:19) xjrn: :P
(18:01:51) powerman: Anyway, I think it *must* be advocated, in any way. And doing things as uriel do is much better than doing nothing. People are different, weak/dubitative one are ease to advocate in uriel's way. Strong/extra smart (at least, they usually sure they are smart) people tend to avoid even talking to uriel giving him 'troll/ignore' label.
(18:01:54) vsrinivas: xjrn: c++ enums also != ints, right?
(18:02:36) xjrn: vsrinivas: not mutable ints 
(18:04:27) uriel: 15:01 < powerman-asdf> Anyway, I think it *must* be advocated, in any way. And doing things as uriel do is much better than doing nothing. 
(18:04:45) uriel: powerman-asdf: well, some would (and do) argue that I do more harm than good, they could well be right
(18:05:01) uriel: but I do honestly try to do the best that I can...
(18:05:32) uriel: (and really, is there any system out there that doesn't have any troll / zealots?)
(18:05:54) uriel: powerman-asdf: (still, I certainly agree with your point)
(18:06:21) uriel: powerman-asdf: (and do appreciate your support and understanding, sometimes I feel really deprssed when everyone seem to think my only goal is to actually destroy plan9 :(
(18:06:50) xjrn: uriel: /me guesses he's paid the bidge toll and has crossed
(18:07:22) ***xjrn mistypes
(18:07:32) uriel: hehehe
(18:15:00) powerman: > well, some would (and do) argue that I do more harm than good, they could well be right
(18:15:00) powerman: well, then these people should advocate harder in *their* way to compensate harm you did :)
(18:23:10) uriel: no, instead they go and don't tell anyone what they are doing, and don't release any code, and then blame me for it :(
(18:23:15) uriel: (see recent 9fans discussion)
(18:25:04) xjrn: i can't see a point debating languages too much, at least for the purposes of solving certain problems of scale, it's just about the means to make a polymorphic representation of a knowledge base as a program graph.  
(18:25:55) xjrn: there are no languages that really make a go of mating the optimizer to the data
(18:26:10) xjrn: so you have to rely ona  jit to do that
(18:29:54) xjrn: when considering buswidth, a bigger jit is not necessarily a more effective system.  too bad i've spent so much time in a c++ debate instead of getting source tree pointers :)
(18:37:11) underspecified [n=eric@softbank220043052007.bbtec.net] entered the room.
(18:39:54) mahjadin left the room (quit: Read error: 110 (Connection timed out)).
(18:46:43) teh_eekster is now known as eekee
(18:49:28) xjrn: im reading this passage of the Dis desgin.. Because reference counting is an exact rather than conservative form of garbage collection, the type of all data items must be known to the VM run-time system. For this reason, the language-to-VM compiler generates a type descriptor for all compound types. This descriptor reports the location of all pointers within the type, allowing the VM to...
(18:49:30) xjrn: ...track references as items are copied.
(18:50:13) xjrn: does this have the featureset to do type polymorphism ?
(18:50:48) Fish left the room (quit: Read error: 54 (Connection reset by peer)).
(18:50:52) xjrn: err, perhaps what answers the root of the question, can these types be treated as unions?
(19:02:02) npe left the room (quit: ).
(19:17:16) uriel: hummmm... I'm not sure, but I don't think so, but that is just a gut feeling and 'm probably wrong
(19:38:23) mahjadin [n=maht@87.84.137.35] entered the room.
(19:38:47) mahjadin: recompiling inferno when editing the .c is dull :>
(19:43:27) uriel: it is also very fast, if you use ken's compilers
(19:56:20) olegfink: xjrn: what type of polymorphism? I'd say this doesn't affect parametric polymorphism in any way
(20:04:39) mahjadin: come one, 4 minutes to compile the whole of inferno is a joke
(20:12:00) uriel: mahjadin: let me guess, you are using gcc?
(20:34:07) j123m left the room (quit: Read error: 54 (Connection reset by peer)).
(20:58:15) j1m1 [n=jim@unas-228.rsity.ru] entered the room.
(20:58:24) j1m1 left the room (quit: Client Quit).
(20:58:44) j123m [n=jim@unas-228.rsity.ru] entered the room.
(20:59:23) mahjadin: oh yeah, I forget that part, it is gcc, lol
(21:02:09) mahjadin: can you use 8c on Linux to compile it /
(21:02:10) mahjadin: ?
(21:04:11) mjl-: you can compile native kernels that way
(21:04:15) mjl-: not elf's
(21:08:55) vsrinivas: passing -H5 to 8l makes an elf, iirc