The Notebook Review forums were hosted by TechTarget, who shut down them down on January 31, 2022. This static read-only archive was pulled by NBR forum users between January 20 and January 31, 2022, in an effort to make sure that the valuable technical information that had been posted on the forums is preserved. For current discussions, many NBR forum users moved over to NotebookTalk.net after the shutdown.
Problems? See this thread at archive.org.
← Previous page

    i7 mobile explanation?

    Discussion in 'Hardware Components and Aftermarket Upgrades' started by double_entity, Sep 24, 2009.

  1. Bog

    Bog Losing it...

    Reputations:
    4,018
    Messages:
    6,046
    Likes Received:
    7
    Trophy Points:
    206
    For one thing, I think it would benefit you to admit that we are in disagreement. There is nothing wrong with disagreeing or in being proven wrong because being corrected should be associated with enlightened understanding, not failure. It is clear that we disagree with each other; past posts reflect this.

    With that said, I don't really care what your profession is; I care about your arguments and the reasons you present to support said arguments. You haven't convinced me of 100% proportional performance gains from adding cores or even close to 100% simply it makes the unrealistic assumption that almost all real-world applications can make 90-100% optimal use of multi-core CPUs when in practice we know that almost all applications do NOT. This article illustrates my point (I would advise skipping to the conclusion for a summary of results):

    http://www.tomshardware.com/reviews/multi-core-cpu,2280.html

    Even in the case of using an OS best suited for making multiple cores as widely available to multiple cores, your assumptions are clearly not valid:
    http://www.tomshardware.com/news/microsoft-windows-xp-vista,6895.html


    What you say you claimed is not true. At the beginning of the thread you told the user that he could simply multiply clock speed by # of cores to get a quantitative measurement of performance; this is clearly only true if and only if certain assumptions are made: namely, 90-100% optimization. Do application benchmarks and tests reflect this? Absolutely not. This is precisely why we are in disagreement.

    Numerous times in this thread you referred to your rule of multiplying clock speed by # of cores without specifying that it was based on theory and made certain critical assumptions that were largely unrealistic.

    To refresh your memory, I would remind you that I do have a better memory than you think:

    Really, you were offering all of this as practical advice, not as theoretical speculations. You even used your own experience as evidence in the context of ray-tracing, which isn't a common computer applications. Your posts show it and there is no point in changing your argument.

    Not quite, I am an environmental scientist by profession, but I do have a hobbyist's enthusiasm for computers. :cool: We're still in the same club, though!
     
  2. MrX8503

    MrX8503 Notebook Evangelist

    Reputations:
    126
    Messages:
    650
    Likes Received:
    0
    Trophy Points:
    30
    What the? lol you can't add clockspeeds together and call it a day. By this logic you're assuming that C2D is as fast as Core i7 clock for clock. This is simply not true. On top of this you're assuming that performance gains between cores are linear and that it has 100% scalability.

    The reason why i7 can perform better than current C2D's is because of the architecture. We can no longer use clockspeeds as a benchmark. Ever since AMD came to the scene with their Athlon 64, clockspeeds are now a poor judgement of performance.

    In laymens terms, Core i7 is faster than C2D clock for clock. This is why a 1.6ghz Core i7 is so powerful.
     
← Previous page