From: Jeff Mitchell <quixoticsycophant@...>
Date: 2004-06-09T07:44:30+09:00
Subject: Re: ruby and mustard


--- "Ara.T.Howard" <Ara.T.Howard@noaa.gov> wrote:
> 
>    * do it in another lang.  i really don't like this because of learning
>      curve and adding extra dependancies (ocamlc for eg.).
> 
>    * c++ is simply out.  ;-)
> 
>    * do it in pure c.  have you used getoptlong lately - sheesh.
> 
>    * do it using a nice library for c.  glib is good - lot's of bells.
>      extra dependancy though...
> 
> these are the options i've been mulling over.  lately, however, i'm starting
> to favour this option:
> 
>    * just code it in c using ruby's builtin libs.  gives you hashes, eval'ing
>      code, lists, GC, etc.  i'm not adding additional dependancies and
>      guarunteed (if my c stays pretty posix) that my code will run where ruby
>      will.  don't need autotools, no stl., etc. etc.
> 
> are there any other options i'm missing?
> 
> what do you do when it needs to be __really__ fast BUT you also have to
> develop it __really__ fast and would __prefer__ not to add dependancies.

Is it possible to somehow isolate the inner-loop functionality?  As long
as you can stay away from raw iterations of every data point -- calling only
row or column operations, for example -- you have a pretty good chance of
being fast enough.

Don't forget you can call any function in any shared library with ruby/dl,
including memcpy and so fourth.  Make some trivial extension classes which
simply hold raw chunks of data in a C array, or just pack strings.  You
can then pass this data to C lib functions or ruby extensions.



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/