6 ms·

JS is quite a bit faster than, say, idiomatic Objective-C. Or Java run through Dalvik. Personally, I don't see why everyone focuses on JavaScript as a massive

JS is quite a bit faster than, say, idiomatic Objective-C. Or Java run through Dalvik. Personally, I don't see why everyone focuses on JavaScript as a massive source of inefficiency compared to, say, PHP. Not to mention the rose-colored glasses we see the past in: folks back in the '90s used to work day in and day out with VB6 (or even interpreted Java) apps.

candiodari 10y ago
Comparing browser games with Dalvik games on 1/4th the cpu/gpu as on my desktop, I feel obliged to point out: Nope. Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Javascript does not match Java in speed, not regular java, nor Dalvik. Comparing node.js apps with PHP apps, it doesn't match PHP performance either.
- pcwalton 10y ago
  > Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Yes, it does, because I'm talking about JavaScript. Not about the entire browser graphics stack (which, by the way, is architecturally better than that of Android). > Javascript does not match Java in speed, not regular java, nor Dalvik. No, Dalvik is slow compared to JS. Its trace based architecture is roughly on par with JS engines in 2009. > Comparing node.js apps with PHP apps, it doesn't match PHP performance either. Zend doesn't even have a JIT.
  - candiodari 10y ago
    Well, that may be true, and a big plus for the developers of those systems, but if the results aren't there, what's the point ? Even if it's browser APIs rather than directly the language/interpreters ...
