My head has been deep in testing and writing for these past couple of weeks but I managed to get my head above water enough to provide an update on what I'm working on.

The Pre Update

I have to give it to Palm, releasing two OS updates since the Pre was launched does show commitment to the platform. I've been working on the iPhone 3GS review and I already miss using the Pre regularly. While I was running battery life tests on the 3GS I got to switch back to the Pre as my primary phone and immediately recognized three things:

1) I miss background applications/multitasking.
2) The Pre is noticeably slower than the 3GS
3) I miss the iPhone App store and its apps when I'm on the Pre.

I think the Pre is quite compelling. I'm guessing it's one major update away from a significant performance update. I've even found that web browser performance is far closer between the 3GS and the Pre on webOS 1.0.3 than it was on 1.0.2 (you'll see results in the 3GS review). I'm very, very eager to see where the Pre is in 6 months. For Sprint's sake, I would hope that Palm can get everything worked out and polished before the carrier exclusivity agreement is up.

I have heard about the HTC Hero and if I could get a good contact over there I'd like to look at the Hero and its installation of Android. Between Palm, Google, Microsoft, Nokia and Apple, I'm really curious to see how many players the smartphone market can really support in the long run.

Nokia and Intel

Yesterday I spent some time on a conference call with Intel and Nokia. They didn't really say much other than they've formed a close partnership. They've agreed to work on mobile platforms together (Netbooks, MIDs and smartphones), Moblin (Intel's mobile Linux distribution) and Nokia has agreed to license their 3G/HSDPA modem technology to Intel.

The first part means we'll probably see some sweet smartphone designs based on Atom and its platforms.The Moblin announcement means that we'll see Moblin on some of these new Intel based Nokia devices. And the last part means that Intel will be able to offer an Atom platform or SoC with integrated 3G modem functionality. Remember that Samsung, Toshiba and other ARM partners can already offer this sort of support in their SoCs so Intel is simply trying to build a similarly stacked deck.

Realistically, Intel is still at least 2 years away from being in something like the Pre or the iPhone, but it's getting there.

It's a Mac Sort of Week

I'm out of the office for the rest of this week but I'm working on wrapping up two major projects: the 3GS review and my Nehalem Mac Pro article. The latter is pretty unique since we managed to upgrade the CPUs in the Mac Pro, which proved to be much more complicated than you'd think at first.

EVGA also sent me their new GeForce GTX 285 Mac Edition that I'm going to start work on next week. I would've gotten to it earlier but my head has been in the smartphone clouds for longer than I expected.

The WePC Update

For the past two weeks my posts over at WePC mirrored much of my life on AnandTech. Last week I talked about Apple's new MacBook Pro and the end of removable batteries in notebooks. This week the topic of conversation was gaming on smartphones. When I was little I used to carry a Gameboy with me on trips but I never carry my PSP or Nintendo DS when I'm out and about these days. If my smartphone becomes the next portable gaming platform of choice then I'd be quite content.

SSDs and Ion

I haven't forgotten about the SSD stuff, you may have even seen a sneak preview of some numbers in my recent MacBook Pro update from the top three contenders in the market. The smartphone and Mac stuff has pushed it back a bit but I also haven't come to any significant enough conclusions on changes to the market. The way I see it is this:

1) The X25-M continues to be my top pick.
2) The Samsung based drives (e.g. Corsair 256GB) offer great compatibility (that's a newer version of what Apple uses in its MacBook lineup) but their worst case performance isn't as good as the Indilinx or Intel drives. This won't be an issue for everyone but it does leave a sour taste in my mouth.
3) The Indilinx based drives (e.g. OCZ Vertex) seem to provide the best of both worlds between the X25-M and the Samsung based drives. You get higher peak transfer rates (like the Samsung) but you get better random write performance (like the X25-M).

Things haven't changed too much but TRIM is just around the corner...

I've also been playing with ASRock's Ion system as well. It's good to see more Ion based systems around, and ASRock is delivering something different enough from the Zotac Ion that it deserves some attention.

That's it for now - have a great week guys :)

POST A COMMENT

36 Comments

