I expect some of these shortcomings to be fixed when Amazon updates the Kindle Fire OS to Android 4.0. Other than that, I wasn't really surprised in the results. Android 2.x isn't that great when it comes to supporting modern standards. Performance is subpar and only masked on phones because of processors that range from 1.2-1.5Ghz to make up for the OS' shortcomings.
Considering Apple gets better performance only running it's CPUs at 800Mhz, it's pretty clear to me that software matters a LOT. Heck, Windows Phone 7 devices are smoother than most Android smartphones and they only have a single core (but hardware acceleration!).
It's the software, stupid!
Are you really that stupid? The fire runs a special Amazon modified version of Gingerbread and cannot be upgraded to ICS.
What makes caching work, however, are lots of reqrests for the same pages -- so Amazon can just deliver from the server cache to the device (no need to re-retrieve and rerender the pages)
I suspect that there is not yet enough Fires in use to maintain enough meaningful cached pages.
Unless:
The route to the cache is longer than the route directly to the site.
The route from the cache to the site is longer than yours.
The cache's DNS lookups are slower than your ISP's or a local DNS cache.
The cache's server is under a heavy load.
The cache is down or the route to it is unreachable. Is Silk smart enough to try another method? Even if it does, it adds delay.
Silk is unable to reach the content due to certain geogpahic restrictions (YouTube is an good example of this) and returns you an error page, even though you are in a whitelisted country.
A site simply does not play well with proxies.
The cache is malfunctioning and out of date.
You're adding a massive point of potential failure into an ordinarily dead simple process. In most cases it is nothing more than a middle man; the performance gains are so minor that Amazon has no inventive to do this other than for data collection.
I checked out the Android 4.0.1 source and had a look. They're using v8 version 3.2.10, from October 20, 2011 - http://code.google.com/p/v8/source/detail?r=9719. For comparison, the current stable version of Chrome (15.0.874.121) uses v8 version 3.5.10.24, which has several performance improvements. Android 4.0.1 isn't yet using the NEON-optimized support libraries, such as libjpeg-turbo (http://libjpeg-turbo.virtualgl.org/). I'm not sure why this is, but I suspect Google will upgrade their external libraries in a future version.
Of course, when they do that, I'm sure the fair-minded folks here will be sure to reevaluate their opinion of Android based on the evidence, right?
Who cares what Google does? Amazon itself decides what version of Android their devices support. Amazon's version is their own customized version of Gingerbread. No vendor has announced an upgrade to ICS from Gingerbread. A major reason is that the Gingerbread HW won't support ICS.
You don't want an email client for too much on a tablet with such limited storage anyway. All it does is fill up mailboxes on what little space you've got on the device, and they want you to use the storage for content. They assume you'll use the browser for email.
But just get an email client and use it, if need be. There are plenty.
True. I guess thats where the cost issue comes in. Limited storage = lower cost.
The route to the cache is longer than the route directly to the site.
The route from the cache to the site is longer than yours.
The cache's DNS lookups are slower than your ISP's or a local DNS cache.
The cache's server is under a heavy load.
The cache is down or the route to it is unreachable. Is Silk smart enough to try another method? Even if it does, it adds delay.
Silk is unable to reach the content due to certain geogpahic restrictions (YouTube is an good example of this) and returns you an error page, even though you are in a whitelisted country.
A site simply does not play well with proxies.
The cache is malfunctioning and out of date.
You're adding a massive point of potential failure into an ordinarily dead simple process. In most cases it is nothing more than a middle man; the performance gains are so minor that Amazon has no inventive to do this other than for data collection.
That's a lot of unlesses...
I'm not adding any failure points...
Even Amazon's client should be smart enough to fail-through to a non-Amazon request for a regular web page. And Amazon servers should be agile enough to re-route requests to the non-Amazon (target) web pages if the cache isn't available in milliseconds,
You are over thinking this... It works some of the time better than others... And fails-through to what you'd get if you didn't try...
Yes... But Silk's potential is for millions of popular page requests from identical devices to a concentrated set of servers.
Amazon could continuously determine, say, the top 10,000 page requests and continuously reload, render and cache those pages -- so that 80% of Silk requests could be delivered, preformatted, from the existing cache.
What happens when I update the files on my site? Are the users going to be treated to the old site rather than the new stuff and I'm going to have a hellish trying to break the cache for amazon silk.
Even Amazon's client should be smart enough to fail-through to a non-Amazon request for a regular web page. And Amazon servers should be agile enough to re-route requests to the non-Amazon (target) web pages if the cache isn't available in milliseconds,
You are over thinking this... It works some of the time better than others... And fails-through to what you'd get if you didn't try...
Either way it takes more time to fall through. That's the bottom line.
I just think you're discounting the bad side to silk and assuming amazon has done something to remedy the downsides of using silk when we don't know that. Saying something should be able to doesn't mean it is. It's wishful thinking.
I disagree. Profanity does not diminish the merits of a good argument and the numerous valid points that have been laid forth. Puritanical people might find such language objectionable, but profanity is a common part of language that is used daily by virtually everybody. Even such writers as Shakespeare were fond of vulgar words.
Even such writers as Shakespeare were fond of vulgar words.
To paraphrase a well-known quote, you sir are no Shakespeare. Nor did Shakespeare struggle with language so much that he found it necessary to use it in a quarter of all his sentences to express his ideas.
Hopefully this site doesn't appear all that often in search results when kids/mothers/families/grandparents etc, research Apple topics if forum members use of profanity is now considered to be an admirable and desirable trait when commenting to others. Far from only puritanical, it's common courtesy to avoid it's use when communicating with other than close friends or family that you know or hope won't be offended. I don't think anyone's ever been insulted or offended by it not being used.
Even Amazon's client should be smart enough to fail-through to a non-Amazon request for a regular web page. And Amazon servers should be agile enough to re-route requests to the non-Amazon (target) web pages if the cache isn't available in milliseconds,
You are over thinking this... It works some of the time better than others... And fails-through to what you'd get if you didn't try...
Quote:
Originally Posted by AdonisSMU
What happens when I update the files on my site? Are the users going to be treated to the old site rather than the new stuff and I'm going to have a hellish trying to break the cache for amazon silk.
Likely, your web site updates will not be cached by Silk, Google or similar search/aggregator services unless it is very popular. If it meets the popularity/caching criteria, then the caching servers should continuously monitor the target sites for changes, and refresh tha cache as necessary.
When you update your site now, how long does it take Google to reflect those changes in its search results?
However, if someone requests your page directly the caching service should check the cache to see if the cached page (if it exists) has been updated, say, within the last 2 minutes -- if not, then fail-through: re-access, re-cache and re-serve the page.
Quote:
Originally Posted by AdonisSMU
I just think you're discounting the bad side to silk and assuming amazon has done something to remedy the downsides of using silk when we don't know that. Saying something should be able to doesn't mean it is. It's wishful thinking.
I suspect that Amazon is as adept at server management as Google, Yahoo, MS Bing, eBay et al.
They have a shopping service that spans millions of web pages that are continuously updated, cached and served.
If they don't have the capability to do this efficiently it would be reflected by many disatisfied buyers and sellers.
Who does a better job of this than Amazon?
Why wouldn't Amazon exploit this capability in Silk?
As an aside, I think that Apple's Siri web searches will cache and deliver web pages in the same way Silk does.
Based on their track record, I suspect that Amazon does a better job on a much larger scale than Apple... or almost anybody.
Silk is an excellent feature, but I'm not surprised it doesn't give a big advantage over WiFi...
However, should Amazon release a 3G version of the Fire... Well, then you will really notice a difference with Silk!
The same things happens to BlackBerries. Browsing in 2G (and even in 3G, sometimes) is much faster on BlackBerries than in other phones, thanks to the BIS...
well if on wifi with silk its slow, it will be unbearable on 3G with silk as 3G is even slower than WIFI
I agree that criticism can absolutley be written without profanity, and you have provided an example of that. But I'm sure you would agree that we all have our own particular style and tastes when it comes to different things, and I am simply a profane and blasphemous person. I guess that's just how I roll.
Not that I'm comparing myself to Picasso, but would you criticize him for having too much blue in his pictures?
Technically, Amazon doesn't get access to newer version of Android nor can it sell its products using the Android trademark because only products that use Google's apps and follow Google's rules get access to the latest version of Android and can use the marketing term. Amazon may never get to use 4.0.
Quote:
Originally Posted by Realistic
Who cares what Google does? Amazon itself decides what version of Android their devices support. Amazon's version is their own customized version of Gingerbread. No vendor has announced an upgrade to ICS from Gingerbread. A major reason is that the Gingerbread HW won't support ICS.
The point of Silk is that it learns your browsing habits over time and prefetches relevant information. You can't test it on day one and conclude it doesn't speed you up any. I'd like to see the same tests done in two or three weeks.
Pretty interesting thread about the Amazon HTML5. Using HTML5 and web browsers, Amazon has produced a workaround for Apple's thirty percent iTunes commission condition. Resource for this article: Amazon bypasses the iOS commission requirement
Comments
I expect some of these shortcomings to be fixed when Amazon updates the Kindle Fire OS to Android 4.0. Other than that, I wasn't really surprised in the results. Android 2.x isn't that great when it comes to supporting modern standards. Performance is subpar and only masked on phones because of processors that range from 1.2-1.5Ghz to make up for the OS' shortcomings.
Considering Apple gets better performance only running it's CPUs at 800Mhz, it's pretty clear to me that software matters a LOT. Heck, Windows Phone 7 devices are smoother than most Android smartphones and they only have a single core (but hardware acceleration!).
It's the software, stupid!
Are you really that stupid? The fire runs a special Amazon modified version of Gingerbread and cannot be upgraded to ICS.
What makes caching work, however, are lots of reqrests for the same pages -- so Amazon can just deliver from the server cache to the device (no need to re-retrieve and rerender the pages)
I suspect that there is not yet enough Fires in use to maintain enough meaningful cached pages.
Unless:
- The route to the cache is longer than the route directly to the site.
- The route from the cache to the site is longer than yours.
- The cache's DNS lookups are slower than your ISP's or a local DNS cache.
- The cache's server is under a heavy load.
- The cache is down or the route to it is unreachable. Is Silk smart enough to try another method? Even if it does, it adds delay.
- Silk is unable to reach the content due to certain geogpahic restrictions (YouTube is an good example of this) and returns you an error page, even though you are in a whitelisted country.
- A site simply does not play well with proxies.
- The cache is malfunctioning and out of date.
You're adding a massive point of potential failure into an ordinarily dead simple process. In most cases it is nothing more than a middle man; the performance gains are so minor that Amazon has no inventive to do this other than for data collection.I checked out the Android 4.0.1 source and had a look. They're using v8 version 3.2.10, from October 20, 2011 - http://code.google.com/p/v8/source/detail?r=9719. For comparison, the current stable version of Chrome (15.0.874.121) uses v8 version 3.5.10.24, which has several performance improvements. Android 4.0.1 isn't yet using the NEON-optimized support libraries, such as libjpeg-turbo (http://libjpeg-turbo.virtualgl.org/). I'm not sure why this is, but I suspect Google will upgrade their external libraries in a future version.
Of course, when they do that, I'm sure the fair-minded folks here will be sure to reevaluate their opinion of Android based on the evidence, right?
Who cares what Google does? Amazon itself decides what version of Android their devices support. Amazon's version is their own customized version of Gingerbread. No vendor has announced an upgrade to ICS from Gingerbread. A major reason is that the Gingerbread HW won't support ICS.
Originally Posted by tylerk36
You don't want an email client for too much on a tablet with such limited storage anyway. All it does is fill up mailboxes on what little space you've got on the device, and they want you to use the storage for content. They assume you'll use the browser for email.
But just get an email client and use it, if need be. There are plenty.
True. I guess thats where the cost issue comes in. Limited storage = lower cost.
Unless:
- The route to the cache is longer than the route directly to the site.
- The route from the cache to the site is longer than yours.
- The cache's DNS lookups are slower than your ISP's or a local DNS cache.
- The cache's server is under a heavy load.
- The cache is down or the route to it is unreachable. Is Silk smart enough to try another method? Even if it does, it adds delay.
- Silk is unable to reach the content due to certain geogpahic restrictions (YouTube is an good example of this) and returns you an error page, even though you are in a whitelisted country.
- A site simply does not play well with proxies.
- The cache is malfunctioning and out of date.
You're adding a massive point of potential failure into an ordinarily dead simple process. In most cases it is nothing more than a middle man; the performance gains are so minor that Amazon has no inventive to do this other than for data collection.That's a lot of unlesses...
I'm not adding any failure points...
Even Amazon's client should be smart enough to fail-through to a non-Amazon request for a regular web page. And Amazon servers should be agile enough to re-route requests to the non-Amazon (target) web pages if the cache isn't available in milliseconds,
You are over thinking this... It works some of the time better than others... And fails-through to what you'd get if you didn't try...
Yes... But Silk's potential is for millions of popular page requests from identical devices to a concentrated set of servers.
Amazon could continuously determine, say, the top 10,000 page requests and continuously reload, render and cache those pages -- so that 80% of Silk requests could be delivered, preformatted, from the existing cache.
What happens when I update the files on my site? Are the users going to be treated to the old site rather than the new stuff and I'm going to have a hellish trying to break the cache for amazon silk.
That's a lot of unlesses...
I'm not adding any failure points...
Even Amazon's client should be smart enough to fail-through to a non-Amazon request for a regular web page. And Amazon servers should be agile enough to re-route requests to the non-Amazon (target) web pages if the cache isn't available in milliseconds,
You are over thinking this... It works some of the time better than others... And fails-through to what you'd get if you didn't try...
Either way it takes more time to fall through. That's the bottom line.
I just think you're discounting the bad side to silk and assuming amazon has done something to remedy the downsides of using silk when we don't know that. Saying something should be able to doesn't mean it is. It's wishful thinking.
I disagree. Profanity does not diminish the merits of a good argument and the numerous valid points that have been laid forth. Puritanical people might find such language objectionable, but profanity is a common part of language that is used daily by virtually everybody. Even such writers as Shakespeare were fond of vulgar words.
Agreed on all counts.
Even such writers as Shakespeare were fond of vulgar words.
To paraphrase a well-known quote, you sir are no Shakespeare. Nor did Shakespeare struggle with language so much that he found it necessary to use it in a quarter of all his sentences to express his ideas.
Hopefully this site doesn't appear all that often in search results when kids/mothers/families/grandparents etc, research Apple topics if forum members use of profanity is now considered to be an admirable and desirable trait when commenting to others. Far from only puritanical, it's common courtesy to avoid it's use when communicating with other than close friends or family that you know or hope won't be offended. I don't think anyone's ever been insulted or offended by it not being used.
Just my take on it.
That's a lot of unlesses...
I'm not adding any failure points...
Even Amazon's client should be smart enough to fail-through to a non-Amazon request for a regular web page. And Amazon servers should be agile enough to re-route requests to the non-Amazon (target) web pages if the cache isn't available in milliseconds,
You are over thinking this... It works some of the time better than others... And fails-through to what you'd get if you didn't try...
What happens when I update the files on my site? Are the users going to be treated to the old site rather than the new stuff and I'm going to have a hellish trying to break the cache for amazon silk.
Likely, your web site updates will not be cached by Silk, Google or similar search/aggregator services unless it is very popular. If it meets the popularity/caching criteria, then the caching servers should continuously monitor the target sites for changes, and refresh tha cache as necessary.
When you update your site now, how long does it take Google to reflect those changes in its search results?
However, if someone requests your page directly the caching service should check the cache to see if the cached page (if it exists) has been updated, say, within the last 2 minutes -- if not, then fail-through: re-access, re-cache and re-serve the page.
I just think you're discounting the bad side to silk and assuming amazon has done something to remedy the downsides of using silk when we don't know that. Saying something should be able to doesn't mean it is. It's wishful thinking.
I suspect that Amazon is as adept at server management as Google, Yahoo, MS Bing, eBay et al.
They have a shopping service that spans millions of web pages that are continuously updated, cached and served.
If they don't have the capability to do this efficiently it would be reflected by many disatisfied buyers and sellers.
Who does a better job of this than Amazon?
Why wouldn't Amazon exploit this capability in Silk?
As an aside, I think that Apple's Siri web searches will cache and deliver web pages in the same way Silk does.
Based on their track record, I suspect that Amazon does a better job on a much larger scale than Apple... or almost anybody.
Silk is an excellent feature, but I'm not surprised it doesn't give a big advantage over WiFi...
However, should Amazon release a 3G version of the Fire... Well, then you will really notice a difference with Silk!
The same things happens to BlackBerries. Browsing in 2G (and even in 3G, sometimes) is much faster on BlackBerries than in other phones, thanks to the BIS...
well if on wifi with silk its slow, it will be unbearable on 3G with silk as 3G is even slower than WIFI
I agree that criticism can absolutley be written without profanity, and you have provided an example of that. But I'm sure you would agree that we all have our own particular style and tastes when it comes to different things, and I am simply a profane and blasphemous person. I guess that's just how I roll.
Not that I'm comparing myself to Picasso, but would you criticize him for having too much blue in his pictures?
Much better, even, dare I say, "endearing!"
Best
Who cares what Google does? Amazon itself decides what version of Android their devices support. Amazon's version is their own customized version of Gingerbread. No vendor has announced an upgrade to ICS from Gingerbread. A major reason is that the Gingerbread HW won't support ICS.