mpweiher 10y ago
> JS is quite a bit faster than, say, idiomatic Objective-C. (a) That depends hugely on what you consider "idiomatic" Objective-C and (b) yeah, that's kind of my point. If you write Objective-C in the style that is currently popular and propagated, treating it as a unified programming language like JS, Java or Smalltalk, you're going to be slow. In my book[1], I show how easy it is to be slower not just than JS or Java, but even slower than a byte-coded Smalltalk interpreter or Ruby. And the sad part is that it's not even particularly expressive! On the other hand, I also show how you can use the original Objective-C style, let's call it "Software-ICs", to create an XML parser faster than libxml and with a much nicer interface, or a Postscript interpreter that uses Objective-C objects as Postscript objects and is still faster than Adobe's interpreter (written in C) for most basic language stuff like arithmetic and loops (it doesn't do the graphics itself, so comparing those numbers would be pointless). In fact, said Postscript interpreter, written in Objective-C, is faster at arithmetic than the "bad" Objective-C style, while doing automatic arithmetic promotion, so being safer. The "Software-IC" style for Objective-C involves fast components written in C connected at the architectural level by dynamic messaging. It is highly idiomatic, convenient, fun and fast as hell. Interestingly, variations of that basic style are being rediscovered these days by the people doing "imperative shell, functional core". See for example Gary Bernhard's talk[2] and then tell me that the final picture doesn't look almost exactly like the pictures Cox drew of Software-ICs (and remember that Cox also said that (a) messaging didn't have to be synchronous and (b) the implementation language for the Software ICs didn't matter much). The Unix tools are also very similar, with fast components written in C connected at the architectural level with pipes. This is also the reason why I think my Objective-Smalltalk language[3] actually has a good chance of enabling very fast programs despite the very high level of abstraction it is aiming for. Being able to pick an appropriate interconnection style and fast components is the key to fast software. Back to the original point, we are leaving orders of magnitude of performance on the table, quite frequently for no particular reason. And as I wrote elsewhere, I actually think this current point we have reached is good for software and for software people, because we can get that performance quite easily by writing decent code, and writing decent code is starting to matter more again. Just like I think the end of Moore's law might finally break the stranglehold Intel has had on hardware architecture, so innovative architectures (remember the Transputer[4]?) have a chance and aren't clobbered by Intel's next fab-step. Speaking of innovative hardware architecture, has there been any new news on the Mill? Interesting times. Anyway, I didn't bring up JavaScript, this problem is everywhere. I just thought that bringing it up as a counterpoint was...humorous. [1] Did I mention my book? g https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-OS-Performance-Tuning-Cocoa-Cocoa-Touch-Objective-C-and-Swift/PGM161424.html https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-... [2] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [3] http://objective.st/ http://objective.st/ [4] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
- vanderZwan 10y ago
  So I checked out your Objective Smalltalk (aside: isn't that a pleonasm?) link, the last update was from May 2014. Are you still working on it?
  - mpweiher 10y ago
    Thanks for checking it out! Yes, I am still working on it, in fact I just added the first cut of an sqlite scheme-handler 3 days ago (https://github.com/mpw/Objective-Smalltalk https://github.com/mpw/Objective-Smalltalk ). Still read-only for now and doesn't do any complex queries. On the other hand, table-name completion is kind of nice. You are right though that I should update the site more often. The seeming pleonasm is intentional...and not really a pleonasm. When you look more closely at the "Objective" side of Objective-C, it really is more about architectural interconnection than just adding Smalltalk to C, Smalltalk-style messaging is just one mechanism chosen. Adding the kind of architectural promiscuity that's in Objective-C to Smalltalk is a big boon. On the other hand there is the (fro me) big idea of the Smalltalk class libraries, the fact that the machine primitives are not the conceptual primitives (Object -> Number -> SmallInteger, Collection -> Array). Taking that and applying to the "objective" part is also a big deal. I believe.

candiodari 10y ago

Comparing browser games with Dalvik games on 1/4th the cpu/gpu as on my desktop, I feel obliged to point out: Nope. Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Javascript does not match Java in speed, not regular java, nor Dalvik. Comparing node.js apps with PHP apps, it doesn't match PHP performance either.

pcwalton 10y ago
> Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Yes, it does, because I'm talking about JavaScript. Not about the entire browser graphics stack (which, by the way, is architecturally better than that of Android). > Javascript does not match Java in speed, not regular java, nor Dalvik. No, Dalvik is slow compared to JS. Its trace based architecture is roughly on par with JS engines in 2009. > Comparing node.js apps with PHP apps, it doesn't match PHP performance either. Zend doesn't even have a JIT.
- candiodari 10y ago
  Well, that may be true, and a big plus for the developers of those systems, but if the results aren't there, what's the point ? Even if it's browser APIs rather than directly the language/interpreters ...

mpweiher 10y ago

> JS is quite a bit faster than, say, idiomatic Objective-C. (a) That depends hugely on what you consider "idiomatic" Objective-C and (b) yeah, that's kind of my point. If you write Objective-C in the style that is currently popular and propagated, treating it as a unified programming language like JS, Java or Smalltalk, you're going to be slow. In my book[1], I show how easy it is to be slower not just than JS or Java, but even slower than a byte-coded Smalltalk interpreter or Ruby. And the sad part is that it's not even particularly expressive! On the other hand, I also show how you can use the original Objective-C style, let's call it "Software-ICs", to create an XML parser faster than libxml and with a much nicer interface, or a Postscript interpreter that uses Objective-C objects as Postscript objects and is still faster than Adobe's interpreter (written in C) for most basic language stuff like arithmetic and loops (it doesn't do the graphics itself, so comparing those numbers would be pointless). In fact, said Postscript interpreter, written in Objective-C, is faster at arithmetic than the "bad" Objective-C style, while doing automatic arithmetic promotion, so being safer. The "Software-IC" style for Objective-C involves fast components written in C connected at the architectural level by dynamic messaging. It is highly idiomatic, convenient, fun and fast as hell. Interestingly, variations of that basic style are being rediscovered these days by the people doing "imperative shell, functional core". See for example Gary Bernhard's talk[2] and then tell me that the final picture doesn't look almost exactly like the pictures Cox drew of Software-ICs (and remember that Cox also said that (a) messaging didn't have to be synchronous and (b) the implementation language for the Software ICs didn't matter much). The Unix tools are also very similar, with fast components written in C connected at the architectural level with pipes. This is also the reason why I think my Objective-Smalltalk language[3] actually has a good chance of enabling very fast programs despite the very high level of abstraction it is aiming for. Being able to pick an appropriate interconnection style and fast components is the key to fast software. Back to the original point, we are leaving orders of magnitude of performance on the table, quite frequently for no particular reason. And as I wrote elsewhere, I actually think this current point we have reached is good for software and for software people, because we can get that performance quite easily by writing decent code, and writing decent code is starting to matter more again. Just like I think the end of Moore's law might finally break the stranglehold Intel has had on hardware architecture, so innovative architectures (remember the Transputer[4]?) have a chance and aren't clobbered by Intel's next fab-step. Speaking of innovative hardware architecture, has there been any new news on the Mill? Interesting times. Anyway, I didn't bring up JavaScript, this problem is everywhere. I just thought that bringing it up as a counterpoint was...humorous. [1] Did I mention my book? g https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-OS-Performance-Tuning-Cocoa-Cocoa-Touch-Objective-C-and-Swift/PGM161424.html https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-... [2] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [3] http://objective.st/ http://objective.st/ [4] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer

vanderZwan 10y ago
So I checked out your Objective Smalltalk (aside: isn't that a pleonasm?) link, the last update was from May 2014. Are you still working on it?
- mpweiher 10y ago
  Thanks for checking it out! Yes, I am still working on it, in fact I just added the first cut of an sqlite scheme-handler 3 days ago (https://github.com/mpw/Objective-Smalltalk https://github.com/mpw/Objective-Smalltalk ). Still read-only for now and doesn't do any complex queries. On the other hand, table-name completion is kind of nice. You are right though that I should update the site more often. The seeming pleonasm is intentional...and not really a pleonasm. When you look more closely at the "Objective" side of Objective-C, it really is more about architectural interconnection than just adding Smalltalk to C, Smalltalk-style messaging is just one mechanism chosen. Adding the kind of architectural promiscuity that's in Objective-C to Smalltalk is a big boon. On the other hand there is the (fro me) big idea of the Smalltalk class libraries, the fact that the machine primitives are not the conceptual primitives (Object -> Number -> SmallInteger, Collection -> Array). Taking that and applying to the "objective" part is also a big deal. I believe.