Hacker Newsnew | comments | show | ask | jobs | submit | marcosscriven's comments login

>What's impressive is the raw math performance of asm.js

I continue to be staggered at how well asm.js performs, and really glad Chrome has taken on optimising for it as well as Firefox.

-----


Running the instancing demo on an iPhone6+ I can get to 150k particles before dropping below 60fps. There's an obvious speed up about three seconds in where I guess the JITter decides to get serious.

So, even though there's no official support for asm.js on mobile safari. It still works surprisingly well!

-----


I lived and worked in Sydney for a year or so, and used iiNet while I was there. They had a mirror of free software, and also zero-rated most iTunes content. With most ISPs there having caps (mine was just 100GB), it was difficult to not see this as a benefit, but overall of course it's far from ideal.

The other problem was just terrible speeds; best I could get in a central district was ADSL2+, with about 16/0.8 mbit d/u, and that's not including the terrible latency issue you had to deal with for a whole host of US and EU based websites and services.

Then again, I'm back in London now with a 150/15 mbit d/u connection for under £30, no caps in sight.

-----


The idea of legal tender not being recognised reminds me of a situation here in the UK.

The Bank of Scotland prints its own notes, but are rarely in circulation in the rest of the UK. Somehow it's mildly amusing passing over a Scottish fiver to an unsuspecting checkout assistant in London, and the ensuing suspicion.

-----


A minor point: that's not what legal tender means.

http://www.royalmint.com/aboutus/policies-and-guidelines/leg...

The shops are free to reject the note, and possibly to lose your custom.

-----


Thanks for the correction, interesting.

-----


Just trying to reconcile the unanimous negative comments (at the time of writing), with the 14 points/front page position. Does this just mean a voting ring is promoting it?

-----


You can surprisingly effectively cross-compile C and C++ to Javascript now, with Emscripten.

-----


The point is to AOT compile to native code.

-----


In fact that's exactly what it does: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...

-----


When talking about AOT compilation, we generally tend to mean that the compiler produces a binary consisting of machine code at some unspecified time before the user attempts to run the application.

In the context of that blog post, there are two compilation steps: First emscripten would be used to produce JS. Then Mozilla's JS engine would compile that JS down to machine code at runtime.

They call the latter step with OdinMonkey AOT when they compile the entire thing at runtime, but before starting execution. But the way most people differentiate, this would still be considered JIT - it still depends on executing the compiler each time the application is started.

-----


The point I was trying to get across is that by cross-compiling from C/C++ with Emscripten, static type information can be used to give native performance, that a program written directly in Javascript wouldn't. It's still AOT in that sense - it's not like JIT where only hot bits of code get converted to native to code, and only then when some heuristics have determined what actual types the code ends up dealing with at runtime.

-----


But it isn't AOT in CS speak.

-----


I'm not sure how you claim to be the authority on 'CS speak', but it's a sufficiently blurred line here, for reasons I clearly explained and which you seem unable to understand. Emscripten/asm.js can use static information to generate Javascript which can be compiled to native code, before the code in question is run, aka Ahead of Time.

-----


Well, I majored in compiler design.

Ahead of time compilation is used to describe the process of generating machine code at compilation time, in a form that can be executed directly by a processor without any additional transformation process.

Which clearly is not happening here, as the code is converted into JavaScript and relies on a JavaScript implementation to run. Regardless of the optimization processes used by the JavaScript engine.

-----


The nuances unfortunately appear to escape you.

-----


I wasn't aware there was a CPU that could run that code natively without a JIT translation layer.

-----


There isn't, perhaps you're getting confused again.

-----


Looking at this 'virtual' text editor the text looks pretty smooth, until you get really close. Would it be possible to import typefaces as paths, and antialias them?

How do native apps do this, while also using hardware acceleration? Also, native apps can access sub-pixels for antialiasing, which I don't think is possible in a WebGL context.

I've seen OpenGL GUIs before, but I wonder what limits them compared to native apps, particularly when it comes to text and sub-pixel antialiasing.

-----


Actually, there is another open source project in the world that does that. It's called fontpath, I believe, and it reads OTF files directly. I'm considering switching to it, as the HTML5 Text API isn't hardware accelerated and a huge amount of the processing time is being spent in the fillText method.

https://github.com/mattdesl/fontpath

-----


I look forward to the day the whole concept of getting pieces of paper from a machine in a wall is looked upon as a vaguely amusing aspect of the past.

-----


ah so your the one fumbling with a credit card and holding every one up at the bar when I want to get a round in.

Personally I like having access to cash reduces the attack surface for me when compared to handing over my card for every transaction and DONT! get me started on NFC credit cards that can be debited with NO interactinon

-----


> ah so your the one fumbling with a credit card and holding every one up at the bar when I want to get a round in.

Here in Canada I just tap my card on the machine and walk away - much, much faster than trying to count out the right amount of cash, then waiting for change, etc.

> and DONT! get me started on NFC credit cards that can be debited with NO interactinon

Let me guess, you also didn't like when it was possible to make CC payments over the phone with no signature (!)

And you also didn't like when it was possible to make CC payments over the web with no signature AND no actual human (!!!!!!)

Things progress, get with the program.

-----


You do know the Chaos Club in berlin demoed a nfc harvester years ago walk through a crowd of unsuspecting commuters and take 5 pounds from everyone.

BTW I have developed a Paperless direct debit system so I do know what the flip I am talking about.

-----


It's a risk, but you can fix it on the backend, away from the end-user. If they were bitcoins then sure you need interaction for NFC. But credit cards are a closed system on the merchant side, any new identity pulling only NFC traffic would be very suspicious. NFC would always be an expected proportion of overall captures. So it's simple to defend against this attack without killing the feature.

-----


Same happened to me trying to use Safari Books Online on my Kindle browser (as the only official way yo access their content on an eInk display). They dropped SSLv3, and in doing so the old 'experimental' Kindle browser can no longer access it.

-----


I couldn't help but notice the 2006 MacBook Pro with front-loading CD-ROM drive.

-----


Why all your submissions on asm.js?

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: