No it can't. C is not the speed limit.
Top native performance is achieved by an ungodly combination of SIMD intrinsics, compiler-assisted optimization, cache-aware data-structures and assembly.
Mozilla can produce near-native performance on the Web
101–110 of 202 posts
Re: Mozilla can produce near-native performance on the Web
#102Earlier quoted context omitted.
> Would be great if Chrome had this option off by default. Disabling Vsync causes page tearing artifacts ( https://en.wikipedia.org/wiki/Page_tearing ). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.
isn't tearing preferable to input lag? As I mentioned, with v-sync on there is a very noticeable rubber-banding effect, with it off the result is (perceptually) far smoother. >It [vsync] should always be enabled by default Not sure about this. Surely the goal is to maximize perceived performance not 'correctness' (where correctness in this context is defined as each frame being fully drawn before the next one starts)…
> isn't tearing preferable to input lag?
In a properly written app, vsync should not cause input lag despite gamer superstitions. But there are lots of not-properly written apps where this is a problem.
WebGL / Chrome should solve the problem in some other way, not disabling vsync. Or using adaptive vsync if available as a workaround.
The culprit here might be the ANGLE OpenGLES2-on-D3D9 wrapper that Chrome uses, which is notoriously slow on synchronous operations like vsync, glGetError or glFinish.
Re: Mozilla can produce near-native performance on the Web
#103Why don't they first produce near-Chrome performance for their browser? Every time I use Firefox, it slows down to a snail's pace and eventually crashes if there are more than 4--6 tabs open.
Exactly. I don't know how I'm supposed to trust them "making the web faster" when I can't scroll up and down a page.
You may have an addon that is leaking memory or your profile may be corrupted. Consider restarting without any Addons or try the Reset feature to start with a new profile but with your key user data migrated. https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...
Re: Mozilla can produce near-native performance on the Web
#104BTW, 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…
It's good progress all the same, but doesn't do much for the end user that still relies on an often shitty Internet connection.
Re: Mozilla can produce near-native performance on the Web
#105For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag. I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which pre…
Like this? http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, an…
For me the movement is smooth but it still lags behind the mouse with 10-20 px. The Firefox version of the demo has a little less lag but still looks disconnected from the mouse when moved.
Re: Mozilla can produce near-native performance on the Web
#106BTW, 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…
Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. The Ars article here even has "surprise" in the title when it concludes that in fact that is possible :) So that is a crucial milestone.…
>The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed.
Single threaded Javascript was already 'fast enough' for the CRUD interfaces that makes up most web apps. Web apps are horrible to use because the network is unreliable for many people, latency is terrible for just about everybody, browsers provide a very poor and limited set of APIs for many of the tasks people actually want to do (interacting with hardware, file systems, audio, inter-app interoperability etc) and apps are forced to run inside a sandbox that can't be escaped. Cloud services nearly always mean that users lose control of their data. Web apps are rarely open source (and if they are you still can't change the version of the app that you actually use because it runs on a server you don't control). A faster Facebook with 3D effects is still a terrible platform.
Homer Simpson: Kids: there's three ways to do things; the right way, the wrong way and the Max Power way!
Bart: Isn't that the wrong way?
Homer Simpson: Yeah, but faster!
I think a lot of this obsession over Javascript speed is a distraction (support for more languages is nice for developers of course). Making slightly faster VMs is just an engineering problem: throw more resources at it and things will improve. The hard problems are political and also related to the basic network infrastructure (constrained by the laws of physics). Trying to recreate the entire operating system inside the browser, for all possible uses (even performance sensitive things), is a huge overreach when we don't seem to have a clue how to make the basic web app experience good. Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. If the world had moved to Gopher based OSs in the early 90s the web as we know it would not have come into existence. What future possible technologies are we destroying by locking ourselves into the web sandbox?
Re: Mozilla can produce near-native performance on the Web
#107Earlier quoted context omitted.
> My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise. These operations are extremely well-optimized. The reason they're slow is that they're also extremely complex and slow operations. It's not something you can hack around.
> The reason they're slow is that they're also extremely complex and slow operations. In that case it seems that we need something new to replace CSS for layout. Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width,…
So we need asm.css? :)
Re: Mozilla can produce near-native performance on the Web
#108Earlier quoted context omitted.
What makes web apps feel like swimming through molasses is the DOM. In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.
Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps. My understanding is that parsing CSS rules…
> Very few web applications are CPU bound to the point of locking the UI.
It comes up regularly around here. We've had to resort to all kinds of ugly workarounds (such, as, e.g. chunking work and running small pieces off setTimeout() or requestAnimationFrame). A simple thing like changing fonts on the Canvas more than a couple of things can kill any hope of a responsive UI unless you very carefully manage your rendering, depending on browser (Canvas font handling is ok on Chrome, and ridiculously slow on Firefox, for example).
Re: Mozilla can produce near-native performance on the Web
#109BTW, 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.
Your comment has made me curious. I tried to think of some examples of performance sensitive apps that aren't amenable to multi-threading and I couldn't, but it seems like they could offer interesting areas for R&D. Can you share some examples?
Re: Mozilla can produce near-native performance on the Web
#110Earlier quoted context omitted.
I don't understand this stuff well enough, but doesn't Emscripten effectively give you that? It converts LLVM bitcode into JavaScript, so if you can compile it with LLVM, you can use it on the web.
That's correct, you can compile many things to JavaScript. But I think this is a suboptimal solution - besides paying the performance penalty because you have the hard-to-optimize JavaScript in the stack it makes development harder, for example debugging generated code in the browser is unnecessarily hard.
> besides paying the performance penalty because you have the hard-to-optimize JavaScript in the stack
Well the article proofs you quite wrong.