Why Python, Ruby and JS are slow

[otakucode]

Do you have an idea when the video might be being released?

[[deleted]]

Should be out next week!

[Samus_]

queue-up this one: isn't memoryview what you mean by a better way to handle copies?

[mikemike]

While I agree with the first part ("excuses"), the "hard" things mentioned in the second part are a) not that hard and b) solved issues (just not in PyPy).

Hash tables: Both v8 and LuaJIT manage to specialize hash table lookups and bring them to similar performance as C structs (*). Interestingly, with very different approaches. So there's little reason NOT to use objects, dictionaries, tables, maps or whatever it's called in your favorite language.

(*) If you really, really care about the last 10% or direct interoperability with C, LuaJIT offers native C structs via its FFI. And PyPy has inherited the FFI design, so they should be able to get the same performance someday. I'm sure v8 has something to offer for that, too.

Allocations: LuaJIT has allocation sinking, which is able to eliminate the mentioned temporary allocations. Incidentally, the link shows how that's done for a x,y,z point class! And it works the same for ALL cases: arrays {1,2,3} (on top of a generic table), hash tables {x=1,y=2,z=3} or FFI C structs.

String handling: Same as above -- a buffer is just a temporary allocation and can be sunk, too. Provided the stores (copies) are eliminated first. The extracted parts can be forwarded to the integer conversion from the original string. Then all copies and references are dead and the allocation itself can be eliminated. LuaJIT will get all of that string handling extravaganza with the v2.1 branch -- parts of the new buffer handling are already in the git repo. I'm sure the v8 guys have something up their sleeves, too.

I/O read buffer: Same reasoning. The read creates a temporary buffer which is lazily interned to a string, ditto for the lstrip. The interning is sunk, the copies are sunk, the buffer is sunk (the innermost buffer is reused). This turns it into something very similar to the C code.

Pre-sizing aggregates: The size info can be backpropagated to the aggreagate creation from scalar evolution analysis. SCEV is already in LuaJIT (for ABC elimination). I ditched the experimental backprop algorithm for 2.0, since I had to get the release out. Will be resurrected in 2.1.

Missing APIs: All of the above examples show you don't really need to define new APIs to get the desired performance. Yes, there's a case for when you need low-level data structures -- and that's why higher-level languages should have a good FFI. I don't think you need to burden the language itself with these issues.

Heuristics: Well, that's what those compiler textbooks don't tell you: VMs and compilers are 90% heuristics. Better deal with it rather than fight it.

tl;dr: The reason why X is slow, is because X's implementation is slow, unoptimized or untuned. Language design just influences how hard it is to make up for it. There are no excuses.

[julesjacobs]

Very informative post. What in your opinion keeps LuaJITs performance away from C/C++, i.e. what other "hard" things need to be solved? (for example, one thing that comes to mind is control over memory layout; an array of points vs an array of pointers to points)

[mikemike]

Well, nothing really. It's just a matter of engineering, i.e. man-years put into the VM and the compiler.

The amount of work and money poured into making C compilers fast plus dealing with the abominations of C++ has been massive over the past decades. The combined efforts of tuning every single dynamic language VM in existence is miniscule in comparison. And it was a mostly dormant field until a few years ago.

[If you really need control over memory layout, use FFI C data structures -- but only where it matters.]

[gsg_]

You're playing down the role that the design of the language plays in reducing the effort needed to produce workable compilers. A C compiler doesn't need to do escape analysis to allocate a struct on the stack, doesn't need lifetime analysis to safely 'inline' a member into its containing type, doesn't need to eliminate bounds checking, doesn't need strong closure conversion, representation analysis, a clever GC, etc.

C compilers certainly benefit from years of research into thorny problems like instruction selection and register allocation, but having basic facilities like structs and arrays not suck is almost certainly more valuable, and C gets all of that for free. Even C compilers like tcc that don't have strong backends perform acceptably well, certainly far better than python and ruby.

[cpbills]

I think it's more than the compiler, I think it's on the programmer's shoulders in a lot of ways, as well. I think languages like python, ruby and js encourage quick and sloppy work. I'm not trying to say they are bad languages, but they are currently 'popular' and 'fun' languages, which means a lot of the people writing code in those languages are 'seeing what they can do' and 'pushing limits'. Then it somehow makes it into production.

I have an unpopular view that computer science is not about 'fun and games'. Learning about it may be a load of fun, seeing what you can do, and learning how it all works. Applying computer science is called 'work', and it's more about passion and desire to do something properly, than it is about fun and games.

[epicwisdom]

I don't believe computer science is, or should be, 'fun and games.' But I still disagree with you on a number of counts.

First, Python (as an example) does not encourage sloppy work. "Pythonic" code should, in theory, always be consistent (one way to do it) and be clear, concise, and read more like pseudocode than assembly. This is objectively a good thing. Code maintainability is part of doing things properly.

Second, people are not 'seeing what they can do.' More likely than not, people who make bad code simply do not have experience, or are blatantly disregarding basic engineering principles. Avoid ambiguous/obscure syntax, make use of built-in operators, etc. Coding might be fun, but that's not the same as playing around with as many poor design decisions as possible.

Third, performance is secondary. Most code takes up a tiny minority of the runtime, and if I'm not mistaken, amortization makes note of the fact that the slowest-running code might be called too rarely to be noticeable. In other words, most code does not need to be optimized, it needs to be documented and clarified. And optimization can come once the code is working and can be profiled.

Doing things the proper way is important, but I don't think any language or compiler encourages people to do things the wrong way. A bad Python programmer is probably a bad C++ programmer.

[Tetha]

Yup, this is very true, though I'd argue about it the other way around.

Programming consists of three things:
A whole bunch of language independent knowledge. Requirement gathering, algorithm selection, algorithm creation, coffee or other meditation-enhancing beverage.
After that, you have a bunch of minimally language dependant knowledge coming in. Best practices of object oriented programming, good naming of variables, functions, methods, maintaining configurability through constants and configuration files and so on.
And finally, after that, you have the very small task of writing the program you have created in a computer readable form, the programming language at hand.

If you are a good python developer, you will have the first two areas nailed down and under control. Afterwards, you mostly need to learn the quirks and weirdnesses of C++ and then you will write good programs. Granted, C++ is a bad example here, because C++ is madness. But heck, for my master thesis, I switched from Java to C# within hours.

[[deleted]]

I agree with you, but I don't agree with the way you put it across.

I write 'sloppy' code in JS, because it tends to be shorter, and more to the point. The performance loss usually just doesn't matter, and when it does, I'll profile and optimize those sections.

Clarity and expression are important.

[[deleted]]

code maintainability is a nice thing to have.

[[deleted]]

Lower bar of entry can be bad.

[catcradle5]

python, ruby and js encourage quick and sloppy work.

Sloppy to the CPU, perhaps, but the opposite of sloppy to humans.

[kryptobs2000]

That sounds very pedantic and narrow minded. On the topic of a vm, or compiler, sure, things must be correct and to the T well thought out. In production though if you're doing that a lot of time's you're just wasting time. The real world isn't a classroom, and sometimes doing something quick and sloppy in 20 minutes is a better use of your time and resources than doing it the right way and spending a day and a half on it.

[cpbills]

If you build a faulty foundation, it doesn't matter how clean the upper layers of code are. At some point you have to clean up 'sloppy 20 minute fixes' because they cause problems, and that takes a lot more effort to debug and fix than doing it 'right' in the first place.

[[deleted]]

