From: Philip Rhoades Date: 2008-06-08T06:30:19+09:00 Subject: Re: RubyToC - Second Question Axel, Axel Etzold wrote: > -------- Original-Nachricht -------- >> Datum: Sat, 7 Jun 2008 22:14:13 +0900 Von: Philip Rhoades >> An: ruby-talk@ruby-lang.org Betreff: Re: >> RubyToC - Second Question > >> Axel, >> >> >> Axel Etzold wrote: >>> -------- Original-Nachricht -------- >>>> Datum: Sat, 7 Jun 2008 04:19:12 +0900 Von: Philip Rhoades >>>> An: ruby-talk@ruby-lang.org Betreff: Re: >>>> RubyToC - Second Question Ryan, >>>> >>>> >>>> Ryan Davis wrote: >>>>> On Jun 5, 2008, at 16:57 , Rob Biedenharn wrote: >>>>> >>>>>> Perhaps you want to check out treetop or one of the other >>>>>> parsers as this project looks like it hasn't been touched >>>>>> in 2 years. >>>>> it's been touched, but none of the changes have been >>>>> released. >>>>> >>>>> ruby2c has a lot of dark corners and isn't meant for general >>>>> use. expect a lot to break. >>>> The reason I am interested is that I have CPU and IO intensive >>>> C/C++ genetics simulation program that I would love to rewrite >>>> in Ruby but it probably would not be viable from a speed point >>>> of view. I thought maybe if I could develop/debug etc to a >>>> working Ruby app and then, when it is a going concern, turn it >>>> into a faster, compiled binary, I would get the best of both >>>> worlds . . >>>> >>>> Regards, >>>> >>>> Phil. >>>> >>>> -- Philip Rhoades >>>> >>>> Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275) GPO >>>> Box 3411 Sydney NSW 2001 Australia E-mail: phil@pricom.com.au >>> Philip, >>> >>> if you have a lot of C/C++ code and look for wrappers, you could >>> also try SWIG >>> >>> http://www.swig.org/Doc1.3/Ruby.html >>> >>> or the rbplusplus gem >>> >>> http://rubyforge.org/projects/rbplusplus/ >>> >>> There have been rumours on this list some time ago that SWIG >>> could also "wrap" Ruby into C, but I couldn't confirm this from >>> the docs. >>> >>> I think the rbplusplus gem is very comfortable, but it's still >>> work in progress ... 0.1.1 doesn't seem to support struct for >>> instance, but the last build from git does... >>> >>> What is it that's most time-consuming in your application ? >> > > Philip, > >> I am thinking about a complete rewrite (to better simulate the real >> world) but I would be quite unenthusiastic about doing it in C++ >> and also it would not help very much to be able to re-use parts of >> the existing stuff via swig or rb++. >> > > That sounds like you want to do some Ruby coding, just because it's > so elegant. Very nice :) Yes, as always with apps, the hindsight and other developments suggest improvements for a second version . . > But as Dave said in his post, as Ruby doesn't have a reputation as a > speed demon, you can throw out some computation-heavy things to > C/C++. In my case, it is hard to see how much would be left as Ruby . . > I was asking about what it is that takes the most time in your > program, because I suspect that you might be able to get to quick > results by reformulating the problem so that you can use Ruby > bindings for some numerical software ... like GSL or constraint > programming (gecode)... (which are implemented in C/C++/Fortran) and > then, you might not even have to bother about how to deal with C and > still have quick execution. Those things are interesting but unfortunately my stuff is sufficiently obscure and specific that I have to do the low level stuff - otherwise I would have used one of the existing simulation packages. >> What does '"wrap" Ruby into C' mean? > > Well, sort of writing Ruby and generate C from it using SWIG. What > Ruby2c promises to do. It doesn't seem to be possible. Bit sad, would have been nice . . >> A rewritten application would be quite different but the existing >> app has an array whose cells point to lists of parental and >> offspring objects that completely change with each generation. >> Output is continuously written to disk. >> > > There are also genetic algorithm projects for Ruby on Rubyforge. I > haven't tried any of them yet. Again, not something that is useful in my situation. >> I would love to produce a new version in Ruby because writing OO in >> Ruby is so much nicer but it would be just too slow and I am not >> really interested in writing parts of it in C/C++ . . defeating the >> purpose of rewriting really . . > > Well, if Ruby is slower in execution but quicker in writing, maybe > one can spend some time profiling how to prune the search space ... I think I might try and do some prototyping with v1.9 and see how it goes but I am actually supposed to be crunching and writing up results with the existing stuff . . Many thanks for the input though! Regards, Phil. -- Philip Rhoades Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275) GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil@pricom.com.au