[PLUG] Facebook & PHP - massive speedup

[Joe Shisei Niski]

On 02/03/2010 07:20 AM, Carlos Konstanski wrote:
> An interpreted language does all the work of translating the
> high-level, complex, abstract programming statements written in a
> human-readable language into machine code (the only kind of code a
> computer can_actually_  execute) at runtime, right when a result is
> needed. A compiled language translates the human-written source code
> into machine code beforehand, so that at runtime the computer can
> execute the ready-made machine code hell-bent-for-leather.
>
> There is an in-between compromise called bytecode. Languages like java
> and C# are not compiled into directly executable machine
> code. Instead, they are compiled into a form that is still interpreted
> at runtime, but it is highly optimized to interpret very
> quickly. These languages use a virtual machine, or "runtime", to
> "execute" the bytecode. What the runtime actually does is read
> segments of bytecode and compile them into real machine code on the
> fly, the results generally not being stored on disk. This is where we
> get the term "Just In Time Compilation", or JIT.
>
> An interpreted language will always run more slowly than a compiled
> language because of all the extra work that has to be done at
> runtime. There may be some oddball cases like TinyBasic, but we're
> talking about high-level application programming languages here.
>    

Lovely clear explanation, Carlos. The only thing i'd add is the 
relatively recent addition of support for typically interpreted 
languages (e.g., Python, Ruby) on both the Java Virtual Machine and the 
.NET Common Language Runtime. This approach is a great middle ground 
that provides the usability/development efficiency of higher-level 
"scripting" languages with the performance of bytecode compilation and 
the safety/security/sandboxing (somewhat debatable but generally better 
than the default interpreters) of the JVM and CLR. In larger 
enterprises, this approach also allows standard deployment and 
management (i.e. as .NET or Java EE applications) on existing server 
infrastructure - the operations teams don't need to deal with another 
platform, even though the application code is written in JRuby or Iron 
Python.

Given that CPU cycles are far cheaper than developers and operations 
staff, the productivity/performance tradeoff of higher-level languages 
is a no-brainer for most businesses.

BTW, your initial remark, "don't engineer your software better, instead 
make your crap execute faster. Oracle might be interested in this," had 
me laughing out loud.

Joe