|Perl: the Markov chain saw|
Re^2: compiling perl scripts aka why is perl not as fast as Cby nikosv (Hermit)
|on Mar 22, 2010 at 09:51 UTC||Need Help??|
I totally agree.
I don't think that there is a reason to write in C nowadays except in embedded systems where real time speed is crucial.C was being used because its structures map closely to the hardware.
Perl uses references which disallow pointer arithmetic or pointer de-referencing which of course are slower in operation than pointers, but at the same time you don't get involved with allocating and de-allocating memory or playing directly with the hardware generating sigfaults easily.
Other issues that arise from C's non-restriction and flexibility are security oriented such as buffer overflows and string formatting and that is a reason why "plug-ins" libraries like The Safe C Library were designed to patch/correct.
Actually quoting the Safe C String Library overt security goals "The API should be capable of tracking whether strings are "trusted", a la Perl's taint mode.";even they recognize Perl's value!
This kind of quest for speed would us lead back to assembly which is faster than C. The question is would you like to deal with assembly? as C is a higher level that assembly, Perl is higher level than C.
It' more a question of what you want to TRADE for speed. The industry is constantly trading speed for flexibility and safety. That is why the trend is oriented on Virtual Machines like Java Virtual Machine or the .NET CLR which are layers on top of the OS and protect you from those kind of issues.
But if one wanted to find out what could be done to bring Perl closer to C he could take a look at Why Not Translate Perl to C? by Mark-Jason Dominus.