10

I was reading this article. It has the following paragraph.

And did Scala turn out to be fast? Well, what’s your definition of fast? About as fast as Java. It doesn’t have to be as fast as C or Assembly. Python is not significantly faster than Ruby. We wanted to do more with fewer machines, taking better advantage of concurrency; we wanted it to be compiled so it’s not burning CPU doing the wrong stuff.

I am looking for the meaning of the last sentence. How will interpreted language make the CPU do "wrong" stuff ?

Mike Dunlavey
  • 12,815
  • 2
  • 35
  • 58
user2434
  • 1,277
  • 1
  • 12
  • 14
  • 3
    Calling anything that compiles to JVM byte code interpretted is a little bit liberal with the usage. – Rig Jun 12 '12 at 18:36

4 Answers4

47

If the code says

A = A + 1

compiled code does this

add A, 1

interpreted code does this (or some variation)

look up the location of A in the symbol table
find the value of A
see that 1 is a constant
get its value
add the value of A and the value of 1
look up the location of A in the symbol table
store the new value of A

get the idea?

Mike Dunlavey
  • 12,815
  • 2
  • 35
  • 58
  • 3
    Sometimes oversimplification really *does* make the picture clearer ;-) (just to be complete: many well-known interpreters optimize *some* of the steps away, so they are halfway between the two sample "implementations" here). – Joachim Sauer Jun 12 '12 at 09:23
  • 3
    @JoachimSauer: You're right of course. It's still hard to make an interpreter run with less than a factor of 10 speed penalty compared to compiled code. If the language is one that really spends all its time in subordinate compiled functions that have to be called anyway, like math libraries or I/O, the cost of interpreting is not a problem. – Mike Dunlavey Jun 12 '12 at 12:17
  • 1
    This is an amazing description – Jamie Taylor Jun 12 '12 at 12:55
13

we wanted it to be compiled so it’s not burning CPU doing the wrong stuff.

Sounds like they are referring to compiled vs interpreted. Most likely down to the whole story of Twitter moving background processing tasks to Scala (compiled) after initially developing in Ruby On Rails (interpreted).

An explanation of compiled vs interpreted code here.

With a compiled language, code you enter is reduced to a set of machine-specific instructions before being saved as an executable file. With interpreted languages, the code is saved in the same format that you entered. Compiled programs generally run faster than interpreted ones because interpreted programs must be reduced to machine instructions at runtime.

KrisG
  • 231
  • 1
  • 4
  • Happy to give you your first +1. Welcome to P.SE! – haylem Jun 12 '12 at 08:12
  • 4
    (Might be worth mentioning that Scala - as it's on the JVM - is technically only byte-compiled). – haylem Jun 12 '12 at 08:14
  • Didn't know Scala was JVM based. Meaning its probably JIT compiled. In which case, why didn't Twitter just move from Ruby on Rails to JRuby? You'd think that would be an easier migration with the benefit of compiled. – KrisG Jun 12 '12 at 08:16
  • 3
    They were also looking for better concurrency model and they had issues with Ruby's garbage collection. The article describes it in detail. – scrwtp Jun 12 '12 at 08:32
9

"Wrong stuff" here means the overhead it takes for the interpreter to parse and process the code. It's connected with the notion of interpreted vs compiled languages. There are several models of code translation in use, which roughly fall into one of following categories:

  • Native compilation - source code is directly compiled into machine code. Best performance at the expense of portability. Commonly associated with C and C++,
  • Intermediate compilation - source code is compiled into a simplified intermediary language (bytecode), which is later interpreted or compiled (just-in-time compilation) into machine code during execution. Better portability than native code, better performance than pure interpretation while retaining some of the upsides of interpretation (like late binding). Examples include C#, Java and other languages targeting JVM and .NET CLR,
  • Interpretation - source code isn't directly translated into machine code, instead it's interpreted and executed by a dedicated interpreter program. Interpreters vary in sophistication, in the naive implementation however it boils down to parsing, analyzing and executing source code line by line. Interpretation allows greater flexibility than compilation, hence interpreted languages make wider use of dynamic typing or reflection, for instance. Interpreted languages are often seen as offering increased developer productivity, as they require less boilerplate code and lent themselves nicely to rapid prototyping. Downside is reduced performance. Commonly associated with JavaScript, Ruby or Python.

Hence the choice between interpreted and compiled language boils down to the question, what do we value more, developer productivity or performance? The migration described in the article seems to follow the same line of thought, with strong prototyping language Ruby being replaced by JVM-based Scala due to performance considerations.

scrwtp
  • 4,532
  • 1
  • 24
  • 29
  • -1 the way the answer is worded, looks way too simplistic. It completely ignores stuff like JIT ([just-in-time compilation](http://en.wikipedia.org/wiki/Just-in-time_compilation "what's this?")) - which is by the way how Scala runs over JVM / CLR – gnat Jun 12 '12 at 12:39
  • True. Rewritten the answer, it was adding little to the topic as it were. – scrwtp Jun 12 '12 at 18:30
-3

In this case I have taken the wrong stuff to mean lack of type safety in non-compiled code.

Thus, not only is interpreted code slower, but it's also more buggy...

Neil Twist
  • 111
  • 8
    You are assuming that compiled languages are type safe and interpreted ones are not. There are many counter examples For example lisp can be compiled and is not strongly typed, while Haskell can be interpreted and is VERY type safe – Zachary K Jun 12 '12 at 11:13
  • 1
    Equating "not type safe" with "more buggy" is FUD pushed by people with products to sell. – user16764 Jun 12 '12 at 18:45
  • 1
    @user16764: It's not FUD if it's true. IME the people pushing nonsense on the subject to sell products are the ones who try to downplay the link between dynamic typing and errors. ("It's only *one type of error*," etc.) – Mason Wheeler Jun 12 '12 at 23:11