5 ms·

I think the short answer is making a dynamic language really fast is really hard. You can do it, but historically you've needed to be Sun or Google to pull it o

I think the short answer is making a dynamic language really fast is really hard. You can do it, but historically you've needed to be Sun or Google to pull it off. Sun made java fast. Google made javascript pretty fast. So ruby either needed to piggy back on someone else's work (jvm or whatever) or get some next-level-smart vm developers. Even then, people have written about how ruby presents some serious challenges.

chinhodado 11y ago
Why is Java a dynamic language? Isn't Java statically typed?
- supster 11y ago
  Static vs dynamic is actually kind of a blurry line: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
- alfanick 11y ago
  you can do metaprogramming - invent new methods or class on the run
- ludamad 11y ago
  Dynamically typed languages essentially have something like Java's Object type as the type of everything. Using wide types like that and interfaces in Java, you easily have dynamic traits in your code.
- mike_hearn 11y ago
  The dynamic its of Java are not its type system, they're things like late dynamic linking.
nly 11y ago
> Sun made java fast. Arguably one of the most prevalent Java platforms these days, Android, doesn't JIT... it compiles AoT. Java is actually a great example of languages with static type systems being easier to optimize, whereas the JVM is the new hotness for everything dynamic.
- Eridrus 11y ago
  The mobile environment really benefits AoT though; you care about CPU usage more due to battery life and you really care about startup performance because slow starts make your platform seem sluggish. Java's main usage (outside of Android) atm is on the server-side, and startup time isn't a huge deal there and you care about cost more than actual perf.
frandroid 11y ago
> Google made javascript pretty fast. A small outsourced team in Denmark did, actually. Sure, they were hired by Google, but that kind of belies your argument that only a large corp can do this, no?
- stcredzero 11y ago
  Also, Sun making Java fast was due to Hotspot, which was inspired by work on Self, the successor to Smalltalk.
- asolove 11y ago
  For sure, a small team can do the work. The question is: who will pay them to? Your five smart compiler friends could maybe get contract work making specific hotspots a bit faster for some specific medium-sized company. But who is going to finance them rebuilding the whole approach from scratch over several years, in a way that benefits a whole platform rather than just their company, and shelter the team from short-term priorities and reorgs? That takes a big company that has an enormous economic stake in the entire platform.
jerf 11y ago
"Sun made java fast. Google made javascript pretty fast." But there's a lot of daylight between what you call "fast" and "pretty fast". For all the effort that has been poured into Javascript, it remains a slow language for general-purpose programming. That's why asm.js could speed up JS as much as it could; if JS was already "C fast" nobody would have needed or used asm.js. And nobody would talk about Web Assembly if JS was already that fast. It is definitely true that the bytecode interpreters that pretty much all the dynamic languages started with were not the last words in speed, and things like JITs and such have sped them up a lot. When the dynamic interpreted languages were routinely 50x slower than C, there was room for improvement. But there seems to be a wall at around 10x slower than C for general-purpose programming [1] that the languages are having a hard time penetrating from what I can see: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-... (Bizarrely, they've broken out into two graphs, with the slower languages getting graphed first. It's actually one big graph, I think.) Having heard people say for many, many years that "languages don't have speeds, only implementations do", I no longer believe that. After vast quantities of time and effort have been poured into the dynamic languages, they're still slow. Just not as slow as they used to be, and often with significantly larger memory footprints to get to "not as slow as they used to be". NB: Pity LuaJIT is no longer on that site. If you design your "dynamic" language for speed, you can do a lot better. But I've not seen proof you can design a language for convenience and dynamicness and then come along 15+ years later and make it C-fast. [1]: I have to qualify that, because any JIT worth its salt can optimize certain very advantageous code down to C speed. As the benchmark contains some of these tasks, you can see the dynamic languages with decent JITs reach their tails down to near C-speed in that graph. However, being able to optimize code that loops over integers and adds them up to C speed or even beyond if you automatically use SIMD doesn't mean that you're going to C performance in general.
- heavenlyhash 11y ago
  I'd offer one riff further on all that: indeed, core languages do continue to influence speed on a scale that implementation details can only batter at the edges of. In Ruby's case, ObjectSpace is worth taking a peek at for an example: http://ruby-doc.org/core-2.3.0/ObjectSpace.html http://ruby-doc.org/core-2.3.0/ObjectSpace.html We have here a method that counts all objects, by type, in the entire heap. How, exactly, could one propose to parallelize that? Not Easily. Does that leak synchronization needs -- and thus performance implications -- into every layer of GC, scheduling, class/module definition loading, and so on? Yup. Doesn't matter how much you approach the pinnacle of excellence in JIT. Some definitions of operational parameters are just going to be expensive. Other languages that simply don't allow such operations are at a permanent advantage. There is no such thing as engineering without tradeoffs.
