Re: Intel Or AMD?

Discussion in 'Processors' started by Tony Hill, Dec 19, 2006.

  1. Tony Hill

    Tony Hill Guest

    On Tue, 19 Dec 2006 19:47:40 +0000, Lexusan
    <> wrote:
    >Which processor is better?


    Can you make that a bit more of an open-ended question?! </sarcasm>
    Seriosuly, both AMD and Intel make quite a range of processors at
    various performance levels and price points.

    > Im currently using a intel celeron (i know )
    >But am looking to the new 4's with hyper-threading.


    The Pentium 4, of any stripe, is a VERY poor choice these days. Their
    performance is pretty weak as compared to either AMD's Athlon64 line
    or Intel's own Core 2 Duo line. P4 chips also consume a LOT of power.

    As for Hyperthreading, at best it's a poor-mans excuse for dual-core
    that offers slight improvements in multithreaded performance. At
    worst it makes the system slower, which is why it's often disabled.
    Given that true dual-core processors start at under $100 these days,
    it's something that can very safely be ignored.

    >Ive seen this amds that are quite good but i heard the semperons are
    >bad.


    Sempron chips are quite reasonable for their price. They compete
    against Intel's Celeron chips and offer very competitive performance
    for the price. For example, a Sempron 3000+ will set you back $43
    (prices according to www.newegg.com) and will give you similar to
    slightly better performance as compared to a Celeron 336 that costs
    $48.

    Of course, both of these are low-end solutions. Spending a small
    amount more will get you a MUCH faster processor. At $93 you could
    get a dual-core Intel Pentium D 805. That will perform about the same
    as the Celeron or Sempron mentioned above in single-threaded
    applications, but it has a whole other processor available allowing
    for MUCH faster performance in multi-threaded applications and/or much
    better multitasking performance. This is probably the absolute
    cheapest chip that I would recommend unless you absolutely need a
    computer now and can't afford the extra $50 or so.

    The next step up from that would be AMD's Athlon64 X2 3800+ at $131.
    Again this is a dual-core chip, but it's much faster than anything
    from Intel with the "Pentium" name on it. It will be faster than any
    of the chips mentioned above in either single-threaded or
    multi-threaded applications and have much better performance in
    multitasking. The Athlon64 X2 4200+ ($165) also isn't bad, though
    going beyond that the price/performance ratio starts to drop off on
    these chips.

    Going up to the high-end of things, Intel currently holds the crown
    with their Core 2 Duo line. The Core 2 Duo 6300 sells for $181 and
    from that point on up the only question is what speed grade you want.

    So, recommendations? Well that depends on what you want to spend:

    High-end: Intel Core 2 Duo 6600
    Mid-range: Intel Core 2 Duo 6300 or 6400
    Low-end: AMD Athlon64 X2 3800+ or 4200+
    "I can just BARELY afford a computer": Intel Pentium D 805
    "I really CAN'T afford a computer": AMD Sempron 3000+
    --
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
     
    Tony Hill, Dec 19, 2006
    #1
    1. Advertisements

  2. Tony Hill

    Spoon Guest

    Tony Hill wrote:

    > As for Hyperthreading, at best it's a poor-mans excuse for dual-core
    > that offers slight improvements in multithreaded performance. At
    > worst it makes the system slower, which is why it's often disabled.


    Moreover, it's a security risk.

    http://www.daemonology.net/hyperthreading-considered-harmful/
     
    Spoon, Dec 20, 2006
    #2
    1. Advertisements

  3. Tony Hill

    Tony Hill Guest

    On Wed, 20 Dec 2006 09:52:01 +0100, Spoon <>
    wrote:

    >Tony Hill wrote:
    >
    >> As for Hyperthreading, at best it's a poor-mans excuse for dual-core
    >> that offers slight improvements in multithreaded performance. At
    >> worst it makes the system slower, which is why it's often disabled.

    >
    >Moreover, it's a security risk.
    >
    >http://www.daemonology.net/hyperthreading-considered-harmful/


    I remember reading about that security risk back when it first came
    out and thinking that the author was just being a jackass. Exploiting
    this security hole is ridiculously difficult, to the point that it
    would probably be easier to brute-force crack the RSA keys he claims
    to be able to get from it. You need a VERY specifically crafted
    situation for this to be remotely possible at all, ie the attacker
    would pretty much need 'root' access on the system to execute this
    exploit, by which point you're security is already shot all to hell.

    What's more, the same "risk" almost certainly exists in any case where
    the cache is shared (Core Duo and Core 2 Duo chips) and possibly even
    any case where cache is snooped (basically all multiprocessor systems.

    Long story short, this one should be way *WAY* down on your list of
    security concerns. Maybe if you're running a super-top-secret
    military system it might be an issue, but then again, you probably
    wouldn't be using anything at all resembling standard hardware.
    --
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
     
    Tony Hill, Dec 21, 2006
    #3
  4. Tony Hill

    Michael Daly Guest

    Tony Hill wrote:

    > I remember reading about that security risk back when it first came
    > out and thinking that the author was just being a jackass. Exploiting
    > this security hole is ridiculously difficult, to the point that it
    > would probably be easier to brute-force crack the RSA keys he claims
    > to be able to get from it.


    I was wondering about this - how, in general, does process A on one CPU know
    what's running on the other CPU and know where in the cache the data is? (I
    didn't bother to read the 12 page stuff at the link). There's a big difference
    between possible and probable.

    > What's more, the same "risk" almost certainly exists in any case where
    > the cache is shared (Core Duo and Core 2 Duo chips) and possibly even
    > any case where cache is snooped (basically all multiprocessor systems.


    I was going to ask about this - unless shared cache has protected memory areas,
    either processor can read the other's data. Even if a virus manages to hog one
    CPU and scan everything in the cache all the time, it would still need intimate
    details of the memory content organization to make sense of the data. That
    implies a much more serious security breach than just reading cache - it implies
    that all your source code has been compromised. Wouldn't it also need to know
    how chunks of memory get swapped in and out of cache at any point in time as
    well? I only have an "overview" notion of how these processor caches work, so I
    have an expectation that the placement of a bit of data in the cache at any
    point in time to be more or less random.

    Mike
     
    Michael Daly, Dec 21, 2006
    #4
  5. Tony Hill

    Spoon Guest

    Tony Hill wrote:

    > Spoon wrote:
    >
    >> Tony Hill wrote:
    >>
    >>> As for Hyperthreading, at best it's a poor-mans excuse for dual-core
    >>> that offers slight improvements in multithreaded performance. At
    >>> worst it makes the system slower, which is why it's often disabled.

    >>
    >> Moreover, it's a security risk.
    >>
    >> http://www.daemonology.net/hyperthreading-considered-harmful/

    >
    > I remember reading about that security risk back when it first came
    > out and thinking that the author was just being a jackass.


    Perhaps you should tell all the people working on side-channel attacks
    (such as Adi Shamir (the S in RSA), and Daniel Bernstein (timing attack
    against AES)) that you consider their work to be worthless? ;-þ

    It is an active field of research.
    cf. the References in http://eprint.iacr.org/2006/351

    > Exploiting
    > this security hole is ridiculously difficult, to the point that it
    > would probably be easier to brute-force crack the RSA keys he claims
    > to be able to get from it. You need a VERY specifically crafted
    > situation for this to be remotely possible at all, ie the attacker
    > would pretty much need 'root' access on the system to execute this
    > exploit, by which point you're security is already shot all to hell.


    The 'spy' process is run as a normal user. No root access required.

    > What's more, the same "risk" almost certainly exists in any case where
    > the cache is shared (Core Duo and Core 2 Duo chips) and possibly even
    > any case where cache is snooped (basically all multiprocessor systems.
    >
    > Long story short, this one should be way *WAY* down on your list of
    > security concerns. Maybe if you're running a super-top-secret
    > military system it might be an issue, but then again, you probably
    > wouldn't be using anything at all resembling standard hardware.
     
    Spoon, Dec 21, 2006
    #5
  6. In comp.sys.ibm.pc.hardware.chips Spoon <root@localhost> wrote in part:
    > Perhaps you should tell all the people working on side-channel
    > attacks (such as Adi Shamir (the S in RSA), and Daniel Bernstein
    > (timing attack against AES)) that you consider their work to be
    > worthless? ;-þ


    Of course not! But it's easy to add keystroke combining to a client
    like `ssh` to drastically reduce the amount of information available
    from timing analysis as well as reduce the number of packets sent.

    There is a small cost in latency which can be rendered less
    noticable by careful design.

    -- Robert
     
    Robert Redelmeier, Dec 21, 2006
    #6
  7. Tony Hill

    Tony Hill Guest

    On Thu, 21 Dec 2006 22:23:18 +0100, Spoon <root@localhost> wrote:

    >Tony Hill wrote:
    >
    >> Spoon wrote:
    >>
    >>> Tony Hill wrote:
    >>>
    >>>> As for Hyperthreading, at best it's a poor-mans excuse for dual-core
    >>>> that offers slight improvements in multithreaded performance. At
    >>>> worst it makes the system slower, which is why it's often disabled.
    >>>
    >>> Moreover, it's a security risk.
    >>>
    >>> http://www.daemonology.net/hyperthreading-considered-harmful/

    >>
    >> I remember reading about that security risk back when it first came
    >> out and thinking that the author was just being a jackass.

    >
    >Perhaps you should tell all the people working on side-channel attacks
    >(such as Adi Shamir (the S in RSA), and Daniel Bernstein (timing attack
    >against AES)) that you consider their work to be worthless? ;-þ
    >
    >It is an active field of research.
    >cf. the References in http://eprint.iacr.org/2006/351


    Worthless? Not quite, but more academic than practical. The timing
    requirements of this sort of attack are so extreme that they are
    virtually impossible to control. Unless I'm reading this wrong, the
    attack you're quoting involves trying to determine the processing
    behaviour of one process by monitoring the branch mispredictions of
    another. This requires that you know exactly when the encryption key
    is going to be generated, you need to know when and how your thread's
    branches are going to get mispredicted according to things happening
    in another thread, and to top it off, you need to have NOTHING else
    running on the system at the same time since that throws all your
    calculations out the window.

    It's not that these attacks are not possible, they're just so
    incredibly inprobable that it's not worth worrying about. Almost any
    normal system will be hacked a thousand times over before anyone ever
    manages to successfully hack it using this method. It's worthwhile
    keeping an eye on for people that do the actual writting of SSL
    encryption software and the like, but hardly something that 99.999%+
    of the population need get concerned about.

    >> Exploiting
    >> this security hole is ridiculously difficult, to the point that it
    >> would probably be easier to brute-force crack the RSA keys he claims
    >> to be able to get from it. You need a VERY specifically crafted
    >> situation for this to be remotely possible at all, ie the attacker
    >> would pretty much need 'root' access on the system to execute this
    >> exploit, by which point you're security is already shot all to hell.

    >
    >The 'spy' process is run as a normal user. No root access required.


    It's not the 'spy' process that they need root access for, it's the
    process providing the RSA keys in the first place! Trying to do this
    with any sort of normal system behaviour is excrutiatingly difficult,
    hence my comment that it would probably be easier to brute-force hack
    the keys (perhaps a slight exaggeration, but not by much).
    --
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
     
    Tony Hill, Dec 22, 2006
    #7
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ted Grevers
    Replies:
    35
    Views:
    1,292
    Nate Edel
    Feb 6, 2004
  2. Stacey
    Replies:
    28
    Views:
    854
    Tony Hill
    Mar 4, 2004
  3. Yousuf Khan
    Replies:
    27
    Views:
    463
  4. bbbl67
    Replies:
    21
    Views:
    468
    Keith
    Apr 8, 2006
  5. Peter Smirnov
    Replies:
    0
    Views:
    441
    Peter Smirnov
    Dec 22, 2006
Loading...

Share This Page