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

On “On Asm.js”

calculist.org

Post reply on HN
Print view View original

51–60 of 64 posts

Re: On “On Asm.js”

#51

Post by flohofwoe »

jheriko wrote: post #30
pcwalton wrote: post #29

Earlier quoted context omitted.

> Why can't we focus this effort on fixing C, or providing a better alternative? asm.js is a way of fixing C so that it's safe.

not even remotely close. sorry. i would qualify it but i imagine it is wasted based on the comment...

Well you can't get out of the sandbox or even crash the process you're running on with C/C++ compiled to asm.js. To me this qualifies as "safety". Of course you can mess up, fragment the local heap/typed-array and produce memory leaks. But it's all contained.

Re: On “On Asm.js”

#52

Post by flohofwoe »

jheriko wrote: post #34
steveklabnik wrote: post #18

Earlier quoted context omitted.

JavaScript is sandboxed, and safe. C......... isn't.

but it trivially can be - this is very measurable and lots of people do it. see for instance iOS, OS X, Android, Windows 8... actually I can just list the modern operating systems that don't provide such an environment out of the box: (end of list)

IMHO the "sandboxes" those OS'es provide are all terribly broken. You'll have to sign your code, you can't distribute your code outside of app shops (either completely impossible like on iOS, or scare-dialogs pop up like in OSX), there are gate keepers which dictate what software gets in the app shops and which don't, and which can remove your app from the shop at a whim. And did you look at the Windows8 Store Apps API? It's a f*cking joke. Innovation doesn't happen in those closed-down environments, only commerce (but commerce depends on innovation).

Re: On “On Asm.js”

#53

Post by pcx66 »

dgregd wrote: post #6

> I see plenty of reason to keep betting on evolution So why Mozilla helped to kill WebSQL? Because NoSQL (IndexedDB) is so much better than SQLite? Mozilla is too much focused on Brendan Eich baby. They should really move forward because JavaScript is becoming new IE6.

Don't know why others are giving you sensible answers, but you using the words 'Brendan Eich baby' shows your level of trolling. If you want a _good_ discussion, stop doing that.

Re: On “On Asm.js”

#54

Post by PeterisP »

mercurial wrote: post #47
PeterisP wrote: post #39

Earlier quoted context omitted.

What you say is done with UTF-8 + such a flag - if the string is pure ASCII (codes under 127) then the UTF8 representation is identical. IIRC latest python does exactly that, sending utf-8 to C functions that expect ascii, if they are 'clean'. But for common what usecases you're just dealing with ASCII? Unless your data comes from a cobol mainframe, you're going to get non-ascii input at random places. Html is a prim…

It really depends on what kind of thing you are doing. Say you're processing financial data from a big CSV. Sure, you may run into non-ASCII characters on some lines. So what? As long as you're streaming the data line-by-line, it's still a big win. You could say the same for HTML - you're going to pay the Unicode price on accented content, but not with all your DOM manipulations which only involve element names (thou…

The scenarios you mention would actually have significantly higher performance in UTF8 (identical to ASCII) rather than in multibyte encodings with fixed character size such as UCS2 or UTF32 that were recommended above. That's why utf-8 is the recommended encoding for html content.

Streaming, 'dealing with text nodes' while ignoring their meaning, and equality operations are byte operations that mostly depend on size of the text after encoding.

Re: On “On Asm.js”

#55

Post by iso-8859-1 »

azakai wrote: post #7
dgregd wrote: post #6

> I see plenty of reason to keep betting on evolution So why Mozilla helped to kill WebSQL? Because NoSQL (IndexedDB) is so much better than SQLite? Mozilla is too much focused on Brendan Eich baby. They should really move forward because JavaScript is becoming new IE6.

WebSQL was a completely separate debate, if I recall correctly, the issues there had to do with WebSQL being heavily dependent on SQLite, a single implementation. So it was hard to spec in a vendor-independent way like web standards require. IndexedDB is much less capable than SQLite, no doubt about it, but still very useful, and far far simpler and feasible to spec and standardize (which it has been).

But SQL is already standardized! They just have to determine a reasonable subset of the existing standard.

Re: On “On Asm.js”

#56

Post by mercurial »

PeterisP wrote: post #54
mercurial wrote: post #47

Earlier quoted context omitted.

It really depends on what kind of thing you are doing. Say you're processing financial data from a big CSV. Sure, you may run into non-ASCII characters on some lines. So what? As long as you're streaming the data line-by-line, it's still a big win. You could say the same for HTML - you're going to pay the Unicode price on accented content, but not with all your DOM manipulations which only involve element names (thou…

The scenarios you mention would actually have significantly higher performance in UTF8 (identical to ASCII) rather than in multibyte encodings with fixed character size such as UCS2 or UTF32 that were recommended above. That's why utf-8 is the recommended encoding for html content. Streaming, 'dealing with text nodes' while ignoring their meaning, and equality operations are byte operations that mostly depend on size…

I think we're actually in agreement :)

Re: On “On Asm.js”

#57

Post by Udo »

pilif wrote: post #16
pornel wrote: post #12

In this exchange UTF-8 got dragged into list of ugly hacks, but it is a beautiful hack. Endian-independent, more efficient than UTF-16 for most languages (often including CJK web pages: halved cost of HTML & URLs makes up for 33% extra text cost), supports easy and safe substring search, can detect cut characters, and all that with ASCII and C-string backwards-compatibility. If I could redesign entire computing platf…

The disadvantage of utf-8 is that it's a variable length encoding. This means that certain operations which are usually O(1) are O(n) with UTF-8: one is finding the n-th character in a string, the other is finding the length in characters (though that's also true for null terminated C strings) Another problem is that swapping a character in a string might cause the (byte) length of the string to change, which might f…

> The disadvantage of utf-8 is that it's a variable length encoding.

So is UTF-16, by the way.

Re: On “On Asm.js”

#58

Post by steveklabnik »

CmonDev wrote: post #44
steveklabnik wrote: post #17

Earlier quoted context omitted.

This scenario assumes that browser vendors have the time and employees to work on a JavaScript and a WhateverScript VM.

"WhateverScript VM" - you mean kind of like Dart VM for Chrome by Google?

Yup. Only one organization in the world has the resources and desire. I don't want a Google-run future.

Re: On “On Asm.js”

#59

Post by CmonDev »

steveklabnik wrote: post #58
CmonDev wrote: post #44

Earlier quoted context omitted.

"WhateverScript VM" - you mean kind of like Dart VM for Chrome by Google?

Yup. Only one organization in the world has the resources and desire. I don't want a Google-run future.

I don't care if it's just Google or Google + Mozilla + some bunch of other guys. At least with Dart I can see the difference and it took a couple of years to implement instead of a dozen of years. I hope Dart will get some traction so that other players will be innovating again instead of relying on legacy languages.

Re: On “On Asm.js”

#60

Post by EpicEng »

antimagic wrote: post #50
pilif wrote: post #16

Earlier quoted context omitted.

The disadvantage of utf-8 is that it's a variable length encoding. This means that certain operations which are usually O(1) are O(n) with UTF-8: one is finding the n-th character in a string, the other is finding the length in characters (though that's also true for null terminated C strings) Another problem is that swapping a character in a string might cause the (byte) length of the string to change, which might f…

O(n) is only an issue for large strings - let's say it might start being a concern at n > 1024, although for modern systems quite frankly n can be substantially larger without incurring any noticeable time loss. In my 20 year career, it has been rare to deal with strings larger than 1024 characters. In those cases, I don't think it's unreasonable to have to use a specialised class that tracks string indexing such tha…

Or, of course, many smaller strings...
Post reply on HN