From: Ricardo Panaggio Date: 2010-07-17T23:35:40+09:00 Subject: [ruby-core:31330] Re: [rubysoc] Queue C-extension patch to come > Visual representation of your changes, commit and files > http://github.com/panaggio/ruby/compare/ruby:trunk...queue Thanks for the help Luis > Which static functions? It looks like everything you're using is public > api. Am I missing something? My mistake. Before working on that branch, I've started working in a toy port using mutext_t and a lot of statics from thread.c. As I've started working on that branch, I've decided to use the more non-statics I could. And now it seems I use little (maybe no) statics at all. Thanks Aaron to point it out. > It looks like this patch is just a port of the ruby code to C, but not > using a native queue system. As Caleb already said, afaik there's no native Queue system in pthreads or win32 threads, or related libraries. If there's any, I could > Can you show us benchmarks between this > version and the pure ruby implementation? Again, as Caleb said, C is much faster than Ruby, and for me that was ok to go just with that. But as asked, I'm working on benchmarking now. As soon as I have useful results, I'll show them. > Also, it looks like you're not tainting objects like the original Queue > class is. Again, my mistake. I'll get the code corrected, but "in the dark". I just didn't get why it's necessary, and maybe that's why I forgot it. Any one can give some help? Tainting is only use in Queue, which makes it more strange for me and more difficult to understand it. > Are there benchmarks showing that the Ruby code is so slow (in an > actual usage scenario) that a rewrite in C (which can�t be used by > JRuby and similar) really is needed? Ruby is used on a lot of different scenarios, for different purposes, with different interpreters, and a lot of other differences that I will just pass, as this is enough for my point. Working on something that would make everyone benefit is kind of the best way to do it, always. But sometimes, we can work for an specific (and my patch is not so specific as it may seem), and make it much better. It's difficult to show that my patch will make ruby 2x faster (but I'll try to show how faster it gets anyway). Specially when talking about an "actual usage scenario". There are a lot of uses for Queue, and without extensively testing it, I couldn't say that it's really faster, in any purpose. I see if there any benefit of accepting it (even if small), it would be of help, specially in a near future. There are plans for evolving Ruby threads, and as we get to stage 3, sync primitives will be an issue, I'm sure. If I can help now to make things better now, knowing that it'll be even better later, I just can't see why it's not good enough. If there's any other mistakes on the code, just let it come. As I'm already working on SizedQueue, anything found on Queue may affect it. And may affect the performance also. Again, thanks for all the help until now.