In the Core 2 Duo Datasheet, 31327801.pdf, it plainly states "Two 16-KB
Level 1 data caches" and, in contrast to previous CPU Datasheets from
Intel, that's about all it says about L1 cache. There's no mention of TLB
anywhere in the document.

The Xeon 5100 Datasheet says "Includes 32-KB Level 1 instruction and 32-KB
Level 1 data cache per core". Again, real info on the CPU is meagre and
concentrates on mechanical, electrical and thermal specs. Can we assume
that the Core 2 Duo Datasheet is just wrong? I'd think this could be
confirmed by using an Intel CPUID program but I don't have a Conroe to test
with.

While on the subject, has anyone else noticed the change in Intel's docs in
general? There is lots of sales-oriented stuff on new hardware, with
click-through to How/Where To Buy, but not a lot of "meat". This is a big
change from their previous generous policy of access to detailed hardware
specs by *anybody". There's a hint that more detailed info is available
with a login for people who are "qualified" but even with my Software
Developer Login I can't find anything on hardware details.

Has the Intel documentation dept already been umm, "attritioned" maybe?...
or is this a new Otellini-era policy to offer info only on a "need to know"
basis? If so, it's a huge blunder IMO.

--
Rgds, George Macdonald

> In the Core 2 Duo Datasheet, 31327801.pdf, it plainly states "Two 16-KB
> Level 1 data caches" and, in contrast to previous CPU Datasheets from
> Intel, that's about all it says about L1 cache. There's no mention of TLB
> anywhere in the document.

That's clearly wrong.

> The Xeon 5100 Datasheet says "Includes 32-KB Level 1 instruction and 32-KB
> Level 1 data cache per core". Again, real info on the CPU is meagre and
> concentrates on mechanical, electrical and thermal specs. Can we assume
> that the Core 2 Duo Datasheet is just wrong? I'd think this could be
> confirmed by using an Intel CPUID program but I don't have a Conroe to test
> with.

You should be able to determine that just by looking at linpack results
relative to another MPU with known L1D size. But if you look at the
article I wrote, it's clear it's a 32KB L1D, and a 256 entry TLB.

> While on the subject, has anyone else noticed the change in Intel's docs in
> general? There is lots of sales-oriented stuff on new hardware, with
> click-through to How/Where To Buy, but not a lot of "meat".

Yup.

> This is a big
> change from their previous generous policy of access to detailed hardware
> specs by *anybody". There's a hint that more detailed info is available
> with a login for people who are "qualified" but even with my Software
> Developer Login I can't find anything on hardware details.

So, I've talked with the architects for MCW, and they have all said
that they are working on an optimization guide which discusses all the
gory details such as issue restrictions, known glass jaws and how to
avoid them, etc. etc. I'm sure Intel will put one out, but it is very
disappointing that it is so slow.

Of course, the irony is that most folks don't really read them. I
remember when the P4 came out, a lot of hte problems were pretty well
documented in the tuning manual. Of course, nobody in the press read
it at all. Then 3 years later someone 'discovers' that the P4 uses
replay mechanisms. It was a little funny, considering most folks had
known about it for a long time.

> Has the Intel documentation dept already been umm, "attritioned" maybe?...
> or is this a new Otellini-era policy to offer info only on a "need to know"
> basis? If so, it's a huge blunder IMO.

Naw, I doubt it. Intel needs the tuning documents for their customers
and partners. They are probably just a little slow getting a public
version out, no doubt there is an internal one which they can show to
key partners and software developers. However, for a document to go
public requires a lot of sanitization and effort.

DK

On 14 Sep 2006 11:20:17 -0700, "David Kanter" <(E-Mail Removed)> wrote:

>> In the Core 2 Duo Datasheet, 31327801.pdf, it plainly states "Two 16-KB
>> Level 1 data caches" and, in contrast to previous CPU Datasheets from
>> Intel, that's about all it says about L1 cache. There's no mention of TLB
>> anywhere in the document.
>
>That's clearly wrong.

That's been two months it's been wrong - nobody noticed yet?

