I'll be honest here (I always am?): I don't understand the iPad comparison. The Kindle Fire and iPad 2 couldn't be more different. They are vastly different sizes, shapes and prices. They even serve slightly different functions. The search for an iPad killer reminds me of the search for a Voodoo killer back during the heyday of 3dfx in the late 1990s.

The Kindle Fire serves entirely different purposes than to take marketshare away from Apple.

Why would Amazon enter the IPS LCD equipped multitouch tablet business to begin with? For users who are content reading ebooks on an e-ink screen, the vanilla Kindles are as good as they get. The problem is for users looking to consolidate devices, they may find themselves carrying a Kindle and a tablet of some sort (likely an iPad) and will ultimately ditch the Kindle in favor of the iPad. Should these users replace their Kindles with iPads, there's the argument that Apple could tempt them away from Amazon's Kindle store altogether. If they want a more affordable tablet however they are likely going to be forced into a solution that's probably not very good. Neither possibility is something Amazon likes, so the obvious answer is to offer a Kindle that delivers enough of the tablet experience that will satisfy those users looking for more than an e-ink Kindle could provide.

The Fire is that Kindle. Read on for our full review!

We've been working on our Kindle Fire review over the weekend but I thought I'd break out a particularly interesting section of the review for release a bit early. At its launch Amazon introduced a new web browser called Silk.

Silk is yet-another-webkit based browser with all of the usual features: tabbed browsing, Flash support, integrated search/URL bar, etc... What makes Silk unique is its ability to funnel your web requests through Amazon's Web Services (AWS) cloud. A typical load of AnandTech.com pulls content from thirteen different hosts. Each host is contacted, the request acknowledged and then data is exchanged between it and your browser.

Amazon believes that this is an inefficient way of loading a web page. With Silk, the request is sent to Amazon's cloud, where Amazon's servers retrieve (and cache) all of the elements of the web page and deliver the result to you directly.

Amazon claims the cloud-side caching can improve performance, however I was skeptical of this claim. A huge portion of web page loading on smartphone platforms is actually CPU bound. It's why you notice a performance difference when you upgrade from a two year old smartphone to a modern day model, even if both were running the same OS. The parts of the loading process that aren't CPU bound are typically limited by the speed of the cellular network you're on. AT&T's 3G at my house tops out at 3Mbps, but more frequently than not it's down in the 1 - 2Mbps range. Things are even worse on Verizon's EVDO network where I get sub 1Mbps speeds. Consolidating network access on a cellular network seems to make sense, there's just one problem: the Kindle Fire was launched as a WiFi only model.

Curious to measure the impact of Amazon's cloud-side caching, I did a bunch of benchmarking on the Kindle Fire. Read on for the results...

In a move that has been anticipated for sometime, Amazon has introduced their own branded Android tablet, the Kindle Fire. Though based on Android, you won't be confusing this device with any of the growing army of Android tablets joining the market, nor will you see much of the Android you've come to expect. The 7" slate is designed to deliver Amazon services in a user friendly walled garden that bears little resemblance to vanilla Android. We've got first impressions and details along with a gallery after the break.