Jürgen Strobel wrote: > On Mon, Aug 21, 2006 at 03:55:10PM +0900, MonkeeSage / gmail.com wrote: >> Ok, I need to preface this by saying that I'm in no way either a C or >> ruby guru, so I may have missed something here, but this is what I'm >> seeing. The bottle-neck here is in the printing to screen. >> >> I don't see how the OP got the code to run in 5 seconds while using any >> stdout writing function (e.g., printf). The program should print like 4 >> megs of text to the screen (though I couldn't get the C that was posted >> to compile--like I said, I'm no C superstar) -- there's no way that is >> happening in 5 seconds. > > First, stdout doesn't neccesarily write to your screen, and /dev/null > is very very fast. Even if writing to some kind of terminal emulator, > some of them are much faster with bulk output than others. Ok, fair enough. I made the assumption that the testing was done on a terminal emulator since the perl execution time was given as 12 minutes and the faster version of the ruby algorithm writing to a file rather than stdout took only 17 seconds, whereas it took 26 minutes writing to stdout--I assumed that the perl version would be comparable with file writing rather than writing to standard out. I used xterm. > All you did benchmark was that your terminal emulator (or whereever > your stdout goes to) is slow. Yes! That's exactly what I was trying to do! I was trying to show that writing to stdout (assuming a comparable context, like an xterm) is the bottle-neck of the ruby version here. Writing to a file was about 90 times faster. Like I said, I wasn't denying that C is faster; my point was this: the C version may only take 5 seconds to write to a *file*, but ruby only takes 17 seconds; and for me, as I'm sure for others, 12 seconds is not worth the effort of writing it in C. So the 12 minutes to 5 seconds comparison was flawed -- 17 seconds to 5 seconds is more accurate. Regards, Jordan -- Posted via http://www.ruby-forum.com/.