>> The Xeon 5100 Datasheet says "Includes 32-KB Level 1 instruction and 32-KB
>> Level 1 data cache per core". Again, real info on the CPU is meagre and
>> concentrates on mechanical, electrical and thermal specs. Can we assume
>> that the Core 2 Duo Datasheet is just wrong? I'd think this could be
>> confirmed by using an Intel CPUID program but I don't have a Conroe to test
>> with.
>
>You should be able to determine that just by looking at linpack results
>relative to another MPU with known L1D size. But if you look at the
>article I wrote, it's clear it's a 32KB L1D, and a 256 entry TLB.

You're asking me to believe your article and ignore Intel's official
doc.;-) The last time I read something you wrote on AMD's K8L, you
contradicted what was discussed by an AMD architect, coulda been Hester, in
an interview article... to do with Load/Store reordering.

>> While on the subject, has anyone else noticed the change in Intel's docs in
>> general? There is lots of sales-oriented stuff on new hardware, with
>> click-through to How/Where To Buy, but not a lot of "meat".
>
>Yup.
>
>> This is a big
>> change from their previous generous policy of access to detailed hardware
>> specs by *anybody". There's a hint that more detailed info is available
>> with a login for people who are "qualified" but even with my Software
>> Developer Login I can't find anything on hardware details.
>
>So, I've talked with the architects for MCW, and they have all said
>that they are working on an optimization guide which discusses all the
>gory details such as issue restrictions, known glass jaws and how to
>avoid them, etc. etc. I'm sure Intel will put one out, but it is very
>disappointing that it is so slow.
>
>Of course, the irony is that most folks don't really read them. I
>remember when the P4 came out, a lot of hte problems were pretty well
>documented in the tuning manual. Of course, nobody in the press read
>it at all. Then 3 years later someone 'discovers' that the P4 uses
>replay mechanisms. It was a little funny, considering most folks had
>known about it for a long time.

It's not particularly the optimization guide I'm thinking of - just the
things that used to appear in CPU datasheets like accurate details of cache
sizes, associativity, TLB layout/lookup, MTRRs etc. there are whole
sections umm, missing... it's less complete and less informative. Could be
they've got one of them Social Scientists they employed a while back in
charge of docs who wants to umm humanize them... make them err, "easier to
read"... cater to a "wider audience"... etc.etc.:-)

>> Has the Intel documentation dept already been umm, "attritioned" maybe?...
>> or is this a new Otellini-era policy to offer info only on a "need to know"
>> basis? If so, it's a huge blunder IMO.
>
>Naw, I doubt it. Intel needs the tuning documents for their customers
>and partners. They are probably just a little slow getting a public
>version out, no doubt there is an internal one which they can show to
>key partners and software developers. However, for a document to go
>public requires a lot of sanitization and effort.

I'm not just talking about Core 2 here - the whole site is just less
navigable for getting at tech docs and I kept running into blocks and
circular references. In fact when I saw what looked like a promising URL a
couple of times, it burped and took me back to the Intel home page. I
really think something's going on here.

--
Rgds, George Macdonald

> >You should be able to determine that just by looking at linpack results
> >relative to another MPU with known L1D size. But if you look at the
> >article I wrote, it's clear it's a 32KB L1D, and a 256 entry TLB.
>
> You're asking me to believe your article and ignore Intel's official
> doc.;-)

LOL : ) Fair enough.

> The last time I read something you wrote on AMD's K8L, you
> contradicted what was discussed by an AMD architect, coulda been Hester, in
> an interview article... to do with Load/Store reordering.

Well, there's no such thing as the K8L, only deerhound. If there were
contradictions in my articles, they were probably stated as guesses
rather than facts. Sometimes I make inferences that seem reasonable
but are wrong. If I was right 100% of the time, I'd play the lotto a
lot more often : )

However, I think my track record on uarch is far better than most folks
out there. And if you look at memory access latency, it should be
apparent that Conroe has a 32KB L1D.

http://techreport.com/reviews/2006q3/core2/index.x?pg=4

