| Author |
Message |
Niels Jørgen Kruse
Guest
|
 Posted:
Thu Oct 13, 2005 12:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
Andi Kleen <freitag@alancoxonachip.com> wrote:
[quote]nospam@ab-katrinedal.dk (Niels Jørgen Kruse) writes:
Andi Kleen <freitag@alancoxonachip.com> wrote:
Seongbae Park <Seongbae.Park@Sun.COM> writes:
Some, if not most, variants of recent Pentium 4 (smithfield ?)
have L2 cache with 64-byte line size.
It only does bus IO in 128 byte chunks, so the effective one is 128 bytes.
You have the prospect of being able to age out the half of the 128 byte
chunk that is unused.
And what would you do with the empty half if you cannot refill it?
[/quote]
I assumed associativity > 1 and allocation block = 64 byte. In that case
selection of victim for each of the 2 parts would be independent.
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark |
|
| Back to top |
|
 |
EdG
Guest
|
| Posted:
Thu Oct 13, 2005 12:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
On 11 Oct 2005 14:04:04 -0700, "Nathan Bates" <nathanbates99@yahoo.com>
wrote:
[quote]Pentium M has all the right ingredients for total world domination:
low power consumption, short pipeline stages, hi-performance.
[/quote]
Are they x86-64? |
|
| Back to top |
|
|
Jason Ozolins
Guest
|
| Posted:
Thu Oct 13, 2005 5:37 am Post subject:
Re: Pentium M to become THE CPU |
|
|
Oliver S. wrote:
[>Mitch Alsup wrote:] <- added by J.O.
[quote]In Opteron, for example, the address associated with an L2 miss can
arrive at the memory controller in less than 2ns, and data arriving at
the pins from the DIMMs can arrive back at the CPU in a similar number.
Yes, but you have to consider the speculative snoops to other CPUs in
the ccNUMA domain also!
[/quote]
If a node has an L2 miss on memory which is on its local DRAM controller,
can't it just speculatively initiate the load from local DRAM and then drop
the results if the snoop issued in parallel indicates that the line is owned
by another node? If the snoop latency is less than the memory latency, then
you would at most wait for the memory load in this case.
[quote]A 4 Node Opteron system has ~4 times as much DRAM bandwidth as a 4
node Pentium (single) FSB system and plenty of chip-to-chip bandwidth
to route the data to where it is needed.
It has about four times the store-bandwith - but not the load-bandwidth
due to speculative snoops.
[/quote]
The load bandwidth is indeed limited by the snoop interconnect. If the loads
are overlapped with snoops as I suggested above, the load latency to local
memory is not, unless the interconnect is so saturated that a snoop takes
longer than a memory read.
On a big 24 processor UltraSPARC III/IV system (E6900), using the Fireplane
interconnect, you will see nasty limits on the overall sustained load
bandwidth (9.6GB/sec) due to the snoop interconnect maxing out. AFAIK the
bigger Sun systems use cache directories to partition their snoop broadcast
domains.
-Jason |
|
| Back to top |
|
|
Oliver S.
Guest
|
| Posted:
Thu Oct 13, 2005 6:10 am Post subject:
Re: Pentium M to become THE CPU |
|
|
[quote]If a node has an L2 miss on memory which is on its local DRAM
controller, can't it just speculatively initiate the load from
local DRAM and then drop the results if the snoop issued in parallel
indicates that the line is owned by another node?
[/quote]
Of course it can; and didn't I mention that somewhere in this
thread? I thought I named this kind of load a "speculative load".
[quote]If the snoop latency is less than the memory latency, then
you would at most wait for the memory load in this case.
[/quote]
I'll bet that the snoop-latency is higher because it travels through
very tight hypertransport channels and on large machines with four or
eight CPUs even through some other CPUs.
[quote]On a big 24 processor UltraSPARC III/IV system (E6900), using the
Fireplane interconnect, you will see nasty limits on the overall
sustained load bandwidth (9.6GB/sec) due to the snoop interconnect
maxing out.
[/quote]
Hasn't this architecture duplicate tags in the chipset? Those large
machines are very expensive anyway, so the duplicate tags wouldn't
increase the whole costs significantly. |
|
| Back to top |
|
|
Jan Vorbrüggen
Guest
|
| Posted:
Thu Oct 13, 2005 8:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
[quote]So for high-performance-applications you would have to nail a thread
to a certain CPU and use an API that would give you memory-pages that
physically map to the memory attached to the CPU. But I'm not aware of
any OS that supports this processor-affine allocations.
[/quote]
VMS on ALpha and IA-64 does it. IIRC, DEC's Unix for Alpha and IA-64
(whatever marketing might be calling it right now) does also. I strongly
suspect SGI's OSes for their MIPS- and IA-64-based systems does as well.
Jan |
|
| Back to top |
|
|
Anton Ertl
Guest
|
| Posted:
Thu Oct 13, 2005 8:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
Andi Kleen <freitag@alancoxonachip.com> writes:
[quote][1] Actually with lmbench a newer Intel dual core systems reports a lower
memory latency to me than on an A64, but I suspect their prefetch
algorithms became so good they broke lmbench ;-)
[/quote]
Well, for the original lmbench that's not very hard.
We had a discussion about that last year (and some of the results are
reflected in <2004Jul24.204851@mips.complang.tuwien.ac.at> ff.), and I
then got a message from Carl Staelin (one of the lmbench people that
lmbench-3.0-a4 (and presumably later versions) has two memory access
patterns: sequential strided and random. So, with the random access
pattern you should be able to disable the stream buffers of the CPUs.
Followups set to comp.arch.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html |
|
| Back to top |
|
|
Oliver S.
Guest
|
| Posted:
Thu Oct 13, 2005 8:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
[quote]VMS on ALpha and IA-64 does it. IIRC, DEC's Unix for Alpha and IA-64
(whatever marketing might be calling it right now) does also. I strongly
suspect SGI's OSes for their MIPS- and IA-64-based systems does as well.
[/quote]
Cool! So number-crunching apps would simply stick their
threads to the cores and allocate processor-affine. |
|
| Back to top |
|
|
Andi Kleen
Guest
|
| Posted:
Thu Oct 13, 2005 1:44 pm Post subject:
Re: Pentium M to become THE CPU |
|
|
"Oliver S." <Follow.Me@gmx.net> writes:
| Quote: | you memory-pages that physically map to the memory attached to the CPU.
But I'm not aware of any OS that supports this processor-affine allocations.
|
It's pretty much standard on any NUMA aware OS (Linux, Solaris, Windows Server 2k3)
-Andi |
|
| Back to top |
|
|
Andi Kleen
Guest
|
| Posted:
Thu Oct 13, 2005 1:47 pm Post subject:
Re: Pentium M to become THE CPU |
|
|
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
| Quote: | Andi Kleen <freitag@alancoxonachip.com> writes:
[1] Actually with lmbench a newer Intel dual core systems reports a lower
memory latency to me than on an A64, but I suspect their prefetch
algorithms became so good they broke lmbench ;-)
Well, for the original lmbench that's not very hard.
|
Test was with one of the 3.x alphas.
| Quote: | We had a discussion about that last year (and some of the results are
reflected in <2004Jul24.204851@mips.complang.tuwien.ac.at> ff.), and I
then got a message from Carl Staelin (one of the lmbench people that
lmbench-3.0-a4 (and presumably later versions) has two memory access
patterns: sequential strided and random. So, with the random access
pattern you should be able to disable the stream buffers of the CPUs.
|
Don't underestimate the predictors. They are good at finding patterns
even sometimes suprising for a human.
-Andi |
|
| Back to top |
|
|
Trent
Guest
|
| Posted:
Thu Oct 13, 2005 2:43 pm Post subject:
Re: Pentium M to become THE CPU |
|
|
On 12 Oct 2005 17:46:25 GMT salfter@salfter.diespammersdie.dyndns.org
(Scott Alfter) wrote in Message id:
<434d4bf1$0$28781$9a6e19ea@news.newshosting.com>:
| Quote: | (One of these days, I'll build a controller for my beer fridges so I can
free up the Apple IIs that are currently running them (a IIGS on one and a
IIe on the other). To simplify the software-porting effort, it'll most
likely be built around a 6502, or something compatible with it. It's not
like monitoring the temperature and switching the compressor on and off
requires dual Opterons or something insane like that.)
|
Even a 6502 is overkill. Why not use a simple 8 pin device like this?
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2735
The only additional thing you'd need aside from a power source is a
transistor, a diode, and a relay. You can program the device with a
parallel port. |
|
| Back to top |
|
|
nobody@nowhere.net
Guest
|
| Posted:
Thu Oct 13, 2005 4:15 pm Post subject:
Re: Pentium M to become THE CPU |
|
|
On Thu, 13 Oct 2005 01:33:26 +0200, "Oliver S." <Follow.Me@gmx.net>
wrote:
| Quote: | Pentium M has all the right ingredients for total world domination:
low power consumption, short pipeline stages, hi-performance.
Are they x86-64?
Even the upcoming dual-core incarnation of the Pentium-M won't
be capable of x86-64 and it seems that this version even miss VT
technology; but both are not strong arguments for Notebook-systems.
|
The original post was about P-M dominating the _world_, not just
thin-n-lite. And even there, Turion is gaining the market share,
apparently not at the expense of VIA, Transmeta, and Apple, but rather
Intel. |
|
| Back to top |
|
|
Scott Alfter
Guest
|
| Posted:
Thu Oct 13, 2005 11:34 pm Post subject:
Re: Pentium M to become THE CPU |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article <pqask1dio0nuip9atb9p4h4j8k9027pl0h@4ax.com>,
Trent <none@dev.nul.pissoff> wrote:
| Quote: | On 12 Oct 2005 17:46:25 GMT salfter@salfter.diespammersdie.dyndns.org
(Scott Alfter) wrote in Message id:
434d4bf1$0$28781$9a6e19ea@news.newshosting.com>:
(One of these days, I'll build a controller for my beer fridges so I can
free up the Apple IIs that are currently running them (a IIGS on one and a
IIe on the other). To simplify the software-porting effort, it'll most
likely be built around a 6502, or something compatible with it. It's not
like monitoring the temperature and switching the compressor on and off
requires dual Opterons or something insane like that.)
Even a 6502 is overkill. Why not use a simple 8 pin device like this?
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2735
The only additional thing you'd need aside from a power source is a
transistor, a diode, and a relay. You can program the device with a
parallel port.
|
1) It doesn't appear to have an ability to enforce a minimum off-time. If
you repeatedly turn the compressor back on too soon after it has shut off,
that'll shorten its life. Choosing setpoints that are far-enough apart
might minimize this, but that would result in the temperature not being
as tightly-regulated as it could be.
2) It doesn't appear to have a way to slowly ramp the temperature up/down.
If the fridge is at 50 degrees and you want it to go up to 70 for a
diacetyl rest and then down to 35 for lagering, you want those
temperature changes to be made slowly (at a rate of maybe 1 degree per
hour).
These are things for which some sort of microprocessor control is needed. A
6502 might be overkill, but it's what I know, so there's less time getting
up to speed with an unfamiliar instruction set. I'm currently using DS18B20
sensors controlled by Apple IIs through a little bit of custom hardware, so
I already have software for the 6502 that talks to 1-Wire devices. Porting
that to another 6502-based machine would take minimal effort.
(If anyone's interested, the 1-Wire software is the first link at
http://alfter.us/a2soft.shtml.)
I also have the IIs graphing the temperature for the past ~4 hours; this
functionality would most likely go away, as it's (more or less) a curiosity
that was relatively easy to implement.
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFDTqibVgTKos01OwkRAib5AKCtqvU9XJIhNcX/y2KxRhFTJ3mYLQCg6O2H
IwAKYv22azX/G20ePQ+6RpI=
=WzMq
-----END PGP SIGNATURE----- |
|
| Back to top |
|
|
Bill Davidsen
Guest
|
| Posted:
Fri Oct 14, 2005 12:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
MitchAlsup@aol.com wrote:
| Quote: | Andi Kleen wrote:
If the processor waits at any point because DRAM data has not arrived
and the CPU has nothing left to try to do, then you are in a latency
bound situation and the FSB looses. More bandwidth does not speed up
latency bound problems.
In addition the on-die approach with the HyperTransport fabric
interconnect gives you the property that as you add CPUs, you also add
DRAM bandwidth and bisection bandwidth. A 4 Node Opteron system has ~4
times as much DRAM bandwidth as a 4 node Pentium (single) FSB system
and plenty of chip-to-chip bandwidth to route the data to where it is
needed.
But you said latency was the issue, not bandwidth. Or do you believe |
that having to get data out of memory on another CPU introduces no latency?
--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com |
|
| Back to top |
|
|
Bill Davidsen
Guest
|
| Posted:
Fri Oct 14, 2005 12:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
Ketil Malde wrote:
| Quote: | "Nathan Bates" <nathanbates99@yahoo.com> writes:
Pentium M has all the right ingredients for total world domination:
low power consumption, short pipeline stages, hi-performance.
Mediocre FP performance, few available motherboards, high price, no
SMP support?
For the price of a high end Pentium M, I can get a dual core AMD where
each core has equivalent integer performance and much better FP. Sure
Pentium M is attractive for some purposes, but total world domination
is still a way off, IMO.
And you can heat your house in the winter. The P-M is really low power |
compared to Opteron, and of course P4 is in a class by itself for heat.
The SMP and FP issues are supposedly being addressed soon, as will
EMT64, current advantage is power. AMD realized this and recently
offered a mobil chip to be more competitive, so I guess AMD saw the need.
I don't think the P-M is going to make everything else go away, but at
the moment the play is in low power, no matter what the O.P. thinks.
I'd like to get a dual dual-core system, but my net will be a single
chip Intel-DC to be compatible with other things I support.
--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com |
|
| Back to top |
|
|
Bill Davidsen
Guest
|
| Posted:
Fri Oct 14, 2005 12:15 am Post subject:
Re: Pentium M to become THE CPU |
|
|
nobody@nowhere.net wrote:
| Quote: | On Thu, 13 Oct 2005 01:33:26 +0200, "Oliver S." <Follow.Me@gmx.net
wrote:
Pentium M has all the right ingredients for total world domination:
low power consumption, short pipeline stages, hi-performance.
Are they x86-64?
Even the upcoming dual-core incarnation of the Pentium-M won't
be capable of x86-64 and it seems that this version even miss VT
technology; but both are not strong arguments for Notebook-systems.
The original post was about P-M dominating the _world_, not just
thin-n-lite. And even there, Turion is gaining the market share,
apparently not at the expense of VIA, Transmeta, and Apple, but rather
Intel.
With the exception of VIA, my perception is that there isn't a hell of a |
lot of market share to take other than Intel's. I'm considering the low
power market, some "laptops" are just portable desktops, and you can't
use them on your lap if you ever plan on having children.
--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in