omaranto 11y ago
"Sun made java fast. Google made javascript pretty fast." And Mike Pall made Lua pretty damn fast.

chinhodado 11y ago

Why is Java a dynamic language? Isn't Java statically typed?

supster 11y ago
Static vs dynamic is actually kind of a blurry line: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
alfanick 11y ago
you can do metaprogramming - invent new methods or class on the run
ludamad 11y ago
Dynamically typed languages essentially have something like Java's Object type as the type of everything. Using wide types like that and interfaces in Java, you easily have dynamic traits in your code.
mike_hearn 11y ago
The dynamic its of Java are not its type system, they're things like late dynamic linking.

nly 11y ago

> Sun made java fast. Arguably one of the most prevalent Java platforms these days, Android, doesn't JIT... it compiles AoT. Java is actually a great example of languages with static type systems being easier to optimize, whereas the JVM is the new hotness for everything dynamic.

Eridrus 11y ago
The mobile environment really benefits AoT though; you care about CPU usage more due to battery life and you really care about startup performance because slow starts make your platform seem sluggish. Java's main usage (outside of Android) atm is on the server-side, and startup time isn't a huge deal there and you care about cost more than actual perf.

frandroid 11y ago

> Google made javascript pretty fast. A small outsourced team in Denmark did, actually. Sure, they were hired by Google, but that kind of belies your argument that only a large corp can do this, no?

stcredzero 11y ago
Also, Sun making Java fast was due to Hotspot, which was inspired by work on Self, the successor to Smalltalk.
asolove 11y ago
For sure, a small team can do the work. The question is: who will pay them to? Your five smart compiler friends could maybe get contract work making specific hotspots a bit faster for some specific medium-sized company. But who is going to finance them rebuilding the whole approach from scratch over several years, in a way that benefits a whole platform rather than just their company, and shelter the team from short-term priorities and reorgs? That takes a big company that has an enormous economic stake in the entire platform.

jerf 11y ago

"Sun made java fast. Google made javascript pretty fast." But there's a lot of daylight between what you call "fast" and "pretty fast". For all the effort that has been poured into Javascript, it remains a slow language for general-purpose programming. That's why asm.js could speed up JS as much as it could; if JS was already "C fast" nobody would have needed or used asm.js. And nobody would talk about Web Assembly if JS was already that fast. It is definitely true that the bytecode interpreters that pretty much all the dynamic languages started with were not the last words in speed, and things like JITs and such have sped them up a lot. When the dynamic interpreted languages were routinely 50x slower than C, there was room for improvement. But there seems to be a wall at around 10x slower than C for general-purpose programming [1] that the languages are having a hard time penetrating from what I can see: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-... (Bizarrely, they've broken out into two graphs, with the slower languages getting graphed first. It's actually one big graph, I think.) Having heard people say for many, many years that "languages don't have speeds, only implementations do", I no longer believe that. After vast quantities of time and effort have been poured into the dynamic languages, they're still slow. Just not as slow as they used to be, and often with significantly larger memory footprints to get to "not as slow as they used to be". NB: Pity LuaJIT is no longer on that site. If you design your "dynamic" language for speed, you can do a lot better. But I've not seen proof you can design a language for convenience and dynamicness and then come along 15+ years later and make it C-fast. [1]: I have to qualify that, because any JIT worth its salt can optimize certain very advantageous code down to C speed. As the benchmark contains some of these tasks, you can see the dynamic languages with decent JITs reach their tails down to near C-speed in that graph. However, being able to optimize code that loops over integers and adds them up to C speed or even beyond if you automatically use SIMD doesn't mean that you're going to C performance in general.

heavenlyhash 11y ago
I'd offer one riff further on all that: indeed, core languages do continue to influence speed on a scale that implementation details can only batter at the edges of. In Ruby's case, ObjectSpace is worth taking a peek at for an example: http://ruby-doc.org/core-2.3.0/ObjectSpace.html http://ruby-doc.org/core-2.3.0/ObjectSpace.html We have here a method that counts all objects, by type, in the entire heap. How, exactly, could one propose to parallelize that? Not Easily. Does that leak synchronization needs -- and thus performance implications -- into every layer of GC, scheduling, class/module definition loading, and so on? Yup. Doesn't matter how much you approach the pinnacle of excellence in JIT. Some definitions of operational parameters are just going to be expensive. Other languages that simply don't allow such operations are at a permanent advantage. There is no such thing as engineering without tradeoffs.

omaranto 11y ago

"Sun made java fast. Google made javascript pretty fast." And Mike Pall made Lua pretty damn fast.