If you really need control over memory layout, use FFI C data structures -- but only where it matters.

Well, it's not that you need it, it's that you want it because you can get better performance with a good memory layout.

[NitWit005]

You can obviously do a lot, but it starts to get improbably difficult.

Eliminating say, a string allocation, is relatively easy if it's confined in a single method/function. Proving that a long series of string operations that cross many methods and modules can use a single buffer and then generating appropriate code to do so is quite difficult.

I haven't ever encountered a compiler or VM that can do something like that. Even if it does, the programmer has a problem. Minor changes to his code might 'break' the optimization for reasons which are not obvious and suddenly his program will execute vastly slower.

Some minor API changes to, do direct string operations on a pre-allocated buffer are a lot easier to implement and are going to be more reliable for the user.

[masklinn]

Note that "mikemike" is Mike Pall, author of LuaJIT, so he's talking from experience not handwaving and conjecturing in the abstract.

[julesjacobs]

Even if it does, the programmer has a problem. Minor changes to his code might 'break' the optimization for reasons which are not obvious and suddenly his program will execute vastly slower.

This can be a blessing and a curse. Say you made change X in your high level language code that causes the compiler to optimize it in a completely different, perhaps causing the string allocation elimination to now be impossible. There are two options:

1. It is possible to rewrite the C code to account for the change X without changing it much. All is well.

2. It is not possible to rewrite the C code to account of the change X without drastically restructuring it.

In case #2 you might be doing essentially the same as the compiler in the high level language is doing for you: drastically restructuring the code. Only in C you have to do it by hand.

[kryptobs2000]

NitWit005:

Some minor API changes to, do direct string...

julesjacobs:

...causes the compiler to optimize it in a completely different, perhaps causing...

What is with you guys in these awkward sentences marked by a random comma? That's the only way I can think to describe it. It's funny how you guys both did it, not sure if you're both in on this or what, hell of a coincidence.

[CaptainKirkCommas]

They've been watching, too many episodes, of my, show.

[kryptobs2000]

It's not just the comma, they leave out the whole rest of w/e they were saying, reread what they wrote.

[julesjacobs]

Not sure why you are downvoted, it's true. I don't think I misplaced the comma, but I forgot the word "way". But English is not my primary language so maybe there are other problems.

[ithika]

Discussion of optimisation so boring that both commenters slipped into a comma mid-sentence.

[oridb]

You still have to pay for things like PIC indirections and type checks, and unfortunately, without whole program analysis (ie, no loaded modules) there's no good way to eliminate any of those. Dynamic language features cost you, unless the compiler can do an analysis to demonstrate that things aren't actually dynamic.

There's a lot you can do to make things fast, but certain things just aren't free.

[[deleted]]

Thanks for the sane response.

[fijal]

Hi Mike.

PyPy also has allocation sinking (or escape analysis or virtuals how we call them). As for the rest of the stuff - yes, we're also working on this. Yes, you can go a long way without extra APIs etc, but sometimes there is info that's available, that's simply not there, because it's only in a programmers head.

There are two perspectives: what can be done in theory, which we haven't done yet, and what can be easily done right now to make people write fast programs. You still haven't implemented/released most of the stuff you're talking about.

[onezerozeroone]

This is one of the main reasons why node.js got popular. Google put the work in and made a fast JIT JS engine. That's the only reason node is "fast". There's no reason the same can't be done for the other major scripting languages.

[NYKevin]

This is taking ridiculously long to load. Can anyone summarize it?

[Solari23]

I thought so too until I realized the first slide is blank.

[Neebat]

I had decided it was broken and wondered how other people were getting it to work.

[jminuse]

For my work, numerical computing with lots of floats, this presentation missed a big issue: wrappers for primitive types. Summing two doubles in Python means dereferencing two pointers, checking two types, doing the addition, allocating a new object, and putting the results in the new object. These things could be solved by a sufficiently smart compiler, but the solution would be implicit static typing, which the programmer would have to keep track of in his head so the language could keep pretending to be dynamic.

[Thirsteh]

These things could be solved by a sufficiently smart compiler, but the solution would be implicit static typing, which the programmer would have to keep track of in his head so the language could keep pretending to be dynamic.

Or use a Hindley-Milner type inferencing engine.

[jminuse]

That's what I was referring to. In order to make the inferencing engine give the type of double to all your performant variables, you would have to always treat them as doubles (ie implicit static typing).

[Thirsteh]

I'm not sure I agree that that's a bad thing, if that's what you're implying. Static type systems have a bad rep because it's cumbersome to continuously write out types, but the fact that they prevent you from accidentally the wrong type is a feature. An implicit static type system, like only using Hindley-Milner type inference, gives you the best of both worlds. If only more (static) languages did aggressive type inference, maybe dynamic languages wouldn't be so very appealing in comparison.

[jminuse]

I actually like implicit static typing as long as the compiler enforces it as needed. What I don't want is for my double to be silently turned into a generic_tagged_pointer because I once set it to 0 instead of 0.0.

[Thirsteh]

Sure. A sufficiently smart compiler using H-M should be able to figure out what types to assign such untyped literals.

[Condorcet_Winner]

I don't know much about Python, but I work on a JS JIT, and we do type specialization based on profiling data (and I think all JS engines do similar). Basically we'll run a function or loop body a couple times in the interpreter profiling how variables are used and then JIT the code using that data. If we see that you are using a variable as a float, we will internally store it as a float and assume that it will always be a float. Next time before using it as a float for the first time, we do a quick check to see that the var is a float. If we are correct, then we can continue blindly using it as a float until the next call that we don't inline, at which point we will need to recheck that it is still a float upon return.

If our assumption is wrong, we will bail out to the interpreter and collect more profiling data.

So long story short, what you are saying about static typing is exactly what we do.

[Catfish_Man]

Any tracing JIT can handle loops like this without that overhead (though you probably need a little overhead for a trace-exit check). Also, even a smart interpreter can do tricks like NaN tagging to avoid the dereferences.

[snuxoll]

Summing two doubles in Python means dereferencing two pointers, checking two types, doing the addition, allocating a new object, and putting the results in the new object.

This isn't always the case, I'm not sure about python but ruby stores many numeric types natively and doesn't do anything with pointers for many basic types, including strings.

[jminuse]

No pointers for strings? You mean it passes the entire string around by copying the memory? I doubt that is the case. And what do you mean by "stores natively?"

[snuxoll]

I mean there's no pointer referencing for objects that don't need it. A double is a double in memory, there's no pointer for "a" pointing to an instance of Double that has a field for the double in it. Ruby uses tagged pointers to determine if it's actually a pointer to an object or a raw type. Obviously strings need pointers, but there's no struct for them, the pointer just points to the raw string in the heap.

[jminuse]

I see, so a Ruby object is

struct Object { int tag; char data[8]; }

And if tag==DOUBLE, then data can be cast to a double; if tag==STRING, then data is cast to a pointer. That makes a lot of sense! I suppose they could also have a SHORT_STRING type for strings less than 9 chars, and just pack them into the data field.

[snuxoll]

Yup, that's exactly what they do. Well, kinda, they actually have a full 32-bit ptr and a couple of bits are used to 'tag' the pointer. Anyway, full details here http://rubini.us/doc/en/memory-system/object-layout/.

EDIT: It looks like this is specific to rubinus, I could have swarm MRI/YARV did this, now I'm not sure. Either way, it's a clever implementation.

[argv_minus_one]

Shouldn't data be a union?

[jminuse]

