In the last episode (Mar 16), Joachim Strmbergson said:
> In an earlier mail to the thread I pointed to the STREAM benchmark
> for memory sub systems. Additionally, I wrote that I knew there were
> another benchmark that tries to analyze word sizes, access latencies
> for the different memories in
Aloha!
In an earlier mail to the thread I pointed to the STREAM benchmark for
memory sub systems. Additionally, I wrote that I knew there were another
benchmark that tries to analyze word sizes, access latencies for the
different memories in the mem sub system. I know can name that benchmark
(or
:
:Noted.
:
:Is there a gcc PR associated with this?
:
:http://gcc.gnu.org/cgi-bin/gnatsweb.pl
:
:A GNATS searc for "freebsd kernel" didn't return anything.
:
:-Charles
No idea. Somewhere around 4.1 my -O2 and -Os kernel compiles just
stopped working. There was a bunch of stuff on the
rles Randall
Cc: Andrew Gallatin; [EMAIL PROTECTED]
Subject: Re: RE: Machines are getting too damn fast
:Which begs the question I've tried to ask a number of times in different
:forums. Who's working on P4 optimizations and code generation for the P4?
I'd be happy if GCC -O2 just w
:
:This explained in great detail exactly why people are seeing the performance
:they are from the P4 etc. The author knows his stuff.
:
:http://www.emulators.com/pentium4.htm
:
:Brandon
Heh heh. You can practically see the sweat popping off his face while
reading his article.
: Tuesday, March 06, 2001 1:08 PM
:To: Andrew Gallatin
:Cc: Matt Dillon; [EMAIL PROTECTED]
:Subject: Re: Machines are getting too damn fast
:
:
:On Tue, Mar 06, 2001 at 10:56:46 -0500, Andrew Gallatin wrote:
:> Matt Dillon writes:
:> >
:> > I modified my original C program agai
:Which begs the question I've tried to ask a number of times in different
:forums. Who's working on P4 optimizations and code generation for the P4?
I'd be happy if GCC -O2 just worked without introducing bugs. I want to
be able to compile the kernel with it again.
On Tue, Mar 06, 2001 at 10:56:46 -0500, Andrew Gallatin wrote:
> Matt Dillon writes:
> >
> > I modified my original C program again, this time to simply read
> > the data from memory given a block size in kilobytes as an argument.
> > I had to throw in a little __asm to do it ri
On Tue, 6 Mar 2001, Matt Dillon wrote:
> My understanding is that Intel focused on FP performance in the P4,
> and that it is very, very good at it. I dunno how to test it though.
>From the benchmarks tom's hardware / others did, I got the impression that
SSE2 performance is awesome, b
From: Matt Dillon [mailto:[EMAIL PROTECTED]]
>My understanding is that Intel focused on FP performance in the P4,
>and that it is very, very good at it. I dunno how to test it though.
>
>GCC generally does not produce very good code, but I would expect that
>it would get reasonabl
:How's your P4 for floating point? Is real-life perf as good as the
:specbench numbers would indicate, or do you need a better compiler
:than GCC to get any benefit from it? My wife is a statistician, and
:she runs some really fp intensive workloads. This Athlon is faster
:than the Serverworks
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>FWIW: 1.2GHz Athlon, VIA Apollo KT133 chipset, Asus A7V motherboard,
>(PC133 ECC Registered Dimms)
Note that the KT does *NOT* support ECC. A few places have claimed it does,
but the VIA chipset spec says it doesn't. The KV or KX does (I
Matt Dillon writes:
>
> I modified my original C program again, this time to simply read
> the data from memory given a block size in kilobytes as an argument.
> I had to throw in a little __asm to do it right, but here are my results.
> It shows about 3.2 GBytes/sec from
Matt Dillon <[EMAIL PROTECTED]> wrote:
> Subject: Re: Machines are getting too damn fast
>
> :throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its
> :overclocked) here on my desk with 256KB L2 cache:
> :
> :dd if=/dev/zero of=/dev/null bs=512k count=4
:IIRC, Intel is using a very different caching method on the P4 from
:what we are used to on just about every other x86 processor we've
:seen. Well, I can't remember if the data cache has changed much, but
:the instruction cache has. I doubt the difference in instruction
:cache behaviour would m
On Mon, 5 Mar 2001, Matt Dillon wrote:
> :throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its
> :overclocked) here on my desk with 256KB L2 cache:
> :
> :dd if=/dev/zero of=/dev/null bs=512k count=4000
> :4000+0 records in
> :4000+0 records out
> :2097152000 bytes transferred in
:throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its
:overclocked) here on my desk with 256KB L2 cache:
:
:dd if=/dev/zero of=/dev/null bs=512k count=4000
:4000+0 records in
:4000+0 records out
:2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec)
:
:dd if=/dev/zero
On Mon, 5 Mar 2001, Matt Dillon wrote:
> :On Mon, 5 Mar 2001, E.B. Dreger wrote:
> :
> :I've got a ServerWorks III HE-SL system with 512MB of two-way
> :interleaved PC133 SDRAM and dual PIII-800's. Is that close enough?
> ::-)
> :
> :Here is my "memory bandwidth test", much much simpler and less
:On Mon, 5 Mar 2001, E.B. Dreger wrote:
:
:I've got a ServerWorks III HE-SL system with 512MB of two-way
:interleaved PC133 SDRAM and dual PIII-800's. Is that close enough?
::-)
:
:Here is my "memory bandwidth test", much much simpler and less
:scientific than Matt's:
:
:dd if=/dev/zero of=/dev/n
On Mon, 5 Mar 2001, E.B. Dreger wrote:
> > Date: Sun, 04 Mar 2001 19:39:09 -0600
> > From: David A. Gobeille <[EMAIL PROTECTED]>
> >
> > It would also be interesting to see the numbers for an Athlon/PIII
> > system with DDR, if anyone has such a machine.
>
> Personally, I'd be [more] interested i
I believe DDR still has it bead (PC2100 that is), Rambus serailizes all writes
to 32 bit or 16 bit (an even 8 bit) depending on the modules. I haven't seen any
64bit RIMMs. Also, DDR scales higher (up to 333Mhz I think). Just wait for
that. I've pretty much given up on RamBus, I saw back in '96 wh
Aloha!
(Sorry for jumping right in to the thread here...)
This might be a good time to mention the STREAM benchmark developed by
John McCalpin. It measures sustained bandwidth of systems. The official
web page is at:
http://www.cs.virginia.edu/stream/
If you check the section under "PC-compati
:You should see what speed RamBus they were using, 600 or 800 Mhz. It is
:pretty fast for large memory writes and reads. It'd be cool to see how
:the different speeds stack up against one another. DDR comparisons would
:be cool too. Yeah, for the frequency, you have to take into account that
:the
> Date: Sun, 04 Mar 2001 19:39:09 -0600
> From: David A. Gobeille <[EMAIL PROTECTED]>
>
> It would also be interesting to see the numbers for an Athlon/PIII
> system with DDR, if anyone has such a machine.
Personally, I'd be [more] interested in a ServerWorks III HE core chipset
with four-way in
You should see what speed RamBus they were using, 600 or 800 Mhz. It is
pretty fast for large memory writes and reads. It'd be cool to see how
the different speeds stack up against one another. DDR comparisons would
be cool too. Yeah, for the frequency, you have to take into account that
these are
Tyler K McGeorge wrote:
>
> - Original Message -
> From: Matt Dillon <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, March 04, 2001 3:34 AM
> Subject: Machines are getting too damn fast
>
> | We need to find something more interesting then buildworlds to do on
> | t
On Sun, Mar 04, 2001 at 04:21:02AM -0600, Tyler K McGeorge wrote:
>
> - Original Message -
> From: Matt Dillon <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, March 04, 2001 3:34 AM
> Subject: Machines are getting too damn fast
>
> | We need to find something more inte
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tyler K McGeorge
Sent: 04 March 2001 10:21
To: Matt Dillon; [EMAIL PROTECTED]
Subject: Re: Machines are getting too damn fast
- Original Message -
From: Matt Dillon <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sund
- Original Message -
From: Matt Dillon <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 04, 2001 3:34 AM
Subject: Machines are getting too damn fast
| We need to find something more interesting then buildworlds to do on
| these machines.
Let's just complicate th
29 matches
Mail list logo
