jerry_mcbride wrote: > My second suggestion... Use something other than PERL... PLEASE! The > interpreter overhead is horrendous! It pretty much eliminates using > slimserver on lowend hardware... especially if you toss the likes of > mysql into the picture... C would be heavenly...
Not to want to jump into a theological argument, because it flat out isn't going to happen. But what makes you think that the Perl overhead is significant in this usage? And how in the world would you suggest C as a replacement? While there is no argument that languages such as Java or Perl are not as fast as well optimized C or assembly for processor intensive usage, your statement appears to be based on a couple of faulty assumptions. First, Perl and Java are usually compiled into byte code that is peephole optimized using JIT techniques. The JIT optimizations are decent and get better all the time. While it is true that Intel developed the Itanium spec as a VLIW processor with the assumption that it would be far faster than X86 processors for applications developed in the late 1990s and beyond, the Itanium has not delivered, and sure isn't the basis for modern things like the AMD X2 or Intel Duo Core. Depending on the benchmark, the difference is really that that big a deal, maybe a factor of two or three, not the 30 to 100 times that statements such are yours seem to rely upon. I've done serious cryptography in Java (RSA, SHA, DES) and had it be within the above factor of two or three, and you can't get much more CPU bound than crypto. Secondly, SlimServer is an application that generates HTML displayed in a browser from data in a database or disk. It is not CPU bound at all. It is communication bound, it gets a little data, reformats it, spits it out to the browser, waits forever for a user response, gets a little data, reformats it, talks to the database... Repeat forever. Taking the SlimServer perl code, itself, to ZERO cpu usage is not going to have a big impact in throughput. As importantly, I can't see the point of your "low end" hardware idea. For years I ran SlimServer on a free computer. It was an ancient P3-500 that I had laying around unused in my basement. You can't get much lower end than that. It ran fine until the day when the CPU fan clogged with dust bunnies -- it was probably already five years old at the time. Perhaps our definitions of low end hardware are different. My definition is something like a TS-7250 from EmbeddedArm.com. Sells for under $200 quantity one retail. But the cost of a slimserver is not the CPU, its the disks and memory. But the reality is that unless someone completes a rewrite in [insert your favorite language here] the SlimServer is written in Perl and maintained and enhanced by software engineers who are comfortable, productive and experienced in perl. On your suggestion of C, I know C, I've written C professionally, and I prefer it over C++. I even am paying a professional software engineer to develop in C right now. But that is for an embedded application that has to run in 32KB of RAM. The SlimServer is developed with OO, you simply can't do that in C. Plus the SlimServer leverages a huge set of CPAN modules for things like MP3 file processing, directory structure recursion, HTML generation, international language support, etc. It is impossible to think about doing such a rich system in C with a handful of developers. I've toyed with the idea of making an equivalent "port" to Java. but haven't had the time to even get started. And as folks talk about a port, the product is being enhanced. Catching up is a real challenge, even if someone really wanted to re-implement it. No one has presented any reasons, other than theology, behind even suggesting a change. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
