Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Asm.js

acko.net

Post reply on HN
Print view View original

171–180 of 185 posts

Re: On Asm.js

#171

Post by acjohnson55 »

jheriko wrote: post #160
acjohnson55 wrote: post #158

Earlier quoted context omitted.

I have another reply to that effect somewhere in this thread :) Modern assembly languages often at a slightly higher level of representation than 1-to-1 with the instruction set so it's tough to draw a tough line, but yes, generally speaking, you should be able to translate the majority of the language to machine code with opcode tables. It's also interesting that machine code isn't even the lowest level representati…

You mean macro assembler languages? Its a pedantic distinction but I wasn't intending to imply those... 'Pure' assembly languages are still not 1 to 1 but are never worse than many to one, eg nop is often a real, but useless instruction with some other mnemonic.... Not sure what you point is about microcode... That is an implementation detail which, even for eg, x86 LEA where you think you are leveraging it, it is no…

We agree! I'm not arguing with you. I'm just trying to provide a bit more context for people who are trying to understand the purpose of all this. Judging by the vast majority of remarks on the article, there's a lot of misunderstanding of how this stuff works.

Re: On Asm.js

#172

Post by captainmuon »

thatthatis wrote: post #57
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

On the web, when one thing just works, albeit slowly; and another thing requires installation but runs quickly; the thing that just works is likely to win. Unless java gets upgraded to a first class browser component, JavaScript will tend to win. As a product designer, every step I take my user through loses users. Installing java is a big, scary step that I can almost always avoid. The insurmountable issue is that i…

Well, until about a year ago, Java was on (I'm guessing) 70% of PCs, Flash on > 95%. Now with the shift away from plugins, and the growing importance of mobile, its shrinking quickly.

But! in the brave new world of HTML5 and so on, you still can't assume that everybody has all these features. Either they are stuck on older browsers (at work, or my old laptop that I rarely use), there are subtle implementation differences bewteen browsers (although I have cutting-edge Android devices, the cool demonstrations often don't work nicely in them), or finally the browser is OK, but the computer is too slow.

I only have one computer that can run all this newfangled WebGL stuff at decent speed, and it's my gaming PC at home.

Re: On Asm.js

#173

Post by captainmuon »

drawkbox wrote: post #84
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

Agreed with most points, largely it is timing (as with Flash's original stronghold and the re-up when it solved a huge video on the web problem with Flash video i.e. Youtube rush). However Snap.svg (snapsvg.io) made by the Raphael creator and backed by Adobe seems to be the best vector animation replacement yet. It is really a mashup of Flash vector and Silverlight declarative style, almost an iteration (you still lo…

Snap.svg looks really nice! I meant mainly the Flash authoring tools (Macromedia Flash) are missing. Every idiot used to be able to click together a little animation. It even spawned a new (although questionable) art style of "Flash cartoons".

Re: On Asm.js

#174

Post by pwang »

macspoofing wrote: post #118
pwang wrote: post #25

It's very simple - there is no magic here. asm.js is just a "pidgin instruction set architecture", to allow communication between an emerging set of VMs - the browser runtimes - and a compiler backend. (The front-ends are the LLVM front-ends.) The article is exactly right in saying that it's a way to route around JS. Javascript fanboys should not be praising asm.js, because it's a way to route around them. (Which is…

>Javascript fanboys should not be praising asm.js, because it's a way to route around them. Depends on what kind of JavaScript fanboy you are. If you love the language and want applications to be written, from the ground up, in JS, asm.js is not your friend. If you want to build applications that run on pretty much every platform + kitchen sink, this is for you.

Doesn't that just make you a browser+web fan, and not a JS fan?

Re: On Asm.js

#175

Post by thatthatis »

millstone wrote: post #169
thatthatis wrote: post #60

Earlier quoted context omitted.

This guy gets it. The browser, html/css/js, is the most ubiquitous common runtime that has ever existed. A lot of services have an iPhone app, an android app, and sometimes even a desktop program. But if you have a website, you get all of those platforms at once. Sure you have to do things differently, usually more slowly, but you can do whatever you do on any device with a browser.

It's not the case that a web app is capable of doing "whatever you do on any device." The browser exposes a tiny fraction of the actual device capabilities. Browsers are themselves native apps, and therefore web apps will always be less capable than native apps, because web apps are subject to the one-two punch of the limitations imposed by native apps and the browser.

Im not sure your contention that browsers will always be hamstrung is true, time will tell, but proposals for HTML spec camera integration, gps integration, etc are alive and well.

To the point of paying the fee of app in app, you're right that there will always be a penalty. But "will browser apps ever run as fast as native" is not really the right question. The right question is "will browser apps ever be able to run fast enough."

Finally, a clarifying point. When i said "do whatever you do" I meant that a website does the same thing in every browser, not that websites currently can do the same thing as native apps.

Re: On Asm.js

#176

Post by thatthatis »

hrjet wrote: post #155
thatthatis wrote: post #57

Earlier quoted context omitted.

On the web, when one thing just works, albeit slowly; and another thing requires installation but runs quickly; the thing that just works is likely to win. Unless java gets upgraded to a first class browser component, JavaScript will tend to win. As a product designer, every step I take my user through loses users. Installing java is a big, scary step that I can almost always avoid. The insurmountable issue is that i…

But the cost of installing Java is spread across several apps. So the cost is negligible over time. It is like saying, if I build a web-app, the user needs to first install the browser. True, but once installed, other web-apps have a zero cost of installation.

Not exactly. A web browser has to be installed before they start the process. Java has to be installed either at the beginning of the process or during the process.

I.e. the installation point of java is inside of my conversion funnel for some x > 0% of people I am targeting.

Re: On Asm.js

#177

Post by thatthatis »

captainmuon wrote: post #172
thatthatis wrote: post #57

Earlier quoted context omitted.

On the web, when one thing just works, albeit slowly; and another thing requires installation but runs quickly; the thing that just works is likely to win. Unless java gets upgraded to a first class browser component, JavaScript will tend to win. As a product designer, every step I take my user through loses users. Installing java is a big, scary step that I can almost always avoid. The insurmountable issue is that i…

Well, until about a year ago, Java was on (I'm guessing) 70% of PCs, Flash on > 95%. Now with the shift away from plugins, and the growing importance of mobile, its shrinking quickly. But! in the brave new world of HTML5 and so on, you still can't assume that everybody has all these features. Either they are stuck on older browsers (at work, or my old laptop that I rarely use), there are subtle implementation differe…

Web gl is a small part of the rich internet applications currently being built. I agree that the web is still too early for advanced games.

On the point of older browsers: 1) the trend of % of people using older browsers is going down. Whereas the number of people using modern browsers without flash and/or java is going up (ie iOS mobile).

2) someone with an older browser expects certain parts of the web to be broken. Being broken in IE6 somewhat says "were more modern than you, try again after you upgrade.". I think people who see this are likely to come back at a future date, whereas someone who can't use it bc of flash is unlikely to think their problem will go away in the future.

