The compilation method is not the only thing that determines execution speed. I have extensive experience in another interpreted language, Forth, and it beats the pants off of anything but tightly written C code. This is not due the compilation method but in the minimalist implementation of the bytecode and the design of the programs. To get raw speed you give up runtime checking, floating point math, and garbage collection among other things. Not as a hard rule but these are design choices that you make. Just as these choices have to made when writing in any language. The important thing is whether the language allows these choices, and if the language doesn't do what you want you can usually do it in a library. So really, it makes little sense to even draw the distinction between languages.

Speed is not everything. As I'm writing this I'm looking at the process status of the many widgets sitting on my desktop. They are all running between 0% and 1% processor utilization. My whole Xorg desktop runs between 2% and 3%. So do I care what language they were written in? No.

I don't take it as a given that a C++ program runs faster that a perl program. Some of the slowest running junk that I've seen has been written in C++ using the MFC Classes. Again the determining factor is not the compilation method but the library implementation.

My next project involve numerical simulations using the ATLAS libraries. These libraries are written in Fortran, C and C++. The libraries do all the heavy work and the application code just shuffles the results over the the display libraries. ( Written in Python, I think. ) So the whole Perl vs X thing is moot. This project mirrors most of my big projects in that I rely on libraries to do the most of the work. So I really don't care what language I'm writing in just so long as it stays out of the way.