Live data from Hacker News

Mozilla can produce near-native performance on the Web

arstechnica.com

161–170 of 202 posts

Re: Mozilla can produce near-native performance on the Web

#161
post #150
post #111

Earlier quoted context omitted.

Consider a single tab of a web browser, for instance. By specification, much of the code must run in the same thread. Keeping the semantics while getting code out of the thread is extremely difficult, often impossible. I should know, that's my dayjob :)

So the reason you can't make it faster than JavaScript by multi-threading it is... because of JavaScript? :-) I had a look at your profile and it looks like you're doing some very valuable work. I was rather hoping for some examples which didn't involve JavaScript, though.

It used to be that almost all PC games were single threaded. Many still are: Civilization 4, Dwarf Fortress, and Morrowind, for example.

Re: Mozilla can produce near-native performance on the Web

#162
post #157

Earlier quoted context omitted.

First of all clang and LLVM support the GCC vector extensions which means you can write portable SIMD code: http://clang.llvm.org/docs/LanguageExtensions.html#vectors-a... Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) and in addition SSE is used even for scalar floating point operations these days. It doesn't look lik…

> First of all clang and LLVM support the GCC vector extensions which means you can write portable SIMD code It's portable in one sense, but not another - it doesn't work in other compilers like MSVC, which was used in this article. > Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) Yes, if the native compiler did auto v…

Ah, I didn't know PNaCl didn't have explicit SIMD through vector types yet. Sounds like it should be relatively easy to add though since LLVM already provides them.

Re: Mozilla can produce near-native performance on the Web

#163
post #20

I would much prefer having a sane new language replacing JavaScript instead of this hack to improve performance. A new language could provide the same performance advantage and make writing web applications much more pleasant. Admittedly it is harder to introduce a new language across all (major) browser but I think it would really be worth it.

I'd vote for LuaJIT as a new, sane, replacement for JavaScript.

Re: Mozilla can produce near-native performance on the Web

#164
post #103
post #45

Earlier quoted context omitted.

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

My profile is apparently constantly being corrupted. If I have to wipe Firefox's data on me every other day because of profile corruption then what is the point? If addons are guaranteed to mess things up then why does Firefox have that feature?

Let's be honest, this isn't meant to be helpful, it's just meant to shift blame back to the user.

Re: Mozilla can produce near-native performance on the Web

#165
post #140

Earlier quoted context omitted.

Nope, I ran no addons.

You seem to say "ran" which implies it was a some time in past. 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.

I switched to Chrome shortly after FF 3.6 and have only looked back 3 or 4 times since.

Re: Mozilla can produce near-native performance on the Web

#166

Earlier quoted context omitted.

Sure, you can write the code if you're a half-way decent programmer. But getting it to work correctly and bug free in presence of nondeterministic behaviour and races is in the domain of the very small minority, when you're talking about large code bases. 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…

The challenge is to design your code in a way that either makes it impossible to end up with race conditions or non-deterministic behavior, or if at least limit the number of possible points-of-failure. This requires a good understanding in what coding styles and data structures to avoid or pay extra attention to, but if you're aware of the pitfalls, it's actually not all that difficult. Just make sure your workers d…

I was talking about the percentage of existing programmers with the abilities to pull it off. I'm sure more than 0.05% have the potential to learn it eventually, given enough time, motivation and opportunity. Like musicians & theremin!

Re: Mozilla can produce near-native performance on the Web

#167
post #109

Earlier quoted context omitted.

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?

Many things are hard to parallelize using current technology, and there indeed has been lots of research done on it. History goes back to the supercomputer era (Cray, Connection Machine, Transputer etc.)

The term of art is "inherently sequential" problems (vs "embarrassingly parallel").

In addition, the programming effort gets untenable quickly due to Amdahl's law when the amount of parallelism increases. Eg. if you have 100 cores, even if only 1% of work in your program is sequential, your performance goes down the drain. Currently we're in the comfy phase of the curve with few cores...

We've been making good progress with parallel-minded reimaginings of programming languages and computer architectures on one front: GPUs. On the CPU we are saddled with the inertia and backwards compatibiltiy lock-in of tools and culture (witness lasting use of C++ as a tool to write parallel software)

Re: Mozilla can produce near-native performance on the Web

#168
post #155

Earlier quoted context omitted.

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

Your premise is demonstrably wrong > 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. The…

Demonstrably wrong? Remind us how many years it took to get rounded corners into CSS?

>The innovation in browsers and webapps is coming from the vendors

Yes, which does not contradict what I said at all: "the people defining the standard (who also happen to be big players in many other related markets)". The vendors are big industry players who have their own agendas that rarely coincide with my interests (yes even Mozilla). They also get to veto any proposal they don't like.

The Kinect has been available for years now, which is an age in the consumer tech space. Where is the open standard web API? Do you see how it might be difficult to get Mozilla, Google and Apple to agree to standardise, implement and support an API for proprietary Microsoft technology? Creating a specific API for every type of device (photo cameras, video cameras, accelerometer, touch screens etc) and not providing a low level interface to hardware is the wrong route to take. High level APIs are fine, but it is important to also provide the ability for people to extend platform support in new and unforeseeable ways, and that requires lower level access.

WebRTC is another excellent example of conflicts of interest with Microsoft opposed to it because it challenges Skype (or because it is technically deficient, depending upon which side you are on). The difference between the web as a platform and real open operating systems is stark. If Windows had been like the web -- locked down with only a limited set of approved APIs -- then Skype could not have been created unless Microsoft decided to allow it. Substitute Microsoft for Apple/Google/Mozilla/Microsoft and you have the situation we have with the web.

Perhaps some people don't see the this because of the tribal nature of technology discussions. People don't see the web as being restrictive because their 'team' (be that Apple or Google or Microsoft or Mozilla) has a say in it. So most arguments devolve into discussion about how X is blocking a proposal by Y and the proposal is either good for the web or bad for the web depending on whether you favour X or Y. Few people seem to stop and wonder why we are creating a system where X can veto technologies, even for people who don't use a single product created by X.

>If you as a developer, are waiting around for them all to agree on any technology, before leveraging it, then you are just paralyzed. Develop against WebGL and asm.js now to get early mover advantages.

How does developing against asm.js and WebGL help me interface with new input devices? It doesn't help me one bit. All it does is let me create a faster shinier version of current webapps (that only runs in certain browsers). This is a reoccurring argument though: the web will be a decent platform once we finally get $NEW_API_PROPOSAL that fill fix everything 'once and for all'.

Re: Mozilla can produce near-native performance on the Web

#169
post #164
post #103

Earlier quoted context omitted.

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

My profile is apparently constantly being corrupted. If I have to wipe Firefox's data on me every other day because of profile corruption then what is the point? If addons are guaranteed to mess things up then why does Firefox have that feature? Let's be honest, this isn't meant to be helpful, it's just meant to shift blame back to the user.

s/(shift blame back to the user)/be passive agressive and \1/

Re: Mozilla can produce near-native performance on the Web

#170
post #65

Earlier quoted context omitted.

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…

The problem is that the DOM is a hard upper limit on performance compared to what the performance of an unsafe language (asm.js) is. It is massively complex because it must perform every UI task in the browser and simply moving around DIVs doesn't give you a feel for its the performance in complex scenarios. If you think about how native applications perform and then imagine every one having to go through a DOM inter…

asm.js is not an "unsafe language".

/be

Post reply on HN