131–140 of 202 posts
It would be interesting to see an implementation of this on ARM platform. Firefox OS powered mobile device would be really promising with this optimization.
It seems Mozilla and Google are moving more and more toward their own browser specifications and mechanisms. Microsoft and Netscape did this in the 90s, and it ended up causing nothing but pain. Optimizing JS is interesting, but creating browser-specific applications of code meant for a web audience disturbs me. I don't want a repeat of the first browser wars. Hopefully Mozilla will work toward w3 standards in this e…
As far as I know, asm.js is a strict subset of JavaScript -- I don't believe it's "browser-specific" in a meaningful way. Rather, it shows that it's possible to take a subset of JavaScript and make it run at near-native speeds, which means that there's still a lot of room left for the VMs to improve. From glancing at the benchmarks in the Ars article, it looks like asm.js generally runs around twice to four times as…
Additionaly browser games can't have main game loop (cause it would hang the browser infinitely), but often use "requestAnimationFrame" to trigger updates with the best sustained refresh rate available. Even if only one frame out of every 10 in your game is taking 20 ms instead of 16 ms - your game won't run with 60 fps anymore, but with 45 fps or 30 fps because browser is trying to choose refresh rate that will work. And that's a big difference in experience.
BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker). http://cdn.arstec…
> anyone writing performance sensitive apps will use MT right? No, multithreading not that simple - usually it's the last trick you should try to pull and even then only if the stars align just right. You need to have expert programmers on hand (of the rare breed who can pull this off), the good luck to succeed and the time budget to spend on the big code reachitecting and experimentation. If you're running on someth…
BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker). http://cdn.arstec…
> anyone writing performance sensitive apps will use MT right? No, multithreading not that simple - usually it's the last trick you should try to pull and even then only if the stars align just right. You need to have expert programmers on hand (of the rare breed who can pull this off), the good luck to succeed and the time budget to spend on the big code reachitecting and experimentation. If you're running on someth…
Earlier quoted context omitted.
> anyone writing performance sensitive apps will use MT right? No, multithreading not that simple - usually it's the last trick you should try to pull and even then only if the stars align just right. You need to have expert programmers on hand (of the rare breed who can pull this off), the good luck to succeed and the time budget to spend on the big code reachitecting and experimentation. If you're running on someth…
I think you are overstating the problems writing multithreaded code a little here. Yes, it's a lot harder than single-threaded code, yes you need to know what you are doing, yes you need to carefully design your code to enable efficient and safe multithreading, and no you don't get speed for free. All true, but you are making it sound as if writing multithreaded code is rocket science, some kind of mad skill only the…
I'm betting the minority is less than 0.5%. Half way decent C++ programmers aren't many % of programmers, and people who can make a reliably working parallelized do-over for a nontrivial code base are maybe 1% of that. I'll say 0.05% max.
Earlier quoted context omitted.
The parent's comment was that it is essentially infeasible to have a single div follow the cursor due to performance issues with the DOM. The fiddle includes 160 divs and opacity to demonstrate that that claim is false. There's an awful lot of red herring going on in your post. It sounds like you have some problems with the web, but they most certainly aren't relevant to this discussion.
Oh I have no problems with the web, it has been providing me with a good living for well over a decade. Maybe that's my problem - that I remember the times when things that are being described now as 'great' or 'fast' were solved already, and my frustration is that instead of moving forward, we now have to repeat the last decade except with js/css before we can really start to innovate again. Unreal engine in the bro…
And developers win because there are more viable businesses which need their skills over the long term.
Should it be possible to sell a native app as a service? Maybe, but supporting a native app professionally is much more difficult than you seem to be acknowledging. Have you ever supported a native app in the wild across a wide variety of generic PC hardware for novice users?
Earlier quoted context omitted.
Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?
> why would anyone write in a crippled C-like subset of javascript Because asm.js is not meant for people, but for compilers. For example the Unreal Engine has been recently compiled from C/C++ to asm.js and is running in the browser: http://www.unrealengine.com/html5/
Earlier quoted context omitted.
Oh I have no problems with the web, it has been providing me with a good living for well over a decade. Maybe that's my problem - that I remember the times when things that are being described now as 'great' or 'fast' were solved already, and my frustration is that instead of moving forward, we now have to repeat the last decade except with js/css before we can really start to innovate again. Unreal engine in the bro…
If an app that had no sustainable future as a native app becomes possible as a web app, don't users also benefit? The fact is that many people are willing to pay for a service they continue to get value from month after month. And the recurring revenue also usually comes with recurring support because companies have to keep winning customer loyalty in a way they never have to with a one time sale. I think it is a net…
Of course they do, therefore charging for software (desktop & web alike) = good. Make no mistake on which side in that debate I'm on. But let's call it like that.
"And developers win because there are more viable businesses which need their skills over the long term."
Sure, and it's no more than fair, and the natural order to boot.
"Have you ever supported a native app in the wild across a wide variety of generic PC hardware for novice users?"
I'm glad you ask, because actually yes I do, and it's a pain in the ass for the most part. And for the parts where it makes sense, I have moved parts of the services we offer to web applications. Therefore I feel I'm experienced enough to compare the advantages and disadvantages of the two, and from that I criticize the developments of people wanting to shoehorn everything into the browser, either because of covered up ulterior motives, or because it's all they know and want to know. But again - then say so, and don't sugarcoat it under the fuzzy 'it's better for the user' rhetoric that is so prevalent.
BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker). http://cdn.arstec…
anyone writing performance sensitive apps will use multithreading That assumes the performance sensitive app is amenable to multithreading. Many aren't.
Earlier quoted context omitted.
I have about 300 tabs open on my Firefox, and the Gecko Profiler is active. Things are running very smoothly, thank you very much. So, my best guess is that you have an add-on killing your performance and stability.
Nope, I ran no addons.
When exactly was this? Also FF is moving very rapidly, I remember FF 19(possibly 20) with no addons being way slower on my laptop than Chrome while its nightly at the time - FF 22 (or 23-24) ran blazingly fast (with same addons as FF 19) on par with Chrome.