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

21–30 of 64 posts

Re: On “On Asm.js”

#21

Post by PeterisP »

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…

Umm, is there any unicode encoding where finding n-th character (not codepoint) in string is O(1) ? In any encoding you can have a single 'composite character' that consists of dozens of bytes, but needs to be counted as a single character for the purposes of string length, n-th symbol, and cutting substrings.

This is not a disadvantage of UTF-8 but of unicode (or natural language complexity) as such.

Re: On “On Asm.js”

#22

Post by rolux »

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…

Reference: http://www.python.org/dev/peps/pep-0393/

Re: On “On Asm.js”

#23

Post by rolux »

PeterisP wrote: post #21
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…

Umm, is there any unicode encoding where finding n-th character (not codepoint) in string is O(1) ? In any encoding you can have a single 'composite character' that consists of dozens of bytes, but needs to be counted as a single character for the purposes of string length, n-th symbol, and cutting substrings. This is not a disadvantage of UTF-8 but of unicode (or natural language complexity) as such.

"UTF-32 (or UCS-4) is a protocol to encode Unicode characters that uses exactly 32 bits per Unicode code point. All other Unicode transformation formats use variable-length encodings. The UTF-32 form of a character is a direct representation of its codepoint." (http://en.wikipedia.org/wiki/UTF-32)

Of course, the problem of combining marks and CJK ideographs remains.

Re: On “On Asm.js”

#24

Post by steveklabnik »

derefr wrote: post #20
jheriko wrote: post #14

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterl…

Native code is, at the bottom of its ladder of abstraction, always held at the behest of some vendor's platform or another. Microsoft, Apple, and Google will never agree on a set of standard C libraries that could be used to build rich, modern graphical applications. If they could, we'd never have needed the web for anything other than the ideas of hyperlinks and intents--everything else could be done with URL-specif…

> The future of Operating Systems will be the lineage of today's ChromeOS and FirefoxOS, not Windows or OSX.

Today was my first day using stock ChromeOS on a Pixel as my main machine. It was pretty great.

I hope you're right about this future.

Re: On “On Asm.js”

#25

Post by [deleted] »

fdej wrote: post #15

Naive question: is there a reason why we cannot just compile programs to both native/bytecode and javascript and have browsers automatically fetch the version they support? If it turns out that native/bytecode universally runs (say) 20% faster and loads in half the time, the javascript target will eventually die a natural death of obsolescence without compatibility ever being sacrificed. If it turns out that the java…

[deleted]

Re: On “On Asm.js”

#26

Post by azakai »

fdej wrote: post #15

Naive question: is there a reason why we cannot just compile programs to both native/bytecode and javascript and have browsers automatically fetch the version they support? If it turns out that native/bytecode universally runs (say) 20% faster and loads in half the time, the javascript target will eventually die a natural death of obsolescence without compatibility ever being sacrificed. If it turns out that the java…

Well, that seems to be what Google is doing with PNaCl and pepper.js. Pepper.js uses emscripten to compile PNaCl apps so they run in JS (specifically asm.js). In Chrome the PNaCl version can run, and everywhere else it runs in JS. That sounds like what you are proposing?

You can try that approach out right now,

http://www.flohofwoe.net/demos.html

http://trypepperjs.appspot.com/examples.html

Those two sites have the same codebases built for both PNaCl and asm.js. Overall they run pretty well in both, so this doesn't seem to show a clear advantage to either JS or a non-JS bytecode. PNaCl starts more slowly, but then runs more quickly, but even those differences are not that big. And surely both PNaCl will get faster to start up, and JS get faster to run, because there is no reason they both cannot get pretty much to native speed in both startup and execution.

Note though that there are risks to this approach. No one enforces that everyone create dual builds of this nature, and there is no guarantee that the dual builds will be equivalent. So while this is interesting to do, it does open up a whole set of compatibility risks, which could fragment the web.

Re: On “On Asm.js”

#27

Post by azakai »

jheriko wrote: post #14

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterl…

C is not sandboxed, and C has lots of undefined behavior. For those reasons, it is problematic for the web, which needs to let people view any site from any browser and platform, in a safe way.

People have tried to "fix" those issues with C, and usually they end up going pretty far, ending up with stuff like the JVM or CLR.

Re: On “On Asm.js”

#28

Post by PeterisP »

rolux wrote: post #23
PeterisP wrote: post #21

Earlier quoted context omitted.

Umm, is there any unicode encoding where finding n-th character (not codepoint) in string is O(1) ? In any encoding you can have a single 'composite character' that consists of dozens of bytes, but needs to be counted as a single character for the purposes of string length, n-th symbol, and cutting substrings. This is not a disadvantage of UTF-8 but of unicode (or natural language complexity) as such.

"UTF-32 (or UCS-4) is a protocol to encode Unicode characters that uses exactly 32 bits per Unicode code point. All other Unicode transformation formats use variable-length encodings. The UTF-32 form of a character is a direct representation of its codepoint." ( http://en.wikipedia.org/wiki/UTF-32 ) Of course, the problem of combining marks and CJK ideographs remains.

That's the point - you get O(1) functions that work on codepoints. Since for pretty much all practical purposes you don't want to work on codepoints but on characters, then codepoint-function efficiency is pretty much irrelevant.

I'm actually hard-pressed to find any example where I'd want to use a function that works on codepoints. Text editor internals and direct implementation of keyboard input? For what I'd say 99% of usecases, if codepoint-level functions are used then that's simply a bug (the code would break on valid text that has composite characters, say, a foreign surname) that's not yet discovered.

If a programmer doesn't want to go into detail of encodings, then I'd much prefer for the default option for string functions to be 'safe but less efficient' instead of 'faster but gives wrong results on some valid data'.

Re: On “On Asm.js”

#29

Post by pcwalton »

jheriko wrote: post #14

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterl…

> 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.

Re: On “On Asm.js”

#30

Post by jheriko »

pcwalton wrote: post #29
jheriko wrote: post #14

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterl…

> 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...
Post reply on HN