How can I convert Perl to C?

Question

Is there a tool available which will convert source code in Perl to source code in C? Any platform is fine.

Answer 1

There is perlcc which "translates" Perl to C.

It's not really a Perl to C compiler; its output is simply a bundle of the Perl interpreter and the parsed bytecode of your program.

Answer 2

The canonical answer to this is MJD's "Why Not Translate Perl to C?".

Answer 3

The answer is going to be pretty much "No". Perl is an extremely dynamic language. C is a language for statically-sized data types. Any translation of Perl to C will likely be pretty much "execute this subroutine call to simulate what Perl does" repeatedly. And there's little point in building such a translator, as it is unlikely to execute Perl much faster than Perl does.

Answer 4

I wrote a pretty large program in Perl that creates PDF based on HTML and database queries that is virtually acting like a browser. The total source code volume is over 1MB. The programs evaluates HTML, creates SQL queries and retrieves data, searches for images on disk or downloads them from HTTP servers, builds a document structure, does all the layout calculations and, finally, produces a PDF.

I had to find out how to speed up the operation in a number of ways. Based on that I state that Perl is quite fast, and many tasks completed swiftly and successfully in Perl take a long time in C, and even C++.

There are 2 ways to make Perl slow or memory consuming: a large number of complex data structures - they need a lot of memory - and a large number of calculations. Yes, calculation is indeed very slow in Perl. A simple term like

$a = $b * $c

is quite time consuming in Perl, but very quick in any compiled language. The operands here may even be integers, not floating point variables - it is slow. I guess this is the reason why Perl scores pretty bad in the language shootout contest [http://shootout.alioth.debian.org/](The Computer Language Benchmarks Game).

I found my pretty large program -it uses many Perl core and additional CPAN modules as well- to start quickly, despite being intepreted.

It performs very well... until it comes to the calculation of text sizes and layout coordinates. Thats very time consuming. After stating this, I wrote small Perl test programs just doing millions of arithmetic calculations and found them to be very slow.

Besides, I am using and object oriented approach to model each and every layout element. Each object is represented by a hash - thats at least about 10kBytes per object. If there is a large amount of data to print, a memory consumption of several 100MBytes is not unusual for that program.

So, I still have a good reason to move the part calculating the layout to C, using structs where I now have hashes with fixed keys and have C integer arithmetic where now Perl does a slow job.

But everything else was done and tested swiftly and runs so fast that I don't see any reason to change. I also find Perl code much more convenient to write and test than C code. And a lot of CPAN modules provide solutions you don't have to work out yourself. Many of them are well tested and documented.

After this quite lenghty dicussion I conclude: if it is to be a server or command line program, consider Perl. But if this program has to build up huge data structures or lots of arithmetics, consider something faster. Sometimes, it may be a Perl program with a module written in C.

Answer 5

There are Perl to C translators, but none are perfect. Ideally you'd want a translator that is both correct and elegant. Alas, you can't have both, simple Perl code isn't equivalent simple C code so you either have to have a translation that isn't 100% correct or is as complex as Perl itself. This has led some to believe you should not try to translate Perl. It would be more accurate to say that you need to be clear what you want to achieve from the translation, and not expect miracles.

100% Correct is easy: if your Perl script is myperl.pl then the C program void main(){system("perl myperl.pl")} will do exactly what myperl.pl will do; this is rather pointless though. The perlcc compiler is a little more sophisticated, but still doesn't seem to give much benefit. I haven't noticed perlcc being any faster than plain Perl. Also, while Perl code can be notoriously difficult to read, I prefer print "Hello World\n" to the 700 line long monstrosity that perlcc translates it into. I haven't seen these programs produce anything that would pass a code-review as well written elegant C code. OTOH, if you want a compiler because you don't want to distribute your source code in a non-obfuscated way, then perlcc could work wonders.

RPerl can achieve speed ups, but is very limited in what it can translate.

For an example of a trivial "elegant but not correct" translator, see the prototype perl2c++.pl. This works by replacing (a few) standard Perl-isms with C++-isms. C++ was chosen because it is a high-level language like Perl, but still shares the same bare-metal ethos of C.

In the case of a simple LCG Pseudo-Random number generator LCG.pl, the output of perl2c++.pl is clean and succinct C++ code that runs dozens of times faster than the original Perl and does not depend on any Perl libraries. It could be extended to look for all the standard answers to "How to do X on Perl", and replace it with "How to do X in C++". Then it might successfully translate many simple but real world Perl scripts, and help a human translate non-trivial Perl software into elegant C++ code. This would be most useful if you find yourself writing numerical software in Perl which should have been written in C++ in the first place.

For software for which Perl is well suited, but you just want to go a little faster, the JIT approach used by JavaScript (and ultimately Perl 6) is more promising.

Answer 6

The converter is called a programmer, and the conversion process programming. Seriously, the language proper of perl is so vast and powerful, that anyone attempting to write a converter would look down on a life-long task. Additionally, the effect in performance improvement might not be an order of magnitude, so why bother?