Actually, it's quite easy, you just have to drive slow enough to be able to brake before hitting anything that is in front of you. That would have avoided most of the accidents I've seen.
At speeds as "slow" as 30 mph (just under 50 km/h) you are moving at 44 feet per second ( ~13 m/s ), so if something goes wrong and it takes you half a second to react properly, you will travel 22 feet ( 7 m ) before your vehicle even begins to slow down.
In a really sporty car with great brakes and nearly new summer tires, on dry roads, it takes 100 feet (~30m) to come to a dead stop from 60 mph (~97 km/h). With all-season tires or worn brakes or a vehicle that is not a sports car, the distance to stop can be twice as long.
Being able to find someone that can get Javascript form validation to work on a text field in some klugy web page is different from getting someone that can write decent Node.js code.
But the same is true in the Java world. I've interviewed more than ten people that could read and write text from a file using Java but had never so much as built a rinky dink web application that prints "Hello World!" to a web page, and didn't know how to compile Java code without an IDE.
My understanding is that most number-crunching performance problems with Java (and I assume C#, though I don't know much about it) are from code that "boxes" the numeric data into the numeric object types. If you work with the primitive int, long, float, and double, and arrays of such, they're very fast. In Java world, I routinely find List vals =.... easier to work with in terms of code constructs than long [] vals =.... but I'm in web work and consistently 90+% of the time we spend answering requests is waiting for the database.
Good point. On the other hand, if you're going to be doing any client-side development and your UI is anything other than very simple, you are probably going to be working on an awful lot of Javascript code anyway. That gives Node the advantage that you're not switching your mental context from Javascript to Java and back as you switch from client to server. That's potentially a productivity win, if not a performance win.
No benchmark is flawless, but look at the computer language shootout ( http://benchmarksgame.alioth.debian.org/ ) or the TechEmpower web benchmarks ( http://www.techempower.com/benchmarks/ ) Java does very well in both. In the computer language shootout, in all eleven micro-benchmarks Java finishes within a factor of two of C++ - it uses dramatically more memory, but it runs very nearly as quickly.
In the TechEmpower benchmarks, in a few places the lone C++ entry has a strong lead, but nowhere does it trump the well-written Java entries by as much as a factor of three, and in some places it loses soundly to some Java entries.
Now there are a large number of applications when a 2-3x loss of speed are unacceptable and a much larger number of applications when a 5-40x increase in required memory are unacceptable. And the Java Virtual Machine HotSpot Just-In-Time compiler starts optimizing functions that have been entered 10,000 times, so for the first few seconds or minutes of operation a Java program runs more like an interpreted language than not.
So you have to ask yourself whether Java occupies the sweet spot between the execution speed of C++ and the developer productivity of, say, Python, Ruby, Perl, and PHP. I would say... no. But that's a much more complex topic to debate. I suspect the real sweet spot might be languages like Clojure and Scala, which hit all of the strengths of the Java Virtual Machine, tie in easily to existing Java libraries, but are much nicer to work with than Java itself.
I think it's the pauses. This is mostly speculation, but from what I understand Firefox runs very quickly but much of it is still single-threaded (or in simpler terms, most of what it does is running in a single sequential order). That means Firefox might be doing important calculations lightning fast in the background, but while those calculations are running the graphical window in front of you pauses temporarily. Chrome is better at multi-threaded, multi-process execution, so the user interface is responsive while background work happens.
Both might take 12 seconds to render a particular web page, but Chrome might load one visual element every few tenths of a second for the entire 12 seconds. Firefox will appear to load half the page, freeze for 9 seconds, then load the last bits. Either way you're done in 12 seconds, but Firefox gives the impression of being painfully slow.
I don't have a particular loyalty to Mozilla but I don't want to see "One Browser To Rule Them All", even if most of that browser (Chrome) is released as open source. Competition is good. I was shocked the Electrolysis was postponed and thrilled to see it back under development. Between that and the "Snappy" project linked from the main article above, Firefox has a real shot at continuing to challenge Chrome for the performance crown and (more importantly) behaving as responsively as Chrome in real world use.
I don't think so. Flash in Firefox crashed plenty for me on Linux. I finally switched to using two browsers at all times - Firefox for most stuff, and Chrome for Flash-intensive websites (mainly Youtube).
As the Anonymous Coward wrote, like it or not (and I definitely don't like it) Windows 8 probably already has a bigger share of the consumer desktop and laptop market than Linux. So it makes sense for Tom's Hardware to test on that platform.
As for the things that are tested, I think it makes sense to include all of their selected categories for two reasons. First, it can potentially show where the development team for a particular product is or is not expending resources. (e.g. If Internet Explorer 11 improves at the speed of DOM manipulation and nothing else, and DOM manipulation wasn't benchmarked, then it would look like Microsoft had done nothing for the new release.) Second, tracking and benchmarking the specific events that cause a slowdown or the impression of a slowdown in a browser is very hard to do. If Firefox and Chrome both take 7 seconds to load a page and Chrome loads it gradually while Firefox loads 90% in one second and then appears to freeze for 5 seconds and then finishes, most people who were not working with a stopwatch would report Chrome as being a dramatically faster browser.
I don't think Firefox has leaked memory for some time, except for some add-ons. If you've read any of the last few Browser Grand Prix comparisons at Tom's Hardware, Firefox has become decent.
But there was a long stretch when Chrome was clearly superior, and even now Firefox occasionally has some pauses that I just don't see in Chrome. I just hope Firefox continues to succeed because I don't want "one browser to rule them all", even if that browser is built on an open source core.
Funny, but I think the worry is that people will adapt QUIC for communications, websites, and programs that don't involve Google. Then if the protocol has security flaws, it's an engineered backdoor Google and the NSA can use.
Yes, I am not going to lose sleep over communicating with GMail via QUIC. I already assume anything I store there is in NSA vaults.
There's nothing stopping you from implementing your own flow control protocol in the data you send by UDP. TCP sends a periodic sequence acknowledgement of every set of packets it receives. If you implement your own flow control in UDP, you could have it only send back a message when it detects that some data was lost. Likewise, TCP connections maintain a little bit of state on each side. UDP does not, so the networking software in the client and server operating system has less work to do - just hand off the data to the application associated with that port for processing (although this is not "free", the application has to do its own processing of the data if you implemented your own flow control and so forth).
It doesn't make sense for somebody building a website in his garage, or even for a company at the smaller end of the fortune 1000. But for some company like Google that is handling mountains of network traffic, I bet QUIC might save them a big pile of cash by slowing down the rate at which they need to enhance their internal networking bandwidth.
Even if they know what it is, they may not care to get it. Many people already have a large financial investment in existing Android applications, a strong liking for the official Google apps for Android (especially Maps and Navigation, but also some of the others), and familiarity with the Android user interface. Plus of course they know the Android application store has a massive selection of applications.
That used to be Google's standard. Now it's less clear. They haven't provided an API for accessing Google Plus, and they're killing XMPP support for messaging. Those are moves towards the Apple and Microsoft -style walled garden approach to locking in their customers.
Android is open source, so Tizen can incorporate an Android software compatibility layer. However, in order to use the official Google applications for Android - the Maps app, Google Now, the official Gmail app, etc.... - you have to agree to certain contractual terms and I think if Samsung sold phones with Tizen and an Android compatibility layer, Google would yank the official Google apps off of all of the actual Samsung Android products.
There are tons of choices, but as a practical matter Samsung is dominating sales.
People are speculating that Google's acquisition of Motorola Mobility has Samsung and other Android partners worried. They're afraid that sooner or later Google will put the necessary resources into making sure Motorola has the best Android devices, and start crowding other Android vendors out of the market. If Google starts to do that, every Android sale by Samsung (and HTC, Sony, Huawei, LG, etc...) gives one more person using Google services on mobile, which increases Google ad revenue, which gives Google even more resources to spend ensuring that Motorola has the best Android products.
So the speculators have a theory that Samsung is focusing a token effort on Bada and Tizen and other vendors are exploring similar Android exit options in case that happens. I can understand the idea, but I don't think it is serious - if Samsung is annoyed by a drop in sales and they start promoting non-Android products, I think it will just hurt sales more. I like Tizen - but then I had heard of it before this article came out, unlike anyone in my social circle outside of Slashdot.
From the second to last paragraph in the article, "It is the case that patents usually have a 20 year life and therefore those that were in force in 1990 have now expired. However, modern implementations of old instruction sets could infringe on techniques that have been patented more recently by ARM or other companies – so I don't think the age of the instruction set is a water-tight defense."
For us, we chose Barnes & Noble to shop over Borders every time because Barnes & Noble had a better area to entertain young children. My wife would watch the kids in the children's area while I picked out some books, then I would watch the kids while she picked out some books. Our local Borders didn't get anything equivalent to less than six months before they went out of business.
Coupons are an annoyance, you have to do extra work to reap the benefits. I'd rather have an additional 5% discount on everything in the store that is active all of the time than the 10%, 15%, and 20% coupons that get emailed to me once a week but I have to remember to print and take with me.
I have a relative that used to work in their warehouse. To Amazon's credit, the wages are much better than minimum wage. On the other hand, the employees are under absurd pressure to work quickly and they get fired at the drop of a hat for failing to meet production quotas or laid off as soon as demand in their region drops. (My relative was laid off, re-hired, and laid off again in a two month period.)
I didn't buy a Nook until the recent fire sale because I didn't want to root the thing to access content I bought from Amazon and the Android marketplace. Once they opened Nook to the wider Google Play Store, I ordered one - but they only made the smart move after they decided to kill the product.
Slashdot Mirror
Actually, it's quite easy, you just have to drive slow enough to be able to brake before hitting anything that is in front of you. That would have avoided most of the accidents I've seen.
At speeds as "slow" as 30 mph (just under 50 km/h) you are moving at 44 feet per second ( ~13 m/s ), so if something goes wrong and it takes you half a second to react properly, you will travel 22 feet ( 7 m ) before your vehicle even begins to slow down.
In a really sporty car with great brakes and nearly new summer tires, on dry roads, it takes 100 feet (~30m) to come to a dead stop from 60 mph (~97 km/h). With all-season tires or worn brakes or a vehicle that is not a sports car, the distance to stop can be twice as long.
Being able to find someone that can get Javascript form validation to work on a text field in some klugy web page is different from getting someone that can write decent Node.js code.
But the same is true in the Java world. I've interviewed more than ten people that could read and write text from a file using Java but had never so much as built a rinky dink web application that prints "Hello World!" to a web page, and didn't know how to compile Java code without an IDE.
My understanding is that most number-crunching performance problems with Java (and I assume C#, though I don't know much about it) are from code that "boxes" the numeric data into the numeric object types. If you work with the primitive int, long, float, and double, and arrays of such, they're very fast. In Java world, I routinely find List vals = .... easier to work with in terms of code constructs than long [] vals = .... but I'm in web work and consistently 90+% of the time we spend answering requests is waiting for the database.
Good point. On the other hand, if you're going to be doing any client-side development and your UI is anything other than very simple, you are probably going to be working on an awful lot of Javascript code anyway. That gives Node the advantage that you're not switching your mental context from Javascript to Java and back as you switch from client to server. That's potentially a productivity win, if not a performance win.
No benchmark is flawless, but look at the computer language shootout ( http://benchmarksgame.alioth.debian.org/ ) or the TechEmpower web benchmarks ( http://www.techempower.com/benchmarks/ ) Java does very well in both. In the computer language shootout, in all eleven micro-benchmarks Java finishes within a factor of two of C++ - it uses dramatically more memory, but it runs very nearly as quickly.
In the TechEmpower benchmarks, in a few places the lone C++ entry has a strong lead, but nowhere does it trump the well-written Java entries by as much as a factor of three, and in some places it loses soundly to some Java entries.
Now there are a large number of applications when a 2-3x loss of speed are unacceptable and a much larger number of applications when a 5-40x increase in required memory are unacceptable. And the Java Virtual Machine HotSpot Just-In-Time compiler starts optimizing functions that have been entered 10,000 times, so for the first few seconds or minutes of operation a Java program runs more like an interpreted language than not.
So you have to ask yourself whether Java occupies the sweet spot between the execution speed of C++ and the developer productivity of, say, Python, Ruby, Perl, and PHP. I would say... no. But that's a much more complex topic to debate. I suspect the real sweet spot might be languages like Clojure and Scala, which hit all of the strengths of the Java Virtual Machine, tie in easily to existing Java libraries, but are much nicer to work with than Java itself.
And Chrome uses less?
Funny, from the same article linked above Firefox had near the best start time of the browsers tested.
Of course, that was on Windows 8. What are you running?
I think it's the pauses. This is mostly speculation, but from what I understand Firefox runs very quickly but much of it is still single-threaded (or in simpler terms, most of what it does is running in a single sequential order). That means Firefox might be doing important calculations lightning fast in the background, but while those calculations are running the graphical window in front of you pauses temporarily. Chrome is better at multi-threaded, multi-process execution, so the user interface is responsive while background work happens.
Both might take 12 seconds to render a particular web page, but Chrome might load one visual element every few tenths of a second for the entire 12 seconds. Firefox will appear to load half the page, freeze for 9 seconds, then load the last bits. Either way you're done in 12 seconds, but Firefox gives the impression of being painfully slow.
The good news is, per the article Firefox is putting a renewed investment in asynchronous operations: https://dutherenverseauborddelatable.wordpress.com/2013/04/10/announcing-project-async-responsive/ (same link as up top) and further up in the discussion someone mentioned that Firefox has decided to revisit their abandoned project to split individual browser tabs into separate threads and processes http://slashdot.org/comments.pl?sid=3929071&cid=44165865
The Browser Grand Prix tests by Tom's Hardware use a different platform with every test. e.g. http://www.tomshardware.com/reviews/android-web-browser-recommendation,3316.html (Android), http://www.tomshardware.com/reviews/macbook-air-chrome-16-firefox-9-benchmark,3108.html (Mac OS X), and http://www.tomshardware.com/reviews/chrome-17-firefox-10-ubuntu,3129.html (Ubuntu).
Windows gets the lion's share of testing because the lion's share of visitors to the Tom's Hardware website run Windows.
Hallelujah. (Not that I'm religious.)
I don't have a particular loyalty to Mozilla but I don't want to see "One Browser To Rule Them All", even if most of that browser (Chrome) is released as open source. Competition is good. I was shocked the Electrolysis was postponed and thrilled to see it back under development. Between that and the "Snappy" project linked from the main article above, Firefox has a real shot at continuing to challenge Chrome for the performance crown and (more importantly) behaving as responsively as Chrome in real world use.
I don't think so. Flash in Firefox crashed plenty for me on Linux. I finally switched to using two browsers at all times - Firefox for most stuff, and Chrome for Flash-intensive websites (mainly Youtube).
I have Win8 installed, though I don't boot into it often. If you look back on previous Tom's Hardware Browser Grand Prix comparisons, they don't always use Windows. e.g. http://www.tomshardware.com/reviews/chrome-17-firefox-10-ubuntu,3129.html (Ubuntu), http://www.tomshardware.com/reviews/macbook-air-chrome-16-firefox-9-benchmark,3108.html (Mac OS X), http://www.tomshardware.com/reviews/android-web-browser-recommendation,3316.html (Android).
As the Anonymous Coward wrote, like it or not (and I definitely don't like it) Windows 8 probably already has a bigger share of the consumer desktop and laptop market than Linux. So it makes sense for Tom's Hardware to test on that platform.
As for the things that are tested, I think it makes sense to include all of their selected categories for two reasons. First, it can potentially show where the development team for a particular product is or is not expending resources. (e.g. If Internet Explorer 11 improves at the speed of DOM manipulation and nothing else, and DOM manipulation wasn't benchmarked, then it would look like Microsoft had done nothing for the new release.) Second, tracking and benchmarking the specific events that cause a slowdown or the impression of a slowdown in a browser is very hard to do. If Firefox and Chrome both take 7 seconds to load a page and Chrome loads it gradually while Firefox loads 90% in one second and then appears to freeze for 5 seconds and then finishes, most people who were not working with a stopwatch would report Chrome as being a dramatically faster browser.
I don't think Firefox has leaked memory for some time, except for some add-ons. If you've read any of the last few Browser Grand Prix comparisons at Tom's Hardware, Firefox has become decent.
But there was a long stretch when Chrome was clearly superior, and even now Firefox occasionally has some pauses that I just don't see in Chrome. I just hope Firefox continues to succeed because I don't want "one browser to rule them all", even if that browser is built on an open source core.
Of course they're open! Look at the public API for Google Plus, and their pledge to support XMPP forever.
Oh, wait...
Funny, but I think the worry is that people will adapt QUIC for communications, websites, and programs that don't involve Google. Then if the protocol has security flaws, it's an engineered backdoor Google and the NSA can use.
Yes, I am not going to lose sleep over communicating with GMail via QUIC. I already assume anything I store there is in NSA vaults.
There's nothing stopping you from implementing your own flow control protocol in the data you send by UDP. TCP sends a periodic sequence acknowledgement of every set of packets it receives. If you implement your own flow control in UDP, you could have it only send back a message when it detects that some data was lost. Likewise, TCP connections maintain a little bit of state on each side. UDP does not, so the networking software in the client and server operating system has less work to do - just hand off the data to the application associated with that port for processing (although this is not "free", the application has to do its own processing of the data if you implemented your own flow control and so forth).
It doesn't make sense for somebody building a website in his garage, or even for a company at the smaller end of the fortune 1000. But for some company like Google that is handling mountains of network traffic, I bet QUIC might save them a big pile of cash by slowing down the rate at which they need to enhance their internal networking bandwidth.
Even if they know what it is, they may not care to get it. Many people already have a large financial investment in existing Android applications, a strong liking for the official Google apps for Android (especially Maps and Navigation, but also some of the others), and familiarity with the Android user interface. Plus of course they know the Android application store has a massive selection of applications.
How can Tizen compete with that?
That used to be Google's standard. Now it's less clear. They haven't provided an API for accessing Google Plus, and they're killing XMPP support for messaging. Those are moves towards the Apple and Microsoft -style walled garden approach to locking in their customers.
Android is open source, so Tizen can incorporate an Android software compatibility layer. However, in order to use the official Google applications for Android - the Maps app, Google Now, the official Gmail app, etc.... - you have to agree to certain contractual terms and I think if Samsung sold phones with Tizen and an Android compatibility layer, Google would yank the official Google apps off of all of the actual Samsung Android products.
There are tons of choices, but as a practical matter Samsung is dominating sales.
People are speculating that Google's acquisition of Motorola Mobility has Samsung and other Android partners worried. They're afraid that sooner or later Google will put the necessary resources into making sure Motorola has the best Android devices, and start crowding other Android vendors out of the market. If Google starts to do that, every Android sale by Samsung (and HTC, Sony, Huawei, LG, etc...) gives one more person using Google services on mobile, which increases Google ad revenue, which gives Google even more resources to spend ensuring that Motorola has the best Android products.
So the speculators have a theory that Samsung is focusing a token effort on Bada and Tizen and other vendors are exploring similar Android exit options in case that happens. I can understand the idea, but I don't think it is serious - if Samsung is annoyed by a drop in sales and they start promoting non-Android products, I think it will just hurt sales more. I like Tizen - but then I had heard of it before this article came out, unlike anyone in my social circle outside of Slashdot.
Agreed.
From the second to last paragraph in the article, "It is the case that patents usually have a 20 year life and therefore those that were in force in 1990 have now expired. However, modern implementations of old instruction sets could infringe on techniques that have been patented more recently by ARM or other companies – so I don't think the age of the instruction set is a water-tight defense."
For us, we chose Barnes & Noble to shop over Borders every time because Barnes & Noble had a better area to entertain young children. My wife would watch the kids in the children's area while I picked out some books, then I would watch the kids while she picked out some books. Our local Borders didn't get anything equivalent to less than six months before they went out of business.
Coupons are an annoyance, you have to do extra work to reap the benefits. I'd rather have an additional 5% discount on everything in the store that is active all of the time than the 10%, 15%, and 20% coupons that get emailed to me once a week but I have to remember to print and take with me.
I have a relative that used to work in their warehouse. To Amazon's credit, the wages are much better than minimum wage. On the other hand, the employees are under absurd pressure to work quickly and they get fired at the drop of a hat for failing to meet production quotas or laid off as soon as demand in their region drops. (My relative was laid off, re-hired, and laid off again in a two month period.)
Agreed.
I didn't buy a Nook until the recent fire sale because I didn't want to root the thing to access content I bought from Amazon and the Android marketplace. Once they opened Nook to the wider Google Play Store, I ordered one - but they only made the smart move after they decided to kill the product.