> >> While on the subject, has anyone else noticed the change in Intel's docs in
> >> general? There is lots of sales-oriented stuff on new hardware, with
> >> click-through to How/Where To Buy, but not a lot of "meat".
> >
> >Yup.
> >
> >> This is a big
> >> change from their previous generous policy of access to detailed hardware
> >> specs by *anybody". There's a hint that more detailed info is available
> >> with a login for people who are "qualified" but even with my Software
> >> Developer Login I can't find anything on hardware details.
> >
> >So, I've talked with the architects for MCW, and they have all said
> >that they are working on an optimization guide which discusses all the
> >gory details such as issue restrictions, known glass jaws and how to
> >avoid them, etc. etc. I'm sure Intel will put one out, but it is very
> >disappointing that it is so slow.
> >
> >Of course, the irony is that most folks don't really read them. I
> >remember when the P4 came out, a lot of hte problems were pretty well
> >documented in the tuning manual. Of course, nobody in the press read
> >it at all. Then 3 years later someone 'discovers' that the P4 uses
> >replay mechanisms. It was a little funny, considering most folks had
> >known about it for a long time.

> It's not particularly the optimization guide I'm thinking of - just the
> things that used to appear in CPU datasheets like accurate details of cache
> sizes, associativity, TLB layout/lookup, MTRRs etc. there are whole
> sections umm, missing... it's less complete and less informative. Could be
> they've got one of them Social Scientists they employed a while back in
> charge of docs who wants to umm humanize them... make them err, "easier to
> read"... cater to a "wider audience"... etc.etc.:-)

Can you find an old data sheet with that information? To be perfectly
honest, I haven't seen anything really detailed except for the
optimization manaul. I could easily believe that over time the data
sheets get less data on them...especially as the folks buying the CPUs
become less technical. IOW, in 1990, the folks at Gateway and Dell
buying CPUs probably knew an awful lot about the tech, where as today,
I'm not so sure.

> >> Has the Intel documentation dept already been umm, "attritioned" maybe?...
> >> or is this a new Otellini-era policy to offer info only on a "need to know"
> >> basis? If so, it's a huge blunder IMO.
> >
> >Naw, I doubt it. Intel needs the tuning documents for their customers
> >and partners. They are probably just a little slow getting a public
> >version out, no doubt there is an internal one which they can show to
> >key partners and software developers. However, for a document to go
> >public requires a lot of sanitization and effort.
>
> I'm not just talking about Core 2 here - the whole site is just less
> navigable for getting at tech docs and I kept running into blocks and
> circular references. In fact when I saw what looked like a promising URL a
> couple of times, it burped and took me back to the Intel home page. I
> really think something's going on here.

I don't spend much time on their site...so I wouldn't really know.

DK

On 15 Sep 2006 13:26:26 -0700, "David Kanter" <(E-Mail Removed)> wrote:

>> >You should be able to determine that just by looking at linpack results
>> >relative to another MPU with known L1D size. But if you look at the
>> >article I wrote, it's clear it's a 32KB L1D, and a 256 entry TLB.
>>
>> You're asking me to believe your article and ignore Intel's official
>> doc.;-)
>
>LOL : ) Fair enough.
>
>> The last time I read something you wrote on AMD's K8L, you
>> contradicted what was discussed by an AMD architect, coulda been Hester, in
>> an interview article... to do with Load/Store reordering.
>
>Well, there's no such thing as the K8L, only deerhound. If there were
>contradictions in my articles, they were probably stated as guesses
>rather than facts. Sometimes I make inferences that seem reasonable
>but are wrong. If I was right 100% of the time, I'd play the lotto a
>lot more often : )

K8L has been used enough to denote AMD's next processor enough that it's
frankly picayune to dispute the use of the name... and deerhound sounds
like some kind of dog to me.;-) In fact I detest the way mfrs leak
internal code names, so that the gutter tech press can sound informed on
inside info, while at the same time never tying those code names back to an
official processor model.

>However, I think my track record on uarch is far better than most folks
>out there. And if you look at memory access latency, it should be
>apparent that Conroe has a 32KB L1D.
>
>http://techreport.com/reviews/2006q3/core2/index.x?pg=4

