Peter Booth
4/23/2007 8:00:00 PM
Shot,
So far the discussion has been very rational and focused on technical
merits. It's also worth considering enlightened self-interest:
If you are planning on working in quantitative finance then you
should use C++ because that is the language of choice for
quantitative finance. If you expect to work in non-telecoms IT then
you should use Java because that will be more valuable.
If neither are issue you should certainly use Ruby because it will be
more productive - the time you spend tuning Ruby is probably less
than the time you would spend waiting around for C++ builds to finish
and chasing down pointer bugs and mysterious crashes. And if the time
isn't less it will at the very least be more fun!
-Peter
On Jan 19, 2007, at 1:17 PM, Shot (Piotr Szotkowski) wrote:
> Thanks a lot for your reply, Ryan!
>
> // Also, as to not pollute the list with separate mails: thanks to
> // everybody else who commented in this thread! I learned more in the
> // past two days than I hoped to learn 'till the end of January!
> // Unfortunately, it might mean I'll come back with more
> questions... ;)
>
> Ryan Davis:
>
>> On Jan 17, 2007, at 2:00 AM, Shot (Piotr Szotkowski) wrote:
>
>>> symbolic functional decomposition of FSMs for FPGA implementation
>
>> Some work has been done in this area to some extent. Check
>> out RHDL from Phil Tomson. I believe it is pure ruby only.
>
> Thanks, again! I'm already eager to drill into his Ruby-interpretation
> of an FSM, and it's not even weekend here yet... :)
>
>>> my gut feeling is that pure Ruby will end up
>>> being *way* too slow and memory-inefficient.
>
>> Gut feelings are often wrong. Especially in this arena.
>
> I hope this one is. Still, my supervisor's C++ classes are quite
> optimised, and it's not rare for a decomposition to run for two days
> straight; hopefully the benchmarks needed to prove the scientific
> value
> of my thesis are of the less-time-consuming kind.
>
>> You can also take advantage of very easy
>> parallelism available through systems like rinda.
>
> Thanks for pointing out Rinda, I'll definitely take a closer look.
> Unfortunately, decomposition is a highly iterative process, so I doubt
> it's at all paralellable (some parts of a single iteration might be,
> though).
>
>>> 2. Ruby with C extensions.
>
>> This is the approach I choose most of the time. Just Do It.
>
> I talked with my supervisor, and he said that if going with Ruby means
> I'll show up with anything that actually works even just a bit sooner,
> then he's all for it. :)
>
> Thanks a lot for pointers to rubyprof and zenprofiler!
>
> -- Shot, currently in the 'Ruby or Lua? Ruby or Lua?' mode...
> --
> I'm not much of a kernel hacker, but a quick (and not very efficient,
> granted) fix could be to make the offset an extern variable, yes?
> That would force the compiler to fall back on the basic "your gun,
> your foot, your choice" memory model. -- jtv, LKML
>
Peter Booth
peter_booth@mac.com
917 445 5663