Re: On Asm.js

#178

Post by flohofwoe »

iso-8859-1 wrote: post #139
flohofwoe wrote: post #22

Earlier quoted context omitted.

From a developer's perspective PNaCl and emscripten is almost the same to work with, the difference is just a couple of hundred lines of wrapper code (less then the differences betwenn iOS and Android wrapper code) and you need to find a higher abstraction layer for threaded code. And if the differences on the surface are so small, and the performance difference is acceptable as well (it is IMHO), I don't really care…

You're just considering the game-perspective, where you don't need anything but GL and sound. What about WebRTC? What about DOM manipulation? You can't do this from Emscripten very well.

It's actually really easy to build C interfaces to any Javascript API or lib. Since compiled code is just JS you can just directly call from C code into JS code and vice-versa. Most of emscripten's CRT wrapper is actually implemented in hand-written JS, as well as the OpenGL-to-WebGL wrapper. For an app which mainly needs to do DOM manipulation it is probably better to write it mostly in traditional JS and only implement the performance sensitive stuff in a C library compiled to JS. Best of both worlds...

Re: On Asm.js

#179

Post by flohofwoe »

CmonDev wrote: post #163
kevingadd wrote: post #86

Earlier quoted context omitted.

asm.js doesn't have support for reference types. You can access threads via the HTML5 'Web Worker' feature.

So, all the C++ threading code will automatically be converted to 'Web Workers'?

No, but it's not a great deal to write a parallel execution subsystem in C/C++ which abstracts the differences between pthreads and WebWorkers away. Using low-level pthreads primitives directly in high-level code is a bad idea anyway.

Re: On Asm.js

#180

Post by haberman »

lifthrasiir wrote: post #146
haberman wrote: post #124

Earlier quoted context omitted.

No VM? What do you call V8, SpiderMonkey, etc?

The conversion from asm.js to native code is much easier than the conversion from JavaScript to native code. The conversion from the real assembly code to native code would be slightly easier than that, but not significantly, making asm.js close to the assembly language (with an infinite number of registers, if that's your concern).

If "ease of converting to native code" is your criterion for "close to assembly language," then Brainf*ck is about the closest to assembly language you can get, because you can write a BF->x86 JIT in about 100 lines of C: http://blog.reverberate.org/2012/12/hello-jit-world-joy-of-s...

So if that's what we're going for, we should forget asm.js and PNaCl and just use BF and expect very close to native speed.

But this won't in fact give native code speed, despite how easy BF is to JIT. Why do you suppose that is?

Post reply on HN