Show enters and exits. Hide enters and exits.
| 08:30:10 | thehcdreamer | Hi, I'm trying to install rubinius on mac but I get this backtrace: http://pastie.org/793207 not sure if I'm missing something. |
| 08:45:38 | somebody | thehcdreamer, use pre-build llvm |
| 08:45:53 | somebody | ./configure --skip-system |
| 08:45:56 | thehcdreamer | somebody_: ok thanks |
| 10:29:33 | duncanmv | evan: hi |
| 11:04:11 | duncanmv | cd rue/j rails |
| 11:04:15 | duncanmv | argh |
| 11:11:35 | dbussink | duncanmv: going well, he? ;) |
| 11:39:58 | duncanmv | just hit http://github.com/evanphx/rubinius/issues/labels/build#issue/86 |
| 12:11:02 | kronos_vano | duncanmv, try to use prebuild llvm |
| 12:25:30 | duncanmv | kronos_vano: I am packaging rubinius so not possible |
| 12:57:12 | kronos_vano | duncanmv, also you can build rubinius without llvm |
| 12:58:29 | duncanmv | kronos_vano: that is how I had before |
| 14:11:43 | duncanmv | evan: I got the first rubinius package: http://download.opensuse.org/repositories/devel:/languages:/ruby:/rubinius/ , building without llvm for now (issue above) and binaries are not symlinked to /usr/bin yet (I have to find out how to make it use alternatives or any method so they dont clas with normal ruby) |
| 16:19:44 | tarcieri | Binding is silly |
| 16:20:02 | tarcieri | apparently rbx has a non-silly Binding object? |
| 16:20:08 | tarcieri | amasing! |
| 16:20:11 | tarcieri | with an s |
| 17:13:13 | evan | tarcieri: :) |
| 17:13:23 | slava | evan! |
| 17:13:29 | evan | Mr. S! |
| 17:17:56 | lypanov | evan. slava. |
| 17:20:34 | slava | evan: my epic visual studio port is complete, all gnu assembly is gone |
| 17:20:50 | slava | evan: I also removed the primitive table. primitives work similarly to rbx now :) |
| 17:21:01 | slava | before I had to maintain two lists, and the order had to match up, so stupid |
| 17:34:37 | rue | Morning |
| 17:36:13 | evan | slava: ha! yeah, i learned that sucks a long time ago. |
| 17:36:23 | evan | name => function pointer is a lot easier. |
| 17:48:43 | BrianRice-work | "similar to rbx" means name => fp? |
| 18:06:44 | evan | BrianRice-work: i'm assuming thats what he means. |
| 18:07:22 | BrianRice-work | k |
| 18:08:42 | slava | evan: yeah, primitives are done with what is a tiny baby FFI |
| 18:09:53 | evan | oh, how so? |
| 18:10:03 | evan | mine are as well, but it's more like a static FFI |
| 18:10:15 | evan | done by infering wrapper code from the signature of the C++ method. |
| 18:11:23 | slava | hi evan |
| 18:11:28 | evan | :) |
| 18:11:33 | slava | I renumbered my irssi tabs, and keep getting confused |
| 18:11:48 | evan | hehe |
| 18:11:55 | evan | yeah, that happens to me sometimes too |
| 18:11:57 | slava | its always th esame people in every channel anyway |
| 18:12:04 | evan | yeah |
| 18:12:06 | evan | anywho |
| 18:12:38 | evan | you're right on using one big chunk of address |
| 18:12:46 | evan | it has a bad limiting factor. |
| 18:13:57 | evan | i guess in that case |
| 18:14:09 | evan | you'd have to clamp the size |
| 18:14:25 | evan | and have a hard error when you try to create too many VMs in the same address space |
| 18:15:07 | evan | slava: it appears that by default on my machine |
| 18:15:13 | slava | does rbx support mvm yet? |
| 18:15:18 | evan | the JVM takes up 428M of virtual mem. |
| 18:15:34 | evan | slava: ironically, we were the first to support it |
| 18:15:38 | evan | but i've since broken it |
| 18:15:43 | evan | fixing it again is easy though. |
| 18:16:19 | slava | neat. supporting mvm was one of my motivations for switching to c++ but I'm not there yet :) |
| 18:16:48 | evan | not using any global data since the very beginning makes it quite easy. :) |
| 18:17:19 | slava | evan: our vm objects don't use global data at all, to the point that if you start a new vm it has no way of communicating with the other one. that's he problem :) |
| 18:17:41 | slava | it needs something more efficient than pipes, to take advantage of the sahred address space |
| 18:17:42 | evan | well |
| 18:17:47 | slava | to pass messages back and forth |
| 18:17:52 | evan | yeah, i coded that up too |
| 18:17:55 | slava | how did you handle that? |
| 18:17:57 | evan | there is a manager object |
| 18:18:10 | evan | to handle the multiple VMs |
| 18:18:29 | evan | so, what i did there was the manager object had mailboxs |
| 18:18:31 | evan | one for each VM |
| 18:18:36 | evan | each VM has a VMid |
| 18:19:03 | evan | and a VM could wait for a "VM message" by doing Rubinius::VM.read_message |
| 18:19:12 | BrianRice-work | hm |
| 18:19:14 | slava | did you combine VM messages with non-blocking IO? |
| 18:19:17 | evan | a pipe was used |
| 18:19:22 | evan | to provide IO blocking |
| 18:19:24 | evan | and waking |
| 18:19:28 | slava | see what I'd want is to have a green thread in each VM in charge of talking to other VMs |
| 18:19:38 | evan | sure |
| 18:19:42 | slava | and incoming messages from other VMs would wake up green threads, in the same way that pending IO does |
| 18:19:43 | evan | you use the pipe trick. |
| 18:19:47 | slava | with one big multiplexer |
| 18:19:47 | slava | ok |
| 18:19:51 | evan | to announce "there is data ready" |
| 18:19:53 | slava | so you have a pipe and you add it to the multiplexer? |
| 18:19:59 | evan | and you store the data into a buffer that the other VM has access to |
| 18:20:01 | slava | and store the data elsewhere, in malloced memory? |
| 18:20:02 | evan | in my case |
| 18:20:02 | slava | ok |
| 18:20:07 | slava | that sounds reasonable |
| 18:20:07 | evan | I used the internal marshaller |
| 18:20:12 | evan | to take a ruby object, turn it into bytes |
| 18:20:12 | slava | is there a pipe between every pair of VMs? |
| 18:20:16 | evan | put it into a mailbox |
| 18:20:26 | evan | write to the other VMs pipe, so it wakes up |
| 18:20:34 | evan | yeah, a read/write pair per VM |
| 18:20:47 | evan | a VM waits on it's read pipe when it wants a message |
| 18:20:49 | slava | ok, cool |
| 18:20:52 | evan | and a writer does |
| 18:21:00 | evan | write(vm[id].write, "!", 1); |
| 18:21:05 | evan | after it puts the message in the mailbox |
| 18:21:12 | slava | see, I want to have multi-VM threading, and also have a thread pool in each VM for async ffi calls |
| 18:21:25 | slava | this is better than native threads that share a GIL |
| 18:21:42 | evan | ah, yaeh. |
| 18:22:05 | slava | farming out ffi calls to a native thread pool, and running green threads, has better properties |
| 18:23:11 | slava | do you think you'll add some form of green threads at some point? |
| 18:23:28 | evan | well, i'll probably add fibers post 1.0 |
| 18:23:30 | slava | what machinery do you use for ruby 1.9 enumerators? |
| 18:23:36 | slava | fibers they're called? |
| 18:23:46 | evan | fibers are basically coroutines |
| 18:23:57 | evan | a simple version of continuations |
| 18:24:08 | evan | you'd build a green thread scheduler on top of them |
| 18:24:08 | slava | yeah, and green threads are closely related to coroutines |
| 18:24:09 | evan | if you wanted. |
| 18:25:56 | slava | evan: and then you'd need soome code to turn blocking IO API calls into yielding to the green thread scheduler and doing non-blocking IO for all green threds at once |
| 18:26:22 | slava | evan: if you make the green threads efficient enough this will be a big performance boost for network servers that handle large numbers of connections |
| 18:26:43 | slava | evan: and the code won't have to be all contorted like anything that uses twisted python or similar |
| 18:26:49 | slava | programming directly for non-blocking io is teh suck |
| 18:27:09 | slava | jruby will never have this :) |
| 18:29:27 | jptix | slava: i think you'll need to repeat that later :) |
| 18:30:49 | BrianRice-work | just have him blog about it |
| 18:31:08 | BrianRice-work | I've been looking into this for a bit; might make it my next priority |
| 18:33:26 | slava | BrianRice-work: its a shame that no books about VMs discuss implementation of green threads |
| 18:34:17 | BrianRice-work | slava: yeah, Iain Craig's book gets a tiny bit into it, but not in a truly helpful way. it's typical academic-style book publishing, though. |
| 18:35:40 | evan | i'm back |
| 18:35:42 | evan | what did i miss. |
| 18:35:49 | evan | while freenode freaked the fuck out. |
| 18:36:03 | BrianRice-work | hm I don't have that book on my desk. I think I sent it back to my home bookshelf |
| 18:36:42 | BrianRice-work | evan: slava had a few more comments on green threading and blocking i/o |
| 18:36:53 | evan | gotcha. |
| 18:37:00 | evan | was it 'DON'T DO IT!" |
| 18:37:01 | evan | :) |
| 18:37:01 | BrianRice-work | "<slava> evan: and then you'd need soome code to turn blocking IO API calls into yielding to the green thread scheduler and doing non-blocking IO for all green threds at once |
| 18:37:02 | BrianRice-work | evan: if you make the green threads efficient enough this will be a big performance boost for network servers that handle large numbers of connections |
| 18:37:02 | BrianRice-work | evan: and the code won't have to be all contorted like anything that uses twisted python or similar |
| 18:37:02 | BrianRice-work | programming directly for non-blocking io is teh suck |
| 18:37:03 | BrianRice-work | jruby will never have this :)" |
| 18:37:33 | evan | thats what MRI does |
| 18:37:43 | evan | so MRI already has a leg up on twisted |
| 18:37:44 | evan | in that regard. |
| 18:37:52 | slava | but does it scale in practice? |
| 18:38:18 | slava | anyway, a hybrid m:n threading system would be ideal |
| 18:38:20 | slava | if you got rid of the gil |
| 18:38:31 | slava | but supported green threads for non-blocking i/o's sake anyway |
| 18:38:42 | evan | well yes |
| 18:38:48 | evan | i've got a few moves to make |
| 18:38:52 | evan | one is removing the GIL. |
| 18:39:04 | evan | i've already been making steps in that direction |
| 18:39:09 | evan | but probably won't finish before 1.0 |
| 18:39:29 | slava | green threads sounds like something that will be a natural next step once you implement the fiber api |
| 18:39:40 | evan | certainly we can play with it. |
| 18:39:47 | slava | once your vm can play with its own call stack |
| 18:39:56 | evan | I should check out how sun's MxN setup works |
| 18:40:26 | slava | I thought the jvm was always 1:1? |
| 18:40:33 | evan | not in the jvm. |
| 18:40:34 | evan | in solaris. |
| 18:40:37 | slava | oh |
| 18:40:39 | slava | hmm |
| 18:40:40 | evan | solaris has (or had) MxN |
| 18:41:27 | slava | I presume the userspace component is similar to how threading is implemented in libc on some bsds |
| 18:42:12 | slava | I'm not sure how it works with blocking system calls |
| 18:42:25 | slava | do they block all threads on the 'N' side of the equation? |
| 18:42:33 | slava | how can it be truly pre-emptive? |
| 18:42:56 | evan | right |
| 18:43:15 | slava | it seems unusual to attempt to do transparent M:N threading at the OS level, since you're papering over the semantic differences etween real threads and what you cook up in user space |
| 18:43:15 | evan | i'm not sure if balances the userspace threads among the kernel threads |
| 18:43:28 | evan | or if it implements a userspace scheduler that can "block" a userspace thread for IO |
| 18:43:28 | slava | maybe in solaris, all syscalls have a non-blocking version? |
| 18:43:41 | evan | right, becuase if you do |
| 18:43:43 | slava | and so the threading lib implements a big multiplexer and scheduler |
| 18:43:47 | evan | syscall(0x7f, ...); |
| 18:43:51 | evan | then you block. |
| 18:43:54 | slava | yeah |
| 18:44:00 | slava | hmm |
| 18:44:06 | evan | and unless libc has a special syscall function that doesn't block |
| 18:44:09 | evan | even so |
| 18:44:18 | evan | there is code that uses RAW syscalls. |
| 18:44:22 | slava | that would add so much overhead if all calls were non blocking |
| 18:44:23 | evan | which libc can't see. |
| 18:44:29 | slava | yeah |
| 18:44:45 | evan | so I dunno |
| 18:44:49 | slava | maybe they just had a separate API forgreen threads? do you have a reference for this? |
| 18:44:52 | evan | maybe there is some kernel support to assist |
| 18:45:02 | evan | sort of like how the page tables work |
| 18:45:11 | evan | you manipulate them at the higher level |
| 18:45:19 | evan | so the lower level can read them and react. |
| 18:45:37 | evan | lets see if i can find it. |
| 18:46:22 | evan | ha |
| 18:46:23 | evan | http://www.sun.com/software/whitepapers/solaris9/multithread.pdf |
| 18:46:25 | evan | page 18 |
| 18:47:49 | evan | so they probably had too many problems. |
| 18:47:58 | evan | and if they were swappable |
| 18:48:04 | evan | then it was surely only at the libc level. |
| 18:48:14 | evan | so there was still the ability to block a kernel thread |
| 19:37:48 | boyscout | CI: rubinius: 6b9b7ad successful: 3024 files, 11752 examples, 35958 expectations, 0 failures, 0 errors |
| 19:38:21 | evan | that was off. |
| 19:38:22 | evan | odd. |
| 19:50:38 | devinus | has anybody managed to use rails 3 on rubinius? |
| 19:51:15 | evan | i've setup a basic app |
| 19:51:18 | evan | using sqlite3 |
| 19:51:27 | evan | haven't gone much beyond that. |
| 20:20:35 | kronos_vano | evan, I've sent pull request. Do you see patches? |
| 20:20:58 | evan | sorry i haven't gotten to them |
| 20:21:28 | kronos_vano | ok |
| 20:22:25 | evan | this commit |
| 20:22:25 | evan | http://github.com/kronos/rubinius/commit/ee9b5d7c835fc1f9b99cb446023498f0dca13e49 |
| 20:22:29 | evan | is incorrect |
| 20:22:39 | kronos_vano | explain please |
| 20:22:41 | evan | we don't allow changes to specs in commits with other things. |
| 20:22:46 | evan | you must do them as seperate commits. |
| 20:22:54 | kronos_vano | ok |
| 20:22:54 | evan | thats allows us to sync spec/ruby |
| 20:23:14 | kronos_vano | I already sent patch to rubyspec |
| 20:23:17 | evan | k |
| 20:23:24 | evan | well, you said these are patches as well? |
| 20:23:29 | evan | in issues |
| 20:24:45 | kronos_vano | #162 #163 |
| 20:25:38 | evan | please tag them as patch |
| 20:25:47 | evan | that makes them easier to sort out |
| 20:25:52 | evan | i'll apply them later today |
| 20:26:42 | kronos_vano | ok, tnx |
| 20:45:43 | slava | evan: lets make an XML virtual machine with a self-hosting XML parser |
| 20:45:52 | evan | sounds like fun! |
| 20:46:01 | slava | generate machine code from assembler templates with XSLT |
| 20:46:14 | slava | the name sounds bad-ass |
| 20:46:20 | slava | XML Virtual Machine enterprise edition(tm) |
| 20:47:10 | evan | XVM |
| 20:47:37 | evan | how many levels deep does the XSLT transforms need to be? |
| 20:47:42 | evan | i'm thinking at least 5 |
| 20:48:00 | evan | machine code optimizations via XSLT transform |
| 20:48:10 | BrianRice-work | ow this just makes my brain hurt |
| 20:48:29 | evan | where's your sense of adventure! |
| 20:49:31 | BrianRice-work | maybe if it could be macro-generated from scheme or something :P |
| 20:50:29 | slava | parrot should switch to xml bytecode |
| 20:50:38 | slava | just when you thought it couldn't get any more absurd |
| 20:51:25 | slava | the trick is to make an xslt to machine code compiler, in xslt |
| 20:51:25 | BrianRice-work | isn't aware of parrot absurdities, but he's chosen not to pay attention to it... |
| 20:51:28 | slava | and use it to compile itself |
| 20:51:37 | tarcieri | Object#id IS deprecated; use Object#object_id OR ELSE. |
| 20:51:38 | tarcieri | lol |
| 20:51:50 | evan | :) |
| 20:52:04 | tarcieri | or else you are likely to be eaten by a grue? |
| 20:52:15 | evan | course. |
| 20:52:20 | tarcieri | awesome |
| 20:53:50 | tarcieri | >> Marshal.dump Binding.new |
| 20:53:50 | tarcieri | => "\004\bo:\fBinding\000" |
| 20:53:52 | tarcieri | :O |
| 20:53:55 | evan | heh |
| 20:54:00 | evan | supported! |
| 20:54:04 | tarcieri | yay! |
| 21:02:17 | slava | tarcieri: can your company give me a few million to design enterprise xml acceleration cards? |
| 21:02:29 | tarcieri | rofl |
| 21:02:50 | slava | the special coprocessor uses proprietary anglebracketscan(tm) technology to parse xml faster than a cpu |
| 21:03:04 | tarcieri | sweet! |
| 21:03:06 | slava | all using the xml virtual machine of course |
| 21:03:11 | tarcieri | that's sure to make JBoss boot faster |
| 21:03:27 | slava | yeah, just convert the JBoss JAR file into XML |
| 21:03:54 | slava | <jar name="JBoss.jar"> ... base 64 encoded data follows |
| 21:04:53 | tarcieri | JBoss needs to parse a few billion lines of XML in order to boot already |
| 21:04:54 | tarcieri | heh |
| 21:05:24 | rue | Huh, I wonder if it was brixen that went through the Picasso at MoMA |
| 21:05:26 | slava | does it do DTD validation every time too? |
| 21:06:05 | slava | an XML virtual machine will compile DTDs to native code using tracing JITs |
| 21:06:22 | slava | you could really get some suits excited about this |
| 21:06:54 | tarcieri | lulz ohjeezus |
| 21:07:25 | slava | I think we should tunnel all TCP/IP traffic through SOAP |
| 21:07:59 | slava | this way firewalls will only ever have to open port 80, it will be teh secure |
| 21:08:20 | Defiler | JSON over UUCP over SOAP |
| 21:08:28 | tarcieri | lulz uucp |
| 21:08:34 | BrianRice-work | punchcard over JSON |
| 21:08:54 | tarcieri | after using JBoss I am really impressed by the whole application platform concept and wish there were some sort of Ruby equivalent |
| 21:09:16 | tarcieri | JBoss itself is still and ugly monsterous tentaclebeast |
| 21:09:30 | slava | is hot code reloading pretty much non-existent? |
| 21:09:48 | tarcieri | it's kind of there |
| 21:10:02 | Defiler | My favorite JBoss game is watching it boot and seeing how many acronyms I recognize |
| 21:10:05 | tarcieri | you copy a "WAR" file into its deploy directory and it magically notices it somehow and deploys it |
| 21:10:07 | BrianRice-work | "people hate J2EE. ruby guy invents Rails as alternative, markets it like crazy making Ruby popular. Ruby user 5 years later decides that JBOSS is cool, ports it to Ruby. Ruby becomes anti-marketed, loses prominence. Javascript inherits the earth." |
| 21:10:09 | slava | I've read about it taking 30 seconds to bounce an app |
| 21:10:11 | rue | Defiler: Why would you use JSON if you are already using XML? |
| 21:10:15 | tarcieri | Defiler: hahahahahahahaha no doubt |
| 21:10:24 | tarcieri | slava: yeah that's pretty much the case |
| 21:10:42 | slava | JBoss prints more messages than the linux kernel when it starts up |
| 21:11:02 | Defiler | rue: Well of course your company mandates that all messages be in XML format, so you do <json> </json> |
| 21:11:05 | tarcieri | yeah watching JBoss try to initialize a data source spews literally a few thousand lines of logs |
| 21:11:26 | slava | so why do you want this for ruby? |
| 21:11:36 | Defiler | Wait, you weren't kidding about liking JBoss? |
| 21:11:36 | tarcieri | oh I can't initialize this data source yet! I need the AbstractDataSourceAdapter! |
| 21:11:37 | Defiler | Whoa. |
| 21:11:51 | tarcieri | Defiler: liking the application platform concept, not JBoss |
| 21:12:06 | Defiler | gem bundler is all the application platform I feel the need for |
| 21:12:08 | tarcieri | Defiler: I have database failover! :O :O :O |
| 21:12:23 | tarcieri | it was actually easy to configure! |
| 21:12:32 | evan | THIS.. IS.. REPLICATION! |
| 21:12:46 | tarcieri | well, yeah, but... client-side support |
| 21:12:47 | tarcieri | heh |
| 21:12:58 | Defiler | You have database failover that will work as long as none of your databases actually fail |
| 21:13:03 | Defiler | Is generally what that means :) |
| 21:13:11 | tarcieri | we did a test today |
| 21:13:14 | tarcieri | it worked just dandy |
| 21:13:28 | slava | Defiler: `j2ee technologies only have to give the impression of actually working |
| 21:13:33 | Defiler | Was your test filling up the disk on one of your databases? |
| 21:13:35 | Defiler | Heh |
| 21:13:47 | tarcieri | it was literally unplugging the database server from the network |
| 21:13:54 | tarcieri | or rather, one of them |
| 21:14:02 | slava | what if its plugged in but the data is corrupt on one of them? |
| 21:14:11 | tarcieri | then you're fucked I guess? |
| 21:14:11 | tarcieri | heh |
| 21:14:16 | Defiler | exactly |
| 21:14:19 | Defiler | failover is domain-specific |
| 21:14:21 | slava | so what's the point of having it? |
| 21:14:27 | slava | either way, if a disk dies, you're fucked |
| 21:14:30 | tarcieri | in case the psu dies? |
| 21:14:35 | tarcieri | or it doesn't boot for some reason |
| 21:14:35 | slava | except if you have two disks and you don't know which one is right, youre fucked too |
| 21:14:40 | tarcieri | or the network card dies |
| 21:14:43 | tarcieri | or mysql won't start |
| 21:14:50 | tarcieri | or it overheats and crashes |
| 21:14:50 | slava | ok, but if one gets corrupted |
| 21:14:56 | tarcieri | yes it won't solve corruption |
| 21:15:02 | tarcieri | but you could make the same argument for RAID |
| 21:15:02 | slava | if you know which computer is bad, then its useful |
| 21:15:04 | slava | you take it offline |
| 21:15:06 | tarcieri | that doesn't mean RAID is useless |
| 21:15:08 | slava | but if you don't know, it won't tell you |
| 21:15:26 | slava | well, as Defiler noted, there are better ways of doing this |
| 21:15:39 | tarcieri | *shrug* |
| 21:15:42 | tarcieri | it solves a number of problems |
| 21:15:46 | tarcieri | not all of them, but a number of them |
| 21:16:04 | slava | is this actually ahibernate feature? |
| 21:16:05 | tarcieri | any that result in a total node failure |
| 21:16:11 | tarcieri | dunno |
| 21:16:19 | tarcieri | it's a feature of a JNDI datasource, I guess? |
| 21:16:24 | tarcieri | Java acronyms confuse me |
| 21:16:33 | slava | jndi, wtf is that |
| 21:16:44 | tarcieri | java name doohickey, inc |
| 21:17:01 | Defiler | Java Naming and Directory Interface, I think? |
| 21:17:05 | slava | see, ruby doesn't need most of this crap |
| 21:17:07 | tarcieri | sure! |
| 21:17:21 | tarcieri | yeah Ruby could do it with 5 billion fewer layers of abstraction |
| 21:17:44 | slava | java apis are always so generic |
| 21:17:58 | kronos_vano | Can anyone explain how to tag tickes on github? |
| 21:18:00 | slava | everything is a wrapper around somethingelse |
| 21:18:09 | Defiler | kronos_vano: I couldn't figure it out |
| 21:19:39 | evan | you click the check boxs next to the ticket |
| 21:19:50 | evan | then you click the "down" arrow on the tag and select "apply to selection' |
| 21:20:19 | evan | great |
| 21:20:21 | evan | it appears to be broken. |
| 21:20:57 | evan | oh, there it goes. |
| 21:21:05 | evan | yeah, it seems to not work sometimes though |
| 21:21:27 | Defiler | I had trouble getting the checkbox behavior, vs. it taking me to the tickets that had those tags |
| 21:21:42 | evan | *shrug* |
| 21:21:45 | evan | i need lunch. |
| 21:21:46 | evan | bad. |
| 21:22:05 | slava | evan: when you generate code with llvm, does each function you generate have the same signature, at the ABI level? |
| 21:22:54 | evan | yes |
| 21:22:55 | slava | what do the function pointers look like when you call compiled code? |
| 21:23:06 | evan | they all have the same signature. |
| 21:23:10 | evan | ok, bbiab. |
| 21:55:46 | khaase | hi |
| 21:56:01 | khaase | anybody seen something like this: http://gist.github.com/286298 |
| 21:56:23 | Defiler | make sure you don't have any old .rbc files around |
| 21:56:33 | Defiler | That's what comes to mind, at least |
| 21:57:20 | khaase | yeah, you're right. really sucks rvm doesn't cope with that. guess that was the issue the last time, too. |
| 21:57:57 | Defiler | rvm may need to be hitting up a 'clean' task somewhere I guess |
| 22:09:53 | devinus | evan: how useful would a grid of packages that do/don't work in rubinius yet be? |
| 22:10:12 | evan | sure, seems useful. |
| 22:12:07 | jvoorhis | evan: hi |
| 22:12:22 | evan | hello |
| 22:13:04 | jvoorhis | without looking at what i have so far, can you tell me how you'd expect ruby-llvm to wrap LLVM types? |
| 22:14:21 | jvoorhis | i didn't have any design going in, and i just realized i'm going to have to tidy it up |
| 22:14:55 | jvoorhis | one thing i want to support easily is managing parallel FFI::Struct and LLVM::Struct declarations, if feasible for a first release |
| 22:15:49 | evan | ew. |
| 22:15:50 | evan | no |
| 22:15:52 | evan | don't bother. |
| 22:15:54 | evan | thats not useful. |
| 22:16:01 | jvoorhis | hm |
| 22:16:08 | evan | LLVM types should be normal objects |
| 22:16:31 | evan | unrelated to any of the FFI type stuff |
| 22:16:39 | jvoorhis | my use case would be for sharing PortAudio's user_data pointer between a ruby app and a jit-compiled callback |
| 22:17:13 | rue | devinus: Very useful; reserve isitrbx.com :) |
| 22:17:15 | evan | you could make something that takes an FFI::Struct |
| 22:17:24 | evan | and creates an LLVM::StructType for it |
| 22:17:34 | evan | but i wouldn't go much beyond that. |
| 22:17:41 | evan | "unifying" them isn't useful. |
| 22:17:52 | evan | and will just cause more grief than be helpful |
| 22:18:11 | devinus | rue: good idea, thanks |
| 22:18:32 | jvoorhis | evan: that's a good idea |
| 22:18:39 | jvoorhis | i'll play with it |
| 22:18:55 | evan | given the trivial nature of FFI::Struct |
| 22:18:58 | evan | that should be easy. |
| 22:19:10 | devinus | i'm sort of just a dabbler in the ruby scene, but rubinius excites me, and i keep coming back to check on the status. it looks freaking fantastic. i'm amazed that most packages are working out of the box for me |
| 22:19:26 | jvoorhis | evan: yeah, ffi's reflection is probably enough |
| 22:19:52 | devinus | has there been any talk of one day making rubinius the de-facto ruby? |
| 22:20:14 | devinus | (or i guess the community "blessed" ruby?) |
| 22:20:29 | rue | Only in the cabals |
| 22:20:47 | evan | devinus: we're amazed at how much runs on it too! |
| 22:21:06 | evan | hell, i'm amazed everytime eval is used and it actually does the right thing. |
| 22:21:11 | evan | so i'm easily amazed perhaps. |
| 22:21:43 | evan | having written Kernel#eval a couple of times though, you can understand my amazement :) |
| 22:22:12 | evan | devinus: talking about rbx being de-facto or such is, in my mind, outside the project itself |
| 22:22:17 | evan | if we make it kick enough ass |
| 22:22:26 | evan | then things will answer themselves. |
| 22:25:57 | devinus | evan: indeed, i love it. you've done some great work. the contributors too |
| 22:26:30 | slava | rubinius will kick major ass once evan completes The Plan(tm) |
| 22:26:44 | evan | haha |
| 22:26:51 | evan | is that like the cylon plan? |
| 22:27:50 | slava | its more like, you'll just keep plugging away at it, and eventually it will have every optimization |
| 22:28:09 | evan | yep. |
| 22:28:57 | slava | my new blog post has a summary of the internal ABI I use, if you're interested |
| 22:30:03 | evan | oh yes. |
| 22:30:05 | evan | url? |
| 22:30:13 | slava | http://factor-language.blogspot.com/2010/01/replacing-gnu-assembler-with-factor.html |
| 22:30:16 | evan | the one on assembler? |
| 22:30:17 | evan | gotcha |
| 22:34:41 | devinus | does rbx irb not read .irbrc? |
| 22:34:53 | devinus | i remember awhile back it did |
| 22:37:09 | evan | it reads it |
| 22:37:17 | devinus | okay |
| 22:40:59 | evan | slava: nice |
| 22:41:24 | evan | slava: something you didn't mention that I always think about is GC pointers in C++ frames |
| 22:49:33 | kronos_vano | evan, I couldn't tag tickets, because only owner and collabs cat do this :( My patches is #162, #163 and #165. |
| 22:49:51 | evan | k |
| 22:57:17 | slava | evan: well, it knows which frames are C++ frames and which ones are factor frmes |
| 22:57:31 | slava | to find roots in C++ frames, it looks at an stl vector of addresses |
| 22:57:36 | evan | yeah |
| 22:57:37 | evan | i know |
| 22:57:41 | evan | but the reader might not |
| 22:57:42 | evan | was my point. |
| 22:57:47 | slava | ah |
| 22:58:47 | slava | thanks for going over it |
| 22:58:52 | evan | np. |
| 22:58:56 | slava | did the calling convention make sense otherwise? |
| 22:58:58 | evan | sweet, i fixed a deopt bug. |
| 22:59:12 | evan | slava: i think so |
| 22:59:27 | slava | its got those funky pseudo-parameters for quotations and tail calls |
| 22:59:33 | evan | one thing that might make it clearer so to, at the boundary of factor and C++ |
| 22:59:37 | evan | make a diagram |
| 22:59:42 | evan | that shows what should be in each register |
| 22:59:45 | evan | and what should be on the stack |
| 23:00:01 | evan | those diagrams always help me when i'm looking at call convention stuff |
| 23:00:06 | slava | yeah |
| 23:03:10 | slava | I'm working on deopt right now too and plan on blogging about the impl |
| 23:06:48 | evan | oh? whats your plan? |
| 23:07:11 | slava | I just need to fix some bugs |
| 23:07:12 | evan | are you doing it because you want to inline words other than ones marked "; inline" ? |
| 23:07:33 | slava | no, either way its the same problem |
| 23:07:58 | slava | stuff gets redefined, has to recompile minimum amount of stuff in order to make everything work |
| 23:18:36 | evan | ah, gotcha. |
| 23:31:46 | evan | slava: what is in your code heap? |
| 23:32:05 | slava | blocks of native code |
| 23:32:30 | evan | well, sure, i mean, whats the form of them |
| 23:32:35 | slava | oh |
| 23:32:36 | evan | i assume they're structured in some way |
| 23:32:47 | slava | a header with a code_block struct |
| 23:32:52 | evan | some metadata around the machine code |
| 23:32:54 | slava | followed by machine code |
| 23:33:13 | evan | and it obviously doesn't compact |
| 23:33:16 | slava | metadata is a relocation table, parameter table, and a pointer back to the owner object whose compiled definition is this code block |
| 23:33:19 | slava | it does |
| 23:33:28 | evan | oh right, with reallocations |
| 23:33:50 | evan | ok, so the pointer back to the owner object |
| 23:33:51 | slava | code can get moved around, and it hasto update return addresses in the code heap as well as machine code itself |
| 23:34:06 | evan | does that mean that you run write barriers there? |
| 23:34:07 | slava | s/code heap/call stack/ |
| 23:34:28 | slava | evan: yes, either one of the owner object, relocation table or parameter table could point into young space |
| 23:34:46 | slava | and the code block's machine code itself could reference literals in young space |
| 23:34:54 | evan | so you update the card table for those? |
| 23:34:56 | slava | so there's a write barrier in the form of a remembered set |
| 23:34:59 | slava | nope, just an stl::set |
| 23:35:00 | evan | ah |
| 23:35:02 | evan | ok |
| 23:35:06 | slava | since its empty 99% of the time |
| 23:35:12 | evan | right |
| 23:35:15 | slava | when new code is compiled, the new blocks end up there |
| 23:35:20 | slava | and rapidly get cleared out after a few cycles |
| 23:35:26 | evan | right |
| 23:35:29 | evan | as things are promoted |
| 23:35:34 | evan | when do you run the GC on the code heap? |
| 23:35:49 | slava | I always collect the oldest generation of the data heap together with the code heap |
| 23:35:54 | slava | if one fills up, both are collected together |
| 23:36:10 | slava | this is because they reference each other circuarly and doing both at once is the only way to collect unreferenced cycles |
| 23:36:18 | slava | each word references its code block which references the word |
| 23:36:18 | evan | gotcha |
| 23:36:29 | evan | right |
| 23:36:35 | evan | also, not doing them both complicates the remember set |
| 23:36:36 | slava | so the mark stack during a full gc is a mix of data heap objects and code heap blocks |
| 23:36:44 | evan | and the idea is that you do both less often |
| 23:36:58 | evan | how often do you do a old gen collection+ |
| 23:36:59 | evan | ? |
| 23:37:11 | slava | whenever old gen or code heap fills up |
| 23:37:23 | evan | sure, i mean normally |
| 23:37:31 | slava | that's the only case |
| 23:37:37 | evan | every few seconds? if there is a lot of churn? |
| 23:37:42 | slava | oh |
| 23:37:51 | slava | no, much more rarely than that hopefully |
| 23:37:53 | evan | i just mean the observed time |
| 23:39:01 | slava | full collections are very rare because almost no object survive into tenured space |
| 23:39:24 | slava | the worst pathology I've seen is with the PEG library |
| 23:39:37 | slava | we have a javascript parsing bnechmark that spends 50% in GC |
| 23:39:52 | slava | and half of the GC time is 4 major collections |
| 23:40:00 | evan | aah |
| 23:40:03 | slava | but most things won't trigger it at all |
| 23:40:07 | evan | right |
| 23:40:20 | evan | someone wrote what they thought was an Array#<< benchmark |
| 23:40:26 | evan | but it was actually a GC benchmark |
| 23:40:31 | slava | why is that? |
| 23:40:41 | evan | it did, basically |
| 23:40:42 | evan | ary = [] |
| 23:40:56 | evan | 10_000_000.times { ary << Math::PI * 2 * 4 } |
| 23:41:13 | slava | so this boxes some floats and stores into the array on each iteration? |
| 23:41:17 | evan | actually, i think it was more than 10 million times |
| 23:41:19 | slava | and then every minor GC scans the whole array? |
| 23:41:30 | evan | yep. |
| 23:41:49 | slava | yeah, card marking fixes that and if you use float arrays there's no boxing at all |
| 23:42:12 | evan | of course it's different if I change the code :) |
| 23:42:19 | evan | but card marking wise, yes. |
| 23:42:38 | evan | i'm thinking about adding a seperate remember set for Tuples |
| 23:42:49 | slava | : foo ( -- ) 10,000,000 [ pi 2 * 4 * ] float-array{ } replicate-as drop ; |
| 23:42:54 | evan | where the address of the slot in the tuple is recorded |
| 23:42:55 | slava | 0.07 seconds |
| 23:42:58 | evan | rather than the address of the Tuple |
| 23:43:10 | evan | using a float-array is cheating. |
| 23:43:27 | slava | : foo ( -- ) 10,000,000 [ pi 2 * 4 * ] replicate drop ; |
| 23:43:31 | slava | 0.09 seconds |
| 23:43:54 | evan | nice |
| 23:43:59 | evan | you're using float boxing, right? |
| 23:44:05 | slava | in #2, yes |
| 23:44:12 | slava | #1 allocates no memory other than the float array at all |
| 23:44:31 | slava | actually, that's incorrect, in both cases pi 2 * 4 * is constant-folded down to a literal float |
| 23:44:34 | slava | there's no boxing in either case |
| 23:44:35 | evan | does replicate create a new array or just loop? |
| 23:44:52 | slava | it creates a new array calling the quotation to geerate each element |
| 23:45:00 | evan | how is there no boxing if you're creating an array with 10 million generic elements |
| 23:45:05 | slava | in this case it returns the same thing on each iteration, so it works like << in a loop |
| 23:45:05 | evan | you should have at least 10 million boxes |
| 23:45:26 | slava | each element points to the same boxed float, though, because of constant folding |
| 23:45:32 | slava | it computes 2*4*pi at compile time |
| 23:45:38 | slava | and saves the result as a single boxed float |
| 23:45:42 | evan | ok |
| 23:45:45 | evan | the real benchmark did |
| 23:45:46 | evan | ary = [] |
| 23:45:49 | evan | 10000.times do |
| 23:45:53 | evan | |i| |
| 23:45:58 | evan | 4000.times do |j| |
| 23:46:03 | evan | ary << Math::PI * i * j |
| 23:46:03 | evan | end |
| 23:46:04 | evan | end |
| 23:46:06 | evan | that might still fold |
| 23:46:09 | evan | but they'll all be different |
| 23:47:52 | slava | 40 million boxed floats? I'm running out of memory |
| 23:48:28 | slava | for 1000x1000, it takes 0.7 seconds |
| 23:49:06 | slava | 0.04 seconds with unboxed floats |
| 23:49:14 | slava | so once you're actually calculating, unboxing makes a bigger difference |
| 23:49:55 | evan | i'd like to compare apples to apples, so yeah, the unboxed array is cute, but not nearly the same |
| 23:50:01 | slava | 10,000x4000 is 0.5 seconds with unboxed floats, runs out of memory with boxed |
| 23:50:29 | slava | so a boxed float is 16 bytes |
| 23:50:34 | slava | plus 4 bytes for the reference |
| 23:50:52 | slava | so that benchmark needs 800mb of heap |
| 23:51:12 | evan | looks like the benchmark was 10000 * 400 |
| 23:51:41 | slava | ah |
| 23:51:44 | slava | and how fast does rubinius do it in? |
| 23:51:49 | slava | : foo ( -- ) 10,000 iota [ 400 iota [ * pi * ] with map ] map drop ; |
| 23:51:56 | slava | 0.5 seconds, with boxing etc |
| 23:52:31 | slava | 90% of that is GC |
| 23:53:04 | slava | yeah, much cuter with unboxing... |
| 23:53:44 | evan | lets see.. |
| 23:54:34 | evan | looks like 5.2s for rbx |
| 23:54:42 | slava | also 90% GC? |
| 23:54:52 | evan | actually, no, it's worse than that |
| 23:54:54 | evan | lets see. |
| 23:54:59 | maharg | hm. Is it still accurate that rubinius isn't thread safe due to borrowed MRI code as stated in the README? |
| 23:55:13 | evan | maharg: wow |
| 23:55:16 | evan | the readme says that? |
| 23:55:17 | evan | where? |
| 23:55:51 | maharg | 5. Goals, first point |
| 23:56:16 | evan | i.. dunno who wrote that |
| 23:56:20 | evan | it's entirely wrong. |
| 23:56:33 | maharg | heh. I thought it seemed unlikely. |
| 23:56:53 | evan | it's been threadsafe for years. |
| 23:56:57 | maharg | been a long time since I looked in on rubinius' progress, though. Come a long way. |
| 23:57:32 | slava | evan: what kind of time are you getting? |
| 23:57:43 | evan | looks like 8.2s |
| 23:58:02 | evan | just the one float * adds 3s |
| 23:58:08 | evan | i haven't done much to make those fast |
| 23:58:14 | evan | and boxless. |
| 23:58:19 | evan | on operations |