View All Comments

  • fedemaste - Thursday, June 25, 2009 - link

    Try using using GPUs that are not for Mac, is it possible? Maybe with a firmware update you can, and they are cheaper!
    Can you also test SLI configurations for OSX and Windows?
    Reply
  • danielk - Thursday, June 25, 2009 - link

    More than anything, i would like to know a bit more about SSD roadmaps, specifically Intel's. I'm in the market for getting a x25-m, but dont want to see a next-gen 'uber' disk released a month after my purchase.

    vr-zone.com supposedly posted intels SSD roadmap earlier this year, vaguely stating the SSD's will get a revamp in Q4(50nm to 34nm and "an updated controller").

    By the looks of how long TRIM is taking, im tempted to think that either TRIM will be launched along side the next-gen Intel SSD's, or TRIM will be popped 'soon'(tm) and used to milk the current Intels a bit more -probably resulting in the next gen release being delayed?

    Any thoughts?
    Reply
  • The0ne - Thursday, June 25, 2009 - link

    Just my thoughts...

    If you aren't in a hurry and can wait til end of the year I think you should wait. Competition is hot, designs are changing and improving and there's lots to improve still. While it may be a couple more years for it to compete competitively with hard drives, it'll eventually get there. Then there's the manufacturing process that will also improve and drive cost down.
    Reply
  • lux47 - Thursday, June 25, 2009 - link

    When testing SSD-s, it would be great if you managed to include Velociraptor (10000 RPM drive) results. You performed Velociraptor tests some time back; it would be interesting to compare these with SSD-s now, when TRIM is supported and new generation of SSDs has arrived.

    Thanks for the great articles!
    Reply
  • TA152H - Thursday, June 25, 2009 - link

    x86 plaguing computers isn't bad enough? We need it to grow like a cancer and spread to phones?

    x86 costs the world tons of money, and needs to go away. We don't need it spreading to graphics cards, and phones, we need it gone. It makes processors slower, bigger, and more expensive to make.

    Maybe it's not a huge amount per processor, but when you multiply it by the number out there, it's an enormous amount of waste.

    I don't understand Intel. They tried to kill x86 with the Itanium, and now they are spreading this disease with reckless abandon.

    What the Hell are they doing????
    Reply
  • Rasterman - Thursday, June 25, 2009 - link

    it is unquestionable that x86 wastes some performance and power, but any transistors or energy lost dealing with x86 is insignificant when compared to the amount of research, training, tools, development, and programs that exist for it. supporting x86 isn't really a choice, its a requirement.

    what would you rather have:

    a 1-10% slower machine OR 99% less programs to run?
    a 1-10% increase in battery life OR a device that costs 90% more?
    Reply
  • The0ne - Thursday, June 25, 2009 - link

    If that was the case for many things you would not have seen advances and innovations in the technical field, software included. At some point there has to be change. People often get too comfortable and often times too lazy with what is already familiar and refuse to change. Someone has to try something they believe will be of more benefit in the long term or else the field goes nowhere. Reply
  • JarredWalton - Thursday, June 25, 2009 - link

    back when x86 support on an otherwise RISC-style CPU first came to be (the P6 in the Pentium Pro), Intel had to use something like 30% of the die to handle the x86 translation. That was huge, and it was space that could have been put to better use perhaps. Now, though, x86 is ubiquitous, well understood, has excellent compilers, and the chips are highly optimized.

    If you have a 5 million transistor processor, using 1.5 million transistors to handle x86 decoding (i.e. translate into RISC-style micro ops) is a costly affair. Now we're looking at chips with over a billion transistors; needless to say, using less than 1% of the transistors to maintain x86 compatibility isn't really a problem.

    Also note that pretty much no one writes in ASM anymore, so there's another reason x86 isn't a problem. Compilers need to handle it properly, and that's about it.

    Sure, Atom and such are a lot smaller at "only" 47 million transistors, but the extra million (or two or three million) trannies to handle x86 is a drop in the bucket http://www.anandtech.com/cpuchipsets/showdoc.aspx?...">compared to the potential benefits.
    Reply
  • TA152H - Thursday, June 25, 2009 - link

    What you're saying ignores a couple of important issues.

    First, there are no benefits, except for compatibility. Who needs this compatibility with a phone? ARM is a cleaner instruction set, and the wasted transistors are big. Keep in mind, a transistor isn't a transistor. You throw around numbers while apparently not taking into account decode logic is a lot larger per transistor than cache memory.

    You might be too young to know this, but x86 was considered a bad instruction set even when it was made. Most people preferred the 68K, and even the 6809. It was damn annoying then.

    Also, you point to transistor count like that's the only issue. How about those extra steps that have to be done? They slow it down, requiring more hardware to perform at the same level, or simply performing worse.

    Then there is all the legacy garbage, like operating modes that aren't useful anymore. How often do you think 286 protected mode is still used? Then there's the lovely x87 section, that serves no purpose at all anymore, and is not even part of x86-64. Of course, if you buy an AMD, you get 3D Now!, which never really was 3D Now!, and certainly isn't today. It was rarely used.

    On top of this, there are limits to what you can do behind it with the RISC engine that has to deal with it. It's not like this RISC engine can be anything you want, except for the fact you have to convert from a bad instruction set. It does limit IPC.

    Then there are the very few registers. Far less than most RISC implementations.

    And, of course, we have multiple forms of software. You can get 32-bit, and 64-bit. So, there is money spent on that.

    And, AMD actually pads the L1 cache to help with decoding, making it smaller than what 128K for actual data.

    Writing compilers for it is also difficult, since you aren't writing for the execution engine. You're writing for something before it, and that level of indirection adds complexity, and can negatively affect efficiency. It's also harder to implement virtually anything because of this level of indirection. It's not that different to writing to an API rather than the actual hardware, although certainly the penalty is lower in magnitude.

    Maybe you like slower performance, extra cost, and extra power use, but I don't. It's bad enough in a PC, but now in phones???? Yes, I really want my battery time chewed up with decode logic. Yup, I really want it chewed up by necessary extra clock speeds to compensate for the speed penalty introduced by extra stages. Even if it were a good CISC implementation, like the 6809 or 68K, or even the VAX, I could live with it a little easier since it might make coding easier. Have you ever heard anyone say x86 code helped in ease of development???? It's a damn nightmare. It blows even for CISC. Why do we want to spread this?
    Reply
  • Penti - Thursday, July 02, 2009 - link

    Your forgetting that Intel got rid for their XScale PXA arm including it's engineers. You can't expect Intel to go ARM for MIDs/Handhelds again. Neither is the chip only for those devices. Reply

Log in

Don't have an account? Sign up now