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

41–50 of 64 posts

Re: On “On Asm.js”

#41

Post by qznc »

willvarfar wrote: post #38
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…

"Text normalization in Go" https://news.ycombinator.com/item?id=6806062 was here yesterday and made me wonder: how can you handle ligatures, accents, digraphs etc in fixed-width? Perhaps text parsing is just a hard problem?

Yes it is hard. Instead of code points, humans usually handle text by graphemes, which have an arbitrary length in edge cases [0] no matter what encoding is used. An O(1) solution for graphemes would be an array of pointers to grapheme objects, which is slower and more memory hungry than necessary in most cases.

[0] http://stackoverflow.com/questions/6579844/how-does-zalgo-te...

Re: On “On Asm.js”

#42

Post by CmonDev »

cdash wrote: post #31
azakai wrote: post #26

Earlier quoted context omitted.

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 s…

Except for the fact that you can not compile threaded programs to javascript I am pretty sure while you can to PNaCl and this is my problem with this talk of asm.js, until it supports threads I don't really consider it an acceptable solution.

And people keep mentioning those 'Web Workers' as if Emscripten is capable of generating them from LLVM thread abstractions.

Re: On “On Asm.js”

#43

Post by fulafel »

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…

Add ActiveX -> IE6 support & native performance!

Re: On “On Asm.js”

#44

Post by CmonDev »

steveklabnik wrote: post #17
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…

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?

Re: On “On Asm.js”

#45

Post by CmonDev »

pcwalton wrote: post #9
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.

> Mozilla is too much focused on Brendan Eich baby. They should really move forward because JavaScript is becoming new IE6. How is a language which all browsers implement comparable to an obsolete browser? In any case, JavaScript is alive and well. Look at the continuous growth of node.js: http://www.google.com/trends/explore?q=node.js

Because it is equally crappy? IE6 was alive and well for _quite_ a while.

Regarding node.js: http://pages.citebite.com/b2x0j8q1megb

Re: On “On Asm.js”

#46

Post by [deleted] »

qznc wrote: post #41
willvarfar wrote: post #38

Earlier quoted context omitted.

"Text normalization in Go" https://news.ycombinator.com/item?id=6806062 was here yesterday and made me wonder: how can you handle ligatures, accents, digraphs etc in fixed-width? Perhaps text parsing is just a hard problem?

Yes it is hard. Instead of code points, humans usually handle text by graphemes, which have an arbitrary length in edge cases [0] no matter what encoding is used. An O(1) solution for graphemes would be an array of pointers to grapheme objects, which is slower and more memory hungry than necessary in most cases. [0] http://stackoverflow.com/questions/6579844/how-does-zalgo-te...

[deleted]

Re: On “On Asm.js”

#47

Post by mercurial »

PeterisP wrote: post #39
mercurial wrote: post #37

Earlier quoted context omitted.

For a lot of usecases, you're just dealing with ASCII though (hello HTML). Wouldn't it be possible, in a string implementation, to have a flag indicating that the string is pure ASCII (set by the language internals), thereby indicating that fast, O(1) operations are safe to use?

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 (though I don't know by how much something like == takes a hit when dealing with non-ASCII), or when dealing with text nodes which don't have special characters.

I'm happy not to pay a performance price for things I don't use :)

Re: On “On Asm.js”

#48

Post by LionRoar »

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)

I can totally understand your frustration that shines through. Basically I agree with you. 8 years ago I saw the start of an explosion of new languages/frameworks/etc. All solving 1 of more things of a bigger problem. To my mind it became too fragmented, too many layers where too many things can go wrong and if not, will have a performance penalty.

So I went to a more abstract approach by working visually in models. After some tries I discovered the OutSystems development environment for web applications and am working with it since on a daily base. The advantage of working visually is that I don't know or see what the compiler creates. (of course I encounter some SQL, JS, CSS and HTML)

However, sometimes I miss text based coding, so this year I looked around to see if the development situation had become better. In my opinion it has not. There seems to be less fragmentation but that's probably caused by the fact that only a select set survived. Besides that new initiatives have been started.

Personally I like the idea of using C as a cross platform language; because it already IS. However, I wouldn't be surprised if the lower levels of the used languages use it already in some form (remember it always needs to go native). Besides that, I think that if C would be the standard then within a couple of weeks you will have language X to C compilers and then have ABC->X->C and then have a webvariant WEB->ABC->X->C while undoubtedly someone will create a Javascript to web to abc to x to c compiler. And than there we are again where we started :)

So in my opinion the problem lays with the chains. Some abstraction is needed of course but not several layers on layers. I would like to see more direct to (e.g.) c compilers: JS->C, Web->C, ABC->C, X->C whereby it is not the goal to program in C but have it as an intermediate format.

I believe that software development has not grown forward enough. There is plenty movement left and right but not going forward. So, I am back to my visual modelling environment and will check later on...

Re: On “On Asm.js”

#49

Post by flohofwoe »

CmonDev wrote: post #42
cdash wrote: post #31

Earlier quoted context omitted.

Except for the fact that you can not compile threaded programs to javascript I am pretty sure while you can to PNaCl and this is my problem with this talk of asm.js, until it supports threads I don't really consider it an acceptable solution.

And people keep mentioning those 'Web Workers' as if Emscripten is capable of generating them from LLVM thread abstractions.

Nope, it's a better idea to create a higher level thread-pool-based parallel-task-system which abstracts away the differences between pthreads and WebWorkers. I think that at least most game engines have such a system in place anyway, and can be relatively easily adopted. YMMV because it may be more overhead to get data in and out of WebWorkers since they don't have a shared address space (so in that regard they are more like processes).

Re: On “On Asm.js”

#50

Post by antimagic »

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…

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 that lookup becomes O(1). With enough mucking around you can even get insertion to be O(1).

For the remaining use cases of strings (the vast majority - filenames, URLs, UI labels, database fields), O(n) performance is perfectly adequate. This is why UTF-8 is such a successful hack.

Post reply on HN