Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×
Intel

Inside Intel 167

Posted by michael
from the moonsuits-for-everyone dept.
z71offroad writes: "There is a really interesting article at Anandtech right now showing what goes on inside Intel Labs. Although it doesnt break any NDAs, it is still a facinating look at what goes on inside the chip giant's labs."
This discussion has been archived. No new comments can be posted.

Inside Intel

Comments Filter:
  • by mbessey (304651) on Wednesday February 13, 2002 @11:13PM (#3004954) Homepage Journal
    Basically, Itanium was designed to address the "efficiency" issue, as well as enabling faster turnaround on new designs with a simpler core.

    We all know how that turned out, don't we? Fundamentally, Intel is trapped by their own success. They haven't successfully introduced a really new architecture since the i860/i960, and that was YEARS ago.

    People don't want "efficient" ot "elegant" processors. They want MegaHertz.

    -Mark
  • by solferino (100959) <hazchem@@@gmail...com> on Wednesday February 13, 2002 @11:30PM (#3005025) Homepage

    Almost as absurd as the idea of Intel backing out of their IA-64 development in favor of x86-64 is the unfortunate perception that the world's largest desktop microprocessor manufacturer is not driven by engineering but rather by marketing.

    th very first sentence in this article states th perception th article is focussed on diminishing

    today we'll be showing you the Intel that doesn't care about anything outside of making fast, reliable and powerful circuits.

    really? - as a for-profit company, perhaps their shareholders might be interested in them making maximum profit as well?

    and who is this 'we' - only a single authour is mentioned at th top of th article - or perhaps his name has simply been appended to a pre-prepared puff piece?

    another example of rhetorical writing pulled from th first few paragraphs

    very talented engineers [who] are focused on pushing the limits of technology

    ok - there may be real information contained in this article - but frankly there were enough warning signals in th first few paragraphs to tell me my time was better spent elsewhere

  • Re:Intel's approach (Score:3, Interesting)

    by Toraz Chryx (467835) <jamesboswell@btopenworld.com> on Thursday February 14, 2002 @12:17AM (#3005179) Homepage
    I'd argue that the weak IPC (especially FP) has more to do with the P4's weakass floating point execution unit than the length of the pipeline, yes, branch mispredicts to hurt performance, but the performance they are hurting isn't all that high anyway :/
  • by Christopher Thomas (11717) on Thursday February 14, 2002 @12:21AM (#3005194)
    Maybe instead of constantly worrying about clock speeds they spend more research into being able to add larger amounts of cache or try to achieve one clock cycle access to main memory

    I'm afraid that both of these (especially the last one) sound like the infamous "let's just find a way to factor huge numbers" quote. That is - yes, it would be wonderful to be able to do this, but there are good reasons for believing that it's very difficult (not that people haven't tried).

    For caches, the problem is that larger caches are slower and more power-hungry. To compensate, you use a multilevel cache architecture, but you still have some penalties. A modern foundry could put as much cache as it wanted on to a chip (look at HP's most recent chip for an example) - but because of architectural tradeoffs, this isn't always a good idea.

    For memory, if you can find a way to get single-clock access latencies reliably without a 10x slower clock, sell it to $favourite_company and retire on the proceeds. This isn't likely to happen for _two_ reasons. Firstly, modern memory is optimized for density at the expense of speed (this is why we use DRAM and not SRAM for system memory). Secondly, because of the trace lengths, capacitance (and inductance!), and crosstalk and noise issues, it's one _hell_ of a lot harder to send data at low latency _or_ low bandwidth across a motherboard than just within a chip.

    There are ways of pushing the boundaries on all of these things, but while we're doing that, processor speeds are still getting faster, putting tougher requirements on the memory and negating most of the relative gain.

    In summary, there's a good reason that Intel (along with everyone else) is pursuing more conventional enhancements while background research into memory and caches is going on.
  • Close, but no cigar (Score:4, Interesting)

    by Glonk (103787) on Thursday February 14, 2002 @12:21AM (#3005196) Homepage
    The 10GHz ALU shown was run at room temperature, and was not actually a Pentium 4 ALU at all. While it is true the Pentium 4's ALUs are double pumped, that's because they're actually 16-bit (16 x 2 = 32-bit, thus double pumped).

    The 10GHz ALU was a very limited ALU, not part of any modern processor.

    Intel is losing little ground at a time right now
    Actually, in Q4 2001 Intel gained market share and AMD lost some. But overall in 2001, AMD did gain market share, that's true.

    I still think it's because Intel wants to point to AMD and say "See? Competition!". ;)

    Intel could easily release faster CPUs right now to totally crush the Athlon, but it doesn't make sense to do so.
  • really (Score:1, Interesting)

    by Anonymous Coward on Thursday February 14, 2002 @12:53AM (#3005294)
    Really? Corporate policy actually doesn't permit wireless access. Which building is fully "wired" for wireless? Not any of the ones I've been to.

Don't be irreplaceable, if you can't be replaced, you can't be promoted.

Working...