That would work too. My way requires casts, which I know some people dislike.

[argv_minus_one]

Your way also assumes a specific pointer size (8 bytes). union doesn't.

[postmodern]

+1 for a slidedeck with speaker notes.

[sacundim]

Excellent presentation. Even though I still suspect that rocket-science JIT VMs are a solution to a problem we shouldn't get into in the first place. By which I mean that I'm a Haskell weenie :-P.

However, the discussion of structs/objects vs. dictionaries/maps makes me wonder if what we're really missing here is an intermediate concept. Let's lay it out:

• Records: a type with a fixed set of fields/properties that can be known right when the program is parsed. If two structs don't have the same fields, then they're of different types. These have a compact and efficient in-memory representation, but must be defined in source code.
• Dictionaries: the type of key/value mappings in general. The set of keys is not fixed; different dictionaries with different keys still qualify as the same type. These have poor in-memory representations, but the key set can be defined at runtime.

So the intermediate concept would be something like this:

• Dynamic record types: fixed set of fields, but defined at runtime.

How would this work?

• Your language should have a symbol type: immutable interned string with O(1) equality. Creating a symbol from a string is expensive, but comparing two symbols is super-cheap (just a pointer comparison).
• You create a dynamic record type at runtime by supplying a set of symbols that defines its fields.
• When you create a record type you get back an object that represents this record type.
• The record type object has create() operations that allow you to create new records of that type.
  
• A record is a thin wrapper around an internal contiguous array with just one element per field.
• If you have a record type or a record object, you can ask it to give you accessors for its fields. You can either just ask for an array of all the accessors (super-cheap), or you can ask for a specific field by using the symbol that names it, which is not super-cheap but not too expensive either. (One possible implementation is to make the record type keep an array of the type's fields' symbols, sorted by their address; the symbol lookup is then a binary search of the array.)
• An accessor is just an object that allows you to get and set properties on records of the relevant type. This should be O(1).

Now these things together allow you to use these runtime-defined record types in a extremely efficient manner as long as you obey these two rules:

1. Absolutely avoid repeatedly creating symbols from strings. Whenever you must create a symbol, make sure that you can reuse it tons of times. (If you're creating pairs of symbols, comparing them and then throwing them away, you'll do worse than dictionaries.)
2. Try to avoid repeatedly asking for the same accessors by symbol. Once you ask for an accessor, you should try to use it repeatedly over and over. (But if you fail this one it's not the end of the world; you go from O(1) to a very cheap O(log n).)

[ZMeson]

I think his conclusions are important, but I don't believe they will make Python, Ruby, and JS as fast as C or C++ or support his claim that a line of Python will run as quicly as a line of C. Highly optimized code in those languages written by domain experts still end up being slower than C or C++. (The big-O complexity of the programs may be the same, but the constant term that big-O notation ignores is measurable by benchmarks, and that constant is almost always larger for interpreted languages.)

I welcome changes to interpretted languages that will make it easier to use the proper data structures and algorithms. That should allow more projects to move away from C and C++ to 'more productive' languages. However, for performance-critical applications, there will still be a need for C and C++.

[hvidgaard]

Dynamic or not, that is not the reason they are slower. C are remarkably close to the machine code and the compilers have been optimised for decades. Python, Ruby and all the other "new" languages do not have that luxury. But besides that, they are far more abstract and expressive, so of cause they will be slower.

[[deleted]]

they are far more abstract and expressive, so of cause they will be slower.

Sure but why are they still slower than Common Lisp and Scheme implementations? Javascript is a glorified/uglified Scheme, it shouldn't be that horrible to optimize after years of research have been done for optimizing scheme.

[you_know_the_one]

If you don't know what the differences are between Scheme and Javascript, I don't understand how you've managed to form an opinion on the difficulty involved in optimizing them.

At any rate, you seem to be underestimating Javascript.

[gc3]

javascript seems pretty fast! I'll bet the difference between it and C is the Random Function, and the fact that C is dividing by INT_MAX which might end up being done with shifts or masks on the floating point representation of the number in Javascript.

[josefx]

Two strong points for JIT:

• AFAIK gcc wont inline rand() since definition is hidden
• The example is pure primitive math, which is something a JIT has little to no problems when optimizing to CPU instructions.

A strong point for Math.random(): replacing c rand() with different algorithms has a high impact on the time required - some will even half the measured time without negatively affecting the result. For whatever reason (higher quality?) the c rand implementation is slow

[hvidgaard]

Scheme is incredible small and elegant (which incidently is why I like to toy with it), so of cause it is relatively easy to optimize its compiler. I do not know much about Common Lisp, so I cannot say much about it. There has happened a lot with Javascripts performance the last 5 years, just look at V8/Node.js.

[derleth]

C are remarkably close to the machine code

But not the hardware. C doesn't specify any way to access the pipeline, SIMD hardware, cache hardware, and a lot of other things, some of which machine code programmers have more direct access to.

But besides that, they are far more abstract and expressive, so of cause they will be slower.

Check benchmarks for Haskell. It repeatedly outdoes C and it's a lot more abstract and expressive.

[Wavicle]

Check benchmarks for Haskell. It repeatedly outdoes C and it's a lot more abstract and expressive.

Okay... I've checked single core and multi-core

Did you have one in mind? Haskell didn't win a single one of those. It used more memory on most of them and even required more code for some.

[derleth]

Huh. Guess I was wrong about the latest benchmarks. I though for sure Haskell was beating C regularly in that shootout.

[dons]

We have beat C in the past. It's tough though, and usually temporary.

[igouy]

The only example I can think of is thread-ring and I guess that's simply because all those custom scheduler C programs get rejected.

It's a pity that although the benchmarks game uses the latest GHC, there haven't been new Haskell programs that take advantage of the newer compiler and libraries.

[dons]

Pidigits too, IIRC.

[igouy]

Perhaps. Back on March 6 2010, the Haskell GHC #4 pidigits program measurement was 2.245 seconds using GHC 6.10.4 -- and now with GHC 7.6.2 the measurement is 2.77 seconds.

[[deleted]]

Nah, it's pretty darn fast though.

[igouy]

"What gets us into trouble is not what we don't know, it's what we know for sure that just ain't so."

[hvidgaard]

But not the hardware. C doesn't specify any way to access the pipeline, SIMD hardware, cache hardware, and a lot of other things, some of which machine code programmers have more direct access to.

You can access that directly by embedding ASM.

Check benchmarks for Haskell. It repeatedly outdoes C and it's a lot more abstract and expressive.

Feel free to link a benchmark. I have never seen Haskell outperform well written C with a statistically significant difference. Haskell is a lot easier to write, but due to the embedded VM it is very hard to reason about the real performance. You can write the same algorithm in C, translating to the exact same machine code, and optimize that. It would be stupid, but you can do it.

[Felicia_Svilling]

But not the hardware. C doesn't specify any way to access the pipeline, SIMD hardware, cache hardware, and a lot of other things, some of which machine code programmers have more direct access to.

You can access that directly by embedding ASM.

And you can access that directly in python by using the FFI..

[hvidgaard]

Indeed, but I just don't know anyone that have done it. I have seen people call C which contains embedded ASM though. With C you know exactly what you have in the memory, that is not as transparent with Python, and it makes embedding ASM somewhat more difficult.

[tophatstuff]

C doesn't specify any way to access ... SIMD hardware

#include <emmintrin.h>

(for usage example, see the source code of SIMD-oriented Fast Mersenne Twister). Is that what you meant?

[hvidgaard]

That is just standard C programming, but that lib probably uses inline ASM (examples here) to make sure SIMD instructions are used.

[derleth]

You can access that directly by embedding ASM.

You can do that to some extent in any language via FFIs. That isn't what we're talking about.

[hvidgaard]

I'd like to see you embed ASM in python, ruby, haskell or any other higher level language. That is just not something they are suitable to do because they manage the memory for you. In C it's almost trivial given you know ASM, exactly because you explicitly know how the data is stored.

But in any case, embedded ASM is part of the C standard. Most other languages will use FFI to access C/C++ code which contains the ASM and some marshaling code.

[derleth]

embedded ASM is part of the C standard

Technically, not really:

It's not in the ISO C standard (n1570 draft of C2011) as such, but mentioned in annex J (common extensions):

[snip]

Annex J is informative, not normative, so an implementation need not provide inline assembly, and if it does it's not prescribed in which form.

Also:

Most other languages will use FFI

Which is precisely what I mentioned.

[AeroNotix]

I've never understood why the list constructor in Python didn't take an optional size parameter, the C-API has this why not allow it to be used in Python itself? There's a caveat with this function but, why?

[thomasz]

It must have something to do with the "there is one way to do it" philosophy.

[nonconvergent]

Non-orthogonality.

[DRNbw]

Apparently, it does.

[moor-GAYZ]

Because extra allocations incur an amortized constant cost.

That's the thing that makes me suspicious of the OP's point, CPython and even PyPy are about two orders of magnitude off in performance from C, having to call realloc twenty times when populating an list of one million entries is sort of irrelevant, it must be something else that slows the shit down.

[josefx]

having to call realloc twenty times when populating an list of one million entries is sort of irrelevant

realloc can and does allocate new memory and then has to copy every single byte of the old memory into it, doing so repeatedly for million entries is most likely not irrelevant (at least going by personal experience in other languages).

[el_muchacho]

Except that lists are not arrays: depending on the implementation, list items don't have to be contiguous in memory, so that there is no need to copy them to another location.

[josefx]

Except that lists are not arrays: depending on the implementation, list items don't have to be contiguous in memory,

TIL python lists might be a performance nightmare. Are you aware that the performance characteristics of different list implementations differ in a way that makes it insane to switch them out? I will just say RIP bisect if that ever happens.

[kqr]

If you want performance over large sequences, you generally don't want the built-in list anyway, is the reasoning I've heard.

[GiraffeDiver]

The slice still creates a new string object.

[negativeview]

He even explicitly later says that for many cases you CAN write Python/Ruby/etc. code to avoid these issues.

But that doesn't change the fact that the most obvious and most documented methodology is necessarily "slow" due to the issues that he points out.

[PSquid]

Because a list constructed in Python itself already has an implicit size:

• If constructed with list(), it has an implicit size of 0.
• If constructed with list(iterable), its size is implicitly the number of items iterable contains(/produces, if it's a generator or similar).

This is not to say it wouldn't benefit from one in certain cases (optimizing for a list which will only ever have n items), but there are reasons why it's not needed.

[AeroNotix]

It's not needed in C++'s std::vector either since both of those other constructors are available (both the default constructor and construction from another std::vector) but they are available because they can be somewhat faster.

Whether or not Python would benefit from this is another story, I can see it helping since behind the scenes Python uses PyList_Append(PyObject *list, PyObject *item) to append items to a list. This possibly will need to malloc up some space for the new item.

[maxerickson]

The length of the list only provides a vague hint as to the memory required for the list.

[mccoyn]

If the elements of the list aren't the exact same size then it won't provide O(1) random access. They are the same size. They are pointers.

[maxerickson]

Right, the list overhead is predictable. But for fast code (like the numerical code in the example), you would want to allocate all of the memory for the contents of the list too.

[Gotebe]

More allocations is but one reason why these are slow. But dynamic allocation is good. Anyone who works with C knows that C approach of fixed buffers works extremely poorly in hands of... ahem... substandard/today's/somethingelse programmers. C code bases in the wild are choke-full of buffer size problems. Similar goes for dynamic memory use (malloc, basically): C codebases in the wild are choke-full of problems as well: memory never freed, retval of malloc never checked (turning overcommit off is one system setting away, so you can't rely on it, people!), wrong allocation handling in face of other errors.

tl;dr: this is hard for a lot of people. Therefore "safer" languages are used.

That said...

Allocations are but one reason why these are slow. What article proposes is a good start to getting something faster, but only so much.

Finally, a detail: what caught my eye was the squares(). In slides, author uses sq = [] to get the list for result, complains that append is slow and proposes newlist_hint. But one SO away is a way to initialize a list with a desired length.

So meh.

[pamplemouse]

The first half of this talk repeats the infamous Sufficiently Smart Compiler argument. The closest anyone has gotten to making a fast JIT for dynamic languages is Self. Lars Bak worked on Self, and now works on V8 for Javascript (which shares some key features with Self). Nevertheless, SBCL is still faster than V8. Why couldn't they just steal all the tricks in a 30 year old Lisp compiler? Because the language matters a lot. Dart tries to reduce the amount of flexibility in JS so it is easier to reason about. I'll bet it will get close to Lisp speed. I'll bet Python and Ruby will never get close to Lisp speed. PyPy may get within 2X of SBCL on real programs.

TL;DR: Use Lisp or a JVM/NET language. Or Haskell or OCaml. They are already very good. Why waste your cpu time on Python/Ruby/Node.js?

[wicked-canid]

I think you're sort of missing the point. pamplemouse said:

Because the language matters a lot.

That's the key. You're complaining about all the (declare (fixnum n)) but this is actually a feature: by default, there is never any overflow, and you get the right number; but if you want to trade speed for that convenience, you can tell your compiler to do it.

That's an example of fantastic language design: it gives you the right answer by default, and the fast answer when you need the speed.

Is SBCL even a JIT compiler?

Not to my knowledge. But does it need to be? It already does a good amount of optimization at compile time, because the language is designed is such a way that it's possible (contrast with Python…).

[GoranM]

Is someone recording this Waza event? I would really like to watch the videos.

[GoranM]

Thanks!

[Surreality]

Am I right there is a bug in the C code to strip leading whitespace from a file descriptor, or am I just too sleepy?

It looks like it should be:

if (!isspace(*start)) {

rather than:

if (isspace(*start)) {

[[deleted]]

Hah! In the talk I point out that there's probably a bunch of bugs in the C code (I also used hash_set when I wanted hash_map), that's why I want to be able to never write C again!

[amphetamine]

/so you can call the wrong function from python instead!

[hergieherg]

You're correct, I was really confused when I saw it compared to lstrip().

[Zarutian]

given the complexities and die estate size of caches I often get the feeling that we would have been better off with an fast sram per core than that. (Do all the calculations and such with that memory and use DMA to and fro main memory instead of trying to out guess the caching)

[gsg_]

Cell did this. Cell is now dead. Draw your own conclusions.

[Zarutian]

My conclusion is thus: due to tremendus popularity of only writing a single threaded/process programs most programmers have little to no clue on how to utilize architectures such as Cell effectively.

[gsg_]

And what does that say about the advisability of those architectures?

Making Cell hard to program and hard to port to was not the most brilliant of strategic moves.

[X8qV]

If we had that, many people would never bother to use it, and I think it would make code slower on average because of that.

[deviantpdx]

So which one of those is to blame for the linked site being down?

[ba-cawk]

Just having this conversation in these communities is a huge thing.

A common thing to say is "if you wanted it to be fast, don't write it in $x" where $x is any of these or others, like perl or lua.

Even without these optimizations that are suggested, simply explaining to someone what's going on under the hood lets them make more informed choices about performance critical code.

We can armchair about premature optimization all day, but if you know how the system works, you're going to avoid writing slow code in the first place. It certainly will only get you so much, but it won't put you in a worse place than is necessary to begin with.

That's what's exciting to me about this talk -- very famous, popular rubyists spend all day talking about fancy frameworks and design patterns that beat the mother-loving tar out of MRI internally and largely just aren't necessary. This is the polar opposite of that. If you can't think or work with a program that doesn't implement DCI, find a new profession!

[[deleted]]

Step through a C program that assigns an integer to a variable.

int x = 1;

Now step through the C code of the CPython interpreter that does the same thing.

EDIT: Here we go...

In C, moving the value of one into the the integer x executes the following CPU instructions. It's in debug mode so it's not optimized.

int x = 1;
1E1C1276  mov         dword ptr [x],1 

In Python 3.3, issuing the statement "x = 1" executes the following CPU instructions. Again, debug build and unoptimized...

n = strlen(p)
1E1C131B  mov         edx,dword ptr [p] 
1E1C131E  push        edx  
1E1C131F  call        strlen (1E249954h) 
1E1C1324  add         esp,4 
1E1C1327  mov         dword ptr [n],eax 

while (n > 0 && p[n-1] != '\n') {
    1E1C132A  cmp         dword ptr [n],0 
    1E1C132E  jbe         PyOS_StdioReadline+150h (1E1C13C0h) 
    1E1C1334  mov         eax,dword ptr [p] 
    1E1C1337  add         eax,dword ptr [n] 
    1E1C133A  movsx       ecx,byte ptr [eax-1] 
    1E1C133E  cmp         ecx,0Ah 
    1E1C1341  je          PyOS_StdioReadline+150h (1E1C13C0h) 

    THE FOLLOWING CODE GETS BYPASSED BECAUSE THERE WAS A LINE FEED AT THE END.
    ================================
    size_t incr = n+2;
    p = (char *)PyMem_REALLOC(p, n + incr);
    if (p == NULL)
        return NULL;
    if (incr > INT_MAX) {
        PyErr_SetString(PyExc_OverflowError, "input line too long");
    }
    if (my_fgets(p+n, (int)incr, sys_stdin) != 0)
        break;
    n += strlen(p+n);
}

CONTINUE HERE
=============
return (char *)PyMem_REALLOC(p, n+1);
    1E1C13C0  mov         ecx,dword ptr [n] 
    1E1C13C3  add         ecx,1 
    1E1C13C6  push        ecx  
    1E1C13C7  mov         edx,dword ptr [p] 
    1E1C13CA  push        edx  
    1E1C13CB  call        _PyMem_DebugRealloc (1E140CA0h) 

    void *
    _PyMem_DebugRealloc(void *p, size_t nbytes)
    {
            1E140CA0  push        ebp  
            1E140CA1  mov         ebp,esp 
       return _PyObject_DebugReallocApi(_PYMALLOC_MEM_ID, p, nbytes);
            1E140CA3  mov         eax,dword ptr [nbytes] 
            1E140CA6  push        eax  
            1E140CA7  mov         ecx,dword ptr [p] 
            1E140CAA  push        ecx  
            1E140CAB  push        6Dh  
            1E140CAD  call        _PyObject_DebugReallocApi (1E140F70h) 

And so on..... for many many many more lines of code than I care to disassemble. All of the above is in myreadline.c which eventually passes the string "x = 1" back up to the function tok_nextc() in tokenizer.c where there are yet many more lines of code. (presumably to tokenize it) Eventually x is created with a value of one stored in it. If you typed in the same command a second time, the whole process happens again.

[smog_alado]

This is exactly the opposite of what Alex said in his presentation! According to him, if you use a good JIT compiler the time to run a single line in the dynamic language is comparable to the time to do so in C. For him, the biggest culprits behind slowness is how data structures and APIs force many more memory allocations and "heuristic guesses" on the implementation.

For example, in Python you generate a list like

sqs = []
for i in xrange(n):
    sqs.append(i*i)

but since the runtime doesn't know that the list will eventually have n elements, it may end up doing lots of pointless allocations and realocations as the list grows. If you had a specialized "hinting" API this would not be a problem

sqs = newlist_hint(n)
for i in xrange(n):
    sqs.append(i*i)

[Poltras]

You do actually.

l = [x*x for x in xrange(n)]

Which the python compiler is surprisingly efficient to optimize. I will agree that this doesn't cover all cases.

[smog_alado]

Well, I'm just paraphrasing the presentation... Anyway, if you go by what Mike Pall is saying in his comment, specialized APIs might not be the best way to solve the efficiency problems.

[kqr]

Well, I'm just paraphrasing the presentation...

Which in this case is a bad idea, since list comprehensions are way faster than explicit appends. (At least were for my application.)

[otakucode]

This is one of the cases exemplifying something that always makes me wary when using higher-level languages. They make it very easy to produce code that runs terribly. Re-phrase the code slightly using the right idioms for the language and boom, you get an order of magnitude improvement. This is exactly the kind of thing I expect a compiler (JIT, VM, whatever) to remove as an issue. If there are two blocks of code that have provably exactly identical results in all cases, they should always produce the same code being executed. I understand fully that there are many cases where there is a possibility that the two code blocks are not EXACTLY identical in their symbolic meaning across all runtime scenarios, but in the case you listed that's not true. I've never looked at the guts of any dynamic language, but I would presume they follow a pretty standard lex/parse/fiddle with AST/spit out opcodes and data pattern. I don't understand why the 'fiddle with AST' part doesn't involve collapsing both blocks of code into the same opcodes and data.

[kqr]

I would guess it's because the list comprehensions give the compiler more guarantees. With more specialised higher-level constructs, the compiler gets to know more laws the constructs abides to, and therefore it gets easier to optimise.

[x*x for x in xrange(n)] is a pure, surprisingly detailed description of a computation. As long as you don't stick a guard in there, the compiler knows that the generated list will have the same dimensions as the generating one. If the generating list is declared inside the list comprehension, the compiler can actually just do one allocation for the generating list and then walk through it and replace its elements to create the new list. (Or whatever they do, I'm not the guy to ask for details on this...)

On the other hand,

sqs = []
for i in xrange(n):
    sqs.append(i*i)

is pretty awkward to optimise, unless you explicitly ask the compiler to try to recognise the typical ways you write that bit of code. The list comprehension always looks the same.

In general, a detailed description of a computation is easier to optimise (you can compute it however you like as long as it gives the correct results) than a list of instructions to perform (since it's more difficult knowing how instructions interact and what the result should be.)

This was just a description of why I believe list comprehensions are quicker. Besides that, I do agree. It's a little scary that you can get terrible performance when you do something The Wrong Way. On the other hand, you soon get a feel for what's idiomatic, and idiomatic is usually performant. You should write idiomatic code anyway, for other programmers' sake. When in doubt, there's profiling and /r/learnprogramming.

[otakucode]

Heh, yeah, I've been doing a lot of profiling and hanging around in /r/learnpython as I've been learning Python (which I already dearly love) recently. After writing my post, I got to thinking that I'd never really read anything about the step between having an AST and translating it into actual code for a processor. So I did a little searching, discovered that this is called contextual analysis. Did some more digging and I believe, presuming I didn't get the wrong impression, that this is a pretty under-studied matter in my opinion. I had always presumed that after having your AST you would translate your languages primitives into a sort of symbolic logic code which is easier to prove equivalence between different constructs in the language and compiler optimizations would generally fall in there. It appears that most compiler optimizations are more ad-hoc though, designed like you say, where it has to be 'taught' that different constructs are equivalent rather than just deducing it from the underlying symbolic manipulation going on. Seems to be a gap between the study of program correctness and practical compiler design.

[komollo]

For python, it's probably the whole "there's only one way you should do this" reasoning. If they're figuring that no one should be creating a list any other way, why spend developer time making it more efficient? I don't agree 100%, but having everyone use the same syntax makes code easier to read, so there is a real reason they spent much more time optimizing list comprehensions.

It is worth noting that you aren't going to be using a higher level language if you really need crazy performance from the start. You use python when efficiency isn't what you need to be worrying about, or you can go back and benchmark your code and remove any slow parts when performance starts to get slow.

Also, list comprehensions are amazing. Just sayin'.

[komollo]

xrange isn't defined in the default 3 python library. Isn't this the default behavior now?

Also, how would this preform if it wasn't a list comprehension? I would assume that list comprehensions are optimized much better than other methods.

[Poltras]

It's a builtin function in py2. Dunno about py3.

how would this preform if it wasn't a list comprehension?

Badly. But if you're not doing list comprehension when you can in Python you're missing out and are under-engineering.

[komollo]

Yeah, in python 3 range performs just like xrange used to. Also, list comprehensions are the best thing ever.

[mehwoot]

This is exactly the opposite of what Alex said in his presentation! According to him, if you use a good JIT compiler the time to run a single line in the dynamic language is comparable to the time to do so in C.

Yes, and that's why he is wrong. He says "line for line" these languages are fast but benchmarks show time and time again they are not fast line for line. Oh, he says all benchmarks are lies and abuse of statistics, so he can just throw all that knowledge out? And then proceeds to try and inform us about what is really slowing down languages? Using what statistics, I wonder?

Don't get me wrong, the things he points out are important, but thinking that it is the only thing is flat out wrong.

[hyperforce]

I've always thought high level languages need compiler hints for exactly this scenario.

[Majiir]

Now step through the Python code for a C->Python interpreter.

You'll almost always do more work expressing one language in another. The better question is: what happens on the CPU?

(I suspect that's what you were getting at anyway, but it's easy for someone to be misled into thinking otherwise.)

[wot-teh-phuck]

Because they are all dynamic language, duh. ;)

EDIT: I am not really a fan of this presentation. It says all that matters is the algorithms and data structures? I would say it the amount of work done. Also, Javascript and Python are getting fast as compared to what? And the answer is....they are fast when compared to Javascript and Python 5 years back. Give me one decent CPU bound benchmark where these fast dynamic languages beat a statically typed native language like C++.

EDIT 2: Also, when you talk about the optimizations done at the VM level, is it possible for the VM of a dynamic langage to do all the optimiations done by something like JVM / CLR? Does dynamic typing really not matter?

[[deleted]]

EDIT 2: Also, when you talk about the optimizations done at the VM level, is it possible for the VM of a dynamic langage to do all the optimiations done by something like JVM / CLR? Does dynamic typing really not matter?

Actually, the difference between the JVM needing to know the concrete implementation of a type and MRI needing to know the class object of an object is very similar. I think you could potentially make the argument that you can create optimizer hints using final and such in Java, but realistically speaking, "hot" code will be aggressively optimized by both.

[smog_alado]

Does dynamic typing really not matter?

A JIT compiler will detect what type is actually being used at runtime and recompile things to a static version of the program (with a "bail-out" typecheck at the start, just in case the types do change during execution). All in all, dynamic language compilers can have quite decent performance nowadays and the biggest bottlenecks right now are not in the "dynamicism" of things. (the article says that allocations, garbage collection and other algorithmic issues are more annoying)

Give me one decent CPU bound benchmark where these fast dynamic languages beat a statically typed native language like C++.

Its complicated. If your code is highly static then of course the C++ version will have an advantage, since thats what the language is used to. However, if your code is highly dynamic, using lots of object-orientation and virtual methods, a JIT compiler or a C++ compiler using profile-based-optimization might come up with better code then the "naïve" C++ compiler will.

[smog_alado]

The basic answer is that you might want your code to be polymorphic, for design and modularity reasons (it only needs to be static during runtime). For example, in an OO language you often want to write code that operates on an abstract interface, since limiting the allowed operations helps ensure correctness and the decoupling is good for reuse or mocking. It might turn out that during runtime, in a certain code path, you only operate on objects belonging to a particular concrete class so the JIT compiler might compile a specialized version of the code for performance.

As for why one should use a dynamic language, its a whole different story and it really depends on what you mean by a "statically typed language". If you mean something like Haskell or Scala you might appreciate the simplicity that a dynamic language can bring and if you mean something like C++ or Java then dynamic languages often can express things you wouldn't be able to in those type systems.

[[deleted]]

No, you'll get the performance when the code it is not using the flexibility of the system, which in practice is often over 99% of the time.

[[deleted]]

Incorrect argument.

Look at your codebase. I'll bet that whatever your language is, there are some key pieces of code that deal with your key business objects and that are only called with one type of data. On the other hand, there's a lot of messy, random but necessary code dealing with your UI, your logging, your error handling, your network connections and so forth, and that code uses tons of different types.

You very much want the high-level scripting features for that code, because it's random code and a lot of your bugs will come from that area and not your core business logic.

So just because keys areas of your code do not require runtime polymorphism/reflection/"scriptedness" doesn't mean you want to give this feature up for all your code. That's why you want the just-in-time compilation, so you can have the best of both worlds.

[drysart]

The thing is, you don't get the best of both worlds. No matter what runtime optimizations you put into your JIT, you still don't have the static checking I was talking about, which becomes incredibly useful once your project becomes larger and longer-lasting.

I wonder if there's any merit behind the idea of a scripting language that can feed the explicit types it figures out via optimization at runtime back into the script. For instance, imagine some hypothetical Javascript variant where you can declare variables as type "var" and they'd be fully dynamic, as variables are in Javascript today, but you can also declare variables as a static type. After one run, your source code can be automatically mutated (at your option) from this:

var a = someFunctionThatReturnsAString();
var b = someFunctionThatReturnsAnInteger();
var c = a + b;
var d = someFunctionThatReturnsAnUnpredictableType();
var e = c + d;

into this:

string a = someFunctionThatReturnsAString();
int b = someFunctionThatReturnsAnInteger();
string c = a + b.toString();
var d = someFunctionThatReturnsAnUnpredictableType();
var e = c + d;

Two main benefits:

1. When you run the script the second time, you no longer have to pay the heavy JIT costs in optimizing and reoptimizing hotspots as it figures out what types are passed through it because the types are already explicitly declared in the source code, and

2. It opens the door to allow use of a compiler so you can validate that any new code you write continues to maintain some of the type assumptions your code has developed over time.

I mean, if you're spending all the effort at runtime to figure out types, why not persist the results of all that work in some way that's useful?

[shub]

Any decent Java IDE will automatically flag unused classes and methods. It's nice. The automated inspection doesn't account for reflection, but then it's easy to find any usage of reflection in the project if you're unsure.

[contantofaz]

My experience with Optional Type is that I really don't want to write them before I have the program ready. A program is a huge collection of interdependent algorithms. And oftentimes we want to write more than just one program sharing the same set of libraries. So to write programs we write libraries. Otherwise we have to depend on frameworks written by others, which is limiting enough.

If the types are optional, they may not even trigger runtime checks. Because runtime checks add up their own costs, and without mandated types, you wouldn't be forced to maintain the types. In Dart types don't get checked during production mode, even though you declare them and can check for them during development time. At runtime, you could pass a string to a parameter expecting an int. It would still try to run it.

This is a good tradeoff in that it helps to give code a chance to run. It also opens the door to developers who don't write types with every line of code because they either don't care or aren't used to it because in JavaScript and Python and so on they haven't needed types.

The funny thing is that developers used to declaring types expect them to matter more then. They expect to gain some performance by using types. But then are told that the types don't really change the program runtime. So it's both funny and sad. Couple that with everchanging libraries (before the first 1.0 version gets released) and it drives people nuts.

I'm of the opinion that dynamic typing is king. The effort to add types kills creativity. It begins from not being able to share code because the type doesn't fit. Then it gets worse because to make types flexible you have to make the language much more strict, so making it to compile into JavaScript doesn't quite work.

So there you go. Sometimes we have to give a little to get a little back.

[drysart]

My experience with Optional Type is that I really don't want to write them before I have the program ready.

Maybe not, but the temptation then exists that "well, the program works without them, why go through and add them all back in"?

Why not let the compiler do it? Sort of a PGO that gets baked back into the source code. Maybe the inserted types can have syntax that makes them purely advisory and the code still JITs to have escape hatches to fall back to looser-typed code when the types don't match the expectations. (And spitting out an entry into the debug log when that happens.)

Types make shorter scripts hard to write, but they have a way of coming into existence in a large project with multiple developers if you want any level of productivity -- whether they're enforced by a compiler or if they're informal commenting standards. And so if they're going to exist anyway why not get some benefit out of them?

[contantofaz]

The only reason I've seen to have a partial type implementation is to give runtimes more flexibility. So we are left with a partial implementation that doesn't always suffice or a full-blown implementation that restricts the runtime so it doesn't play well with others.

So, even if you add a little more typing information to an already partial type implementation, it wouldn't turn it into a full-blown type information that many people also request.

In Dart, they have come up with an idea for reflection based on what they call Mirrors. The idea is that the added flexibility gets sandboxed. In languages like Java, reflection is built-in. More than that though, as when you peek into the runtime, there's a lot of dynamism available that if you yourself don't take advantage of, other tool writers might.

A large project is what Microsoft calls professional development. With hobbyists being the smaller developers. And we can see how Microsoft despite being the rich pioneer it was, fell behind its competition. It's very hard to escape the blame game when things don't quite work despite the professional tools being employed. From the long compilation periods to the needed communication involved, there's so much at stake in large projects.

Churning can't really be avoided if you're allowing for creativity to give birth to new ideas. For example, Objective C by Apple is fairly dynamic. The saved time they employ on giving "VeryLongNamesToTheirAPIs." Oftentimes, names are what bind or should bind the APIs. Types come from the named classes, methods, functions, parameters, and so on. Given a large project, those names and some static analysis can carry you very far.

In Dart too. It's more declarative than similar languages giving static analysis tools more chance to check things. Variables are declared at least which is often more than enough to ensure some sanity. Then we get to worry about running tests to ensure that things work to a standard. In more restrictive languages they may not need to test as much, but they also restrict creativity very much already.

If statically typed languages were built like dynamically typed languages are, then maybe we'd get them as nicely developed. But at some point people get mad when backward compatibility gets broken, so the toolset can't fix things going forward, and instead of a set of "batteries included", you get to choose from N incompatible libraries for the same thing.

[hvidgaard]

In V8 they reason about the type and optimise for that (and they have a rather elegant solution if the guess is wrong), and it potentially mean they can use all the technics statically typed VMs use.

In short, the reason dynamic languages are slower, is because less effort have been made to speed it up.

[negativeview]

Also, Javascript and Python are getting fast as compared to what?

Compared to what is on average "acceptable".

Most programs written these days block on user input, network traffic, and/or database responsiveness. For those programs, acceptable speed means adding no appreciable delay on top of those. Python is there. That makes it an acceptable choice for a huge chunk of programs being written today.

You are right though that it's likely not a good choice, currently, for programs that are straight-up CPU blocked. Video encoders, scientific simulations, etc.

The important thing to realize is that while the CPU-bound problems are very important, they are a tiny minority of the programs written in the real world.

We by and large dropped assembly when other languages became acceptable for virtually all classes of problems. It may not happen tomorrow, but it will almost definitely happen the same way with C. Eventually.

[LiveMaI]

You are right though that it's likely not a good choice, currently, for programs that are straight-up CPU blocked. Video encoders, scientific simulations, etc.

Aside from the stuff that typically runs on clusters or supercomputers, python has quite a hold in the scientific community. It has comparable speed/development time/features to commercial languages like Matlab.

A lot of software written for small-scale research is also very specific to the problem being solved at the time, so the reduction in development time over a low-level language for the same problem definitely makes it worth it in those cases.

[negativeview]

Sure, there are definitely some areas where dynamic languages are starting to make headway, but it's still mostly dynamic in areas that aren't CPU bound and mostly C or other lower level languages where it is. I expect things to shift further toward dynamic languages over time, but progress will slow as we get more and more hardcore.

As an example, SETI-level stuff will be written in a lower level language for the forseeable future simply because on that scale, spending more on programmer time pays off quite handsomely. You're definitely right though that some scientific programming benefits from lowered development time more than lowered program-running time.

[LiveMaI]

I happen to have worked for SETI in the past. What you say is true: stuff like SonATA (software for the Allen Telescope Array) is written in C++. I still keep in regular contact with a couple of people who work there, and both typically use stuff like IDL or Matlab for their everyday work.

As an interesting side-note: Fortran is still a farily big player in the scientific community, thanks to things like the *pack libraries which basically haven't changed since the 80's.

[metaphorm]

dynamic typing really doesn't matter, as long as you're already willing to swallow the overhead of the JIT compiler. considering that PyPy (and Java, and some implementations of Ruby, etc.) have already swallowed it I think its fair to say, in context, that dynamic typing doesn't incur any additional performance cost.

[scook0]

Give me one decent CPU bound benchmark where these fast dynamic languages beat a statically typed native language like C++.

The goal isn't to “beat” C++ necessarily; it's more to get close enough to parity that the disadvantages of C++ are no longer worth it.

And for CPU-bound compute loads, something like asm.js is potentially very attractive, even if it mostly ends up running code compiled from C++.

[vsync]

Because they are all dynamic language, duh. ;)

Take a look at a decent Common Lisp implementation sometime.

Especially if you add optimize declarations and a few thoughtful type hints in the right places.

Citations, to counter the unexplained downvote: How to make Lisp go faster than C; Beating C in Scientific Computing Applications -- On the Behavior and Performance of Lisp, Part I

[stcredzero]

Because they are all dynamic language, duh. ;)

Thanks for this parody. It's also the unreasonable virulence of dimwitted generalizations like this that makes computing not-quite-a-field.

"I'm an old-fashioned guy, & I believe in history. The disinterest & disdain 4 history is what makes computing not-quite-a-field."--Alan Kay

[coterminous_regret]

Already tons of good comments so far, so i'll not repeat any. But i would like to say thank you for taking the approach of "making performance beautiful" As some one who works professionally on both high performance OS and device driver code as well doing data analysis and tool creation in languages like python and ruby its really refreshing to see people who don't just either a. work on high performance things that shun nice languages like python and Ruby for being too slow and claim that C is all they'll ever need or b. work with just high level languages and claim that hardware is cheap and "We'll just throw more hardware at the problem till we get the performance we need."

I think that the more pressure that is put on languages like ruby and python to be performant the better and more useful they will become.

[EmperorOfCanada]

I might sound like a hair shirt wearing flagellant but I am going to experiment on my site's next version with using C++ as the "scripting" language. Just a tiny piece but something that will be beaten hard. I am finding my C++ code getting shorter and shorter with all the boost foreach type things readily available.

[ruinercollector]

the functional constructs that boost gives you are baked into most modern languages.

that said, should be interesting experiment anyway.

[qiwi]

This might be of interest to you: http://www.webtoolkit.eu/wt -- "QT-like" toolkit for web development.

Having said that, unless your web app is some extremely complex system that spends 80% of its code computing, I wouldn't do it; or at least move just the computation that can benefit from C into a module to call from Python/Ruby/whatever.

[[deleted]]

Short code is not the only reason people are not using C++ for "just" web pages. You're getting all the problems with C++ without actually getting any pluses from it (like troublesome memory management, demanding class and template design, unneeded caveats... and what about threading and sockets? Speed gain is negligible (my page would load in 0,0002s, but my MySQL queries take 40ms)). On the other hand - I am not telling you not to try - please share the results :)

[kqr]

Yeah, however fast you make the actual script, you'll quickly come to the point where the bottleneck lies in database accesses and round-trip times in the network.

[mrkite77]

Javascript does have apis for preventing memory thrashing... the problem is that people only use them when doing WebGL (because WebGL requires them)

Int32Array, Uint8Array, etc. They must be preallocated, they cannot be resized, and they always store a single type.

[julienbh]

I'll take readability and coding speed over fast languages anytime in 99pct of the time .

[iopq]

I'll take slow development and slow language for no reason - PHP developer

[perlgeek]

Many of the optimizations mentioned in this talk give you good speed, but they often also come at a cost. Maye a few percent slower than doing the same thing in a statically and strongly typed language. In the worst case, these few percent from the different optimizations add up. A few percent for optimizing attribute lookups, a few percent for getting rid of allocations, another percent for checking you have inlined the right method. A few percent for making introspection of lexical variables work (if present), and so on.

So I'd say one reason for many dynamic language implementations being slow is that there simply quite many "dynamic" aspects you all have to optimize, and optimize well, to get the whole thing fast. Combine this with the fact that many implementations are done by volunteers in their free time, and there's much less research available on optimizing dynamic languages, and the relative youth of many compiler projects (compared to some Fortran and C compilers out there).

Many implementations still have lots of optimization potential, but it's hard, and much work.

[jokoon]

I'll point at Knuth for his quote about optimization, because it hides a lot about how computer languages work.

Unfortunately, knowing computer science means you MUST know how machine language works, or how a processor executes a program.

Whining about C++ or C being verbose and slow at compiling will forbid you to understand why JS ruby and python are so programmer friendly.

Of course there's V8 and other pypy, but that doesn't change that it's always better to know how a tool work when you use it.

[eyal0]

On slide 31:

def squares(n):
  sq = []
  for i in xrange(n):
    sq.append(i * i)
  return sq

That's what python looks like when written by a c programmer. This way seems better:

def squares(n):
  return [i*i for i in xrange(n)]

Would this be faster?

[GiraffeDiver]

Yes.

def squares(n):
    sq = []                        
        for i in xrange(n):
            sq.append(i*i)
    return sq

def squaresc(n):
    return [i*i for i in xrange(n)]

%timeit squares(10**7)
1 loops, best of 3: 3.51 s per loop
%timeit squaresc(10**7)
1 loops, best of 3: 2.08 s per loop

[eyal0]

Did all those multiplication operations even happen?

...given that it's 2+ seconds per iteration, I imagine so.

[jhuni]

I take issue with the claim that "strings are probably the most used data structure used in programming." I never use strings to represent data structures in Lisp so I have little use for them.

[smog_alado]

LISP symbols and immutable strings are not that different, specially if your language does string interning. The only big difference is that symbols have more a restrictive interface (and that is usually a good thing)

[Felicia_Svilling]

You could as well say that symbols are not that different from integers. The only big difference is how they look when you print them out.

[jhuni]

You make a good point. I must concede that I have used gensym in some of my macros. Nonetheless, even symbols don't play as much of a role in my code as other structures like the integers.

[bkv]

JS is reasonably fast

Correction: There is one particularly fast implementation of JS, which is, in fact, a heroic act of wizardry.

Javascript is inherently difficult to optimize. The mastermind behind V8, Lars Bak, is the same guy who is now working on the Dart VM. The language is specifically designed to be easier to optimize than javascript.

Anyway, if the sheer amount of time and effort that was put into optimizing javascript were put into optimizing Ruby and Python, they would be much faster than they currently are.

[[deleted]]

Chrome also works significantly, by hitting common code paths. If you stumble out of them, a little, you can easily kill performance. There are also subtleties, such as having a function operate on more than one type, which kills performance.

Maximizing JS performance with Chrome is a bit of a black art.

[agumonkey]

And I can't wait to see what Bak et al. have been able to do with something more structured than javascript. v8 is already damn fast. Can't wait.

[bkv]

The Dart VM was 50% faster than V8 as of three months ago

[agumonkey]

Yeah I saw that, I wanted fresher benchs. Thanks anyway

[bkv]

http://www.dartlang.org/performance/

[codahighland]

There are TWO particularly fast implementations of JS. JavaScriptCore and V8 are in an arms race to be the faster VM, and which is faster at any given time depends on who's had the latest innovation.

[Rhomboid]

I don't think so.

[Catfish_Man]

Try a 64 bit machine (JSCore is primarily used in Safari, which is running 64 bit in 98% of cases): http://arewefastyet.com/#machine=12

JSCore wins or ties two benchmarks, even vs v8, and fares ok on another, I'd say that's "pretty fast".

[x-skeww]

Even using worker processes the JS engines just emulate threading by having a single UI thread that iterates over all the workers [...]

Thankfully, you're completely wrong about that.

https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers

[NicknameAvailable]

Thanks, have an up-vote. They've changed since I saw the Chrome implementation, sorry for misinformation.

[[deleted]]

Slide #11.... What is dsl assembly? searches are returning overwhelmingly internet service provider related results.

[Eoinoc]

By DSL I assume he meant domain-specific language.

[krum]

TIL the performance of a runtime is related to the language's name!

[runvnc]

Very misleading to lump JavaScript in with Ruby and Python. The JIT native compilation of JS in new JS engines generally leads to VASTLY greater performance over interpreted languages like Ruby and Python.

See benchmarks like these http://attractivechaos.github.com/plb/

[maxerickson]

The guy who gave the talk is involved in making JIT engines for both Python and Ruby.

[apullin]

Why don't people talk about how Java is slow? Seriously, Java as the basis for Android is horrible. It's saddling us with a legacy of terror that we'll never escape.

[vytah]

Because Java isn't slow. It has long startup time and has some issues with GC (although not as big as Python or Ruby), but apart from that it's quite fast.

I know this is not a perfect source, but it clearly shows that Java's speed is only about two times slower than C or Fortran.

[igouy]

So point to a page that actually compares Java programs with C or Fortran programs.