I'm not saying it doesn't - just that Intel should not have such glaring
and misleading errors in Datasheets after this time.

>> >Of course, the irony is that most folks don't really read them. I
>> >remember when the P4 came out, a lot of hte problems were pretty well
>> >documented in the tuning manual. Of course, nobody in the press read
>> >it at all. Then 3 years later someone 'discovers' that the P4 uses
>> >replay mechanisms. It was a little funny, considering most folks had
>> >known about it for a long time.
>
>> It's not particularly the optimization guide I'm thinking of - just the
>> things that used to appear in CPU datasheets like accurate details of cache
>> sizes, associativity, TLB layout/lookup, MTRRs etc. there are whole
>> sections umm, missing... it's less complete and less informative. Could be
>> they've got one of them Social Scientists they employed a while back in
>> charge of docs who wants to umm humanize them... make them err, "easier to
>> read"... cater to a "wider audience"... etc.etc.:-)
>
>Can you find an old data sheet with that information? To be perfectly
>honest, I haven't seen anything really detailed except for the
>optimization manaul. I could easily believe that over time the data
>sheets get less data on them...especially as the folks buying the CPUs
>become less technical. IOW, in 1990, the folks at Gateway and Dell
>buying CPUs probably knew an awful lot about the tech, where as today,
>I'm not so sure.

Find? I have the files right here and some are not that old. When P4 came
out, it had a large amount of detailed description of various elements;
some of it disappeared with later versions of the Datasheet, which had
improved info in othre areas, but this is the first time in >20 years that
Intel has a Datasheet for a new processor which has no such info. I'm
thinking maybe somebody retired, voluntarily or not.:-)

--
Rgds, George Macdonald

> >> The last time I read something you wrote on AMD's K8L, you
> >> contradicted what was discussed by an AMD architect, coulda been Hester, in
> >> an interview article... to do with Load/Store reordering.
> >
> >Well, there's no such thing as the K8L, only deerhound. If there were
> >contradictions in my articles, they were probably stated as guesses
> >rather than facts. Sometimes I make inferences that seem reasonable
> >but are wrong. If I was right 100% of the time, I'd play the lotto a
> >lot more often : )
>
> K8L has been used enough to denote AMD's next processor enough that it's
> frankly picayune to dispute the use of the name...

K8L was a term invented by a friend of mine...Charlie Demerjian at the
Inq. The codenames for external use at AMD are deerhound, bloodhound,
etc.

I'd just prefer to call it K8++, but I think some folks might not get
the joke.

> and deerhound sounds
> like some kind of dog to me.;-)

Heh, it's a good thing they didn't go with the K9 then

> In fact I detest the way mfrs leak
> internal code names, so that the gutter tech press can sound informed on
> inside info, while at the same time never tying those code names back to an
> official processor model.

I generally agree, I wish that mfgs would just use one code-name for
the same core. For instance, it would be nice if there was a single
codename to refer to Woodcrest, Conroe and Merom. Some folks use MCW,
etc. etc.

I do think part of it is making the press feel special.

> >However, I think my track record on uarch is far better than most folks
> >out there. And if you look at memory access latency, it should be
> >apparent that Conroe has a 32KB L1D.
> >
> >http://techreport.com/reviews/2006q3/core2/index.x?pg=4
>
> I'm not saying it doesn't - just that Intel should not have such glaring
> and misleading errors in Datasheets after this time.

That's a perfectly valid point.

> >Can you find an old data sheet with that information? To be perfectly
> >honest, I haven't seen anything really detailed except for the
> >optimization manaul. I could easily believe that over time the data
> >sheets get less data on them...especially as the folks buying the CPUs
> >become less technical. IOW, in 1990, the folks at Gateway and Dell
> >buying CPUs probably knew an awful lot about the tech, where as today,
> >I'm not so sure.
>
> Find? I have the files right here and some are not that old. When P4 came
> out, it had a large amount of detailed description of various elements;

What in particular? I believe you, but I'd love to know specificaly
what has changed since I don't pay that much attention to data sheets.
Optimziation manuals are much more valuable.

DK