"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> I've patched the code according to your suggestion. Result is:
> [ snip ]
OK, that test seems a little more believable. One point you didn't
consider is that on 64-bit machines, the integer bufnum really has
to be coerced to size_t to avoid overflow i
"Tom Lane" <[EMAIL PROTECTED]> writes:
>
> This is definitely going to tell us a lot more about the compiler's loop
> strength reduction algorithms than it is going to tell about the time to
> evaluate any one of these expressions in isolation. What's worse, the
> compiler would be quite within i
Hello,
With gcc-4 on Ubuntu AMD Athlon 2600 Barton:
[EMAIL PROTECTED]:~$ ./a.out
duration round 1 of array method: 0.539 ms
duration round 2 of array method: 0.529 ms
duration round 3 of array method: 0.530 ms
duration round 1 of mul method: 0.258 ms
duration round 2 of mul method: 5.563 ms
dur
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> The source code is attached.
>gettimeofday(&start_t, NULL);
>if (method == 0)
>{
> for (i = 0; i < NBuffers; i++)
> k = array[i];
>}
>if (method == 1)
>{
> for (i = 0; i < NBuffers; i++)
> k = start + i*BLCKSZ;
Gavin Sherry wrote:
Sun still calls Solaris SunOs - try doing uname -s on a Solaris box (or
look at a buildfarm solaris build info)
True. But my previous experience in university environments is that SunOS
usually refers to SunOS 2.6
I think I must be a lot older then you.
On Thu, 11 Aug 2005, Andrew Dunstan wrote:
>
>
> Gavin Sherry wrote:
>
> >>Or more than one hardware architecture (which you didn't even say what
> >>you tested...)
> >>
> >>
> >
> >Well, he tested on SunOS (!) and Linux -- I presume that's two
> >architectures.
> >
> >
>
> Sun still calls Solaris
Gavin Sherry wrote:
Or more than one hardware architecture (which you didn't even say what
you tested...)
Well, he tested on SunOS (!) and Linux -- I presume that's two
architectures.
Sun still calls Solaris SunOs - try doing uname -s on a Solaris box (or
look at a buildfarm sola
Mark Kirkwood wrote:
Looks to me like -O2 makes the difference very small (on this
platform/gcc combo) - is 5/169 worth doing?
Ahem - misunderstood your comment here, sorry.
Qingqing Zhou wrote:
compiled with "gcc testbuf.c". I tried -O2 actually, and it turns out
that
the timing is redu
FreeBSD 5.4 RELEASE gcc 3.4.2 on Intel dual PIII 1Ghz
[postgres:~/develop/c/testbuf]$ gcc -Wall -o testbuf testbuf.c
[postgres:~/develop/c/testbuf]$ ./testbuf
duration round 1 of array method: 1.737 ms
duration round 2 of array method: 1.676 ms
duration round 3 of array method: 1.527 ms
duration
"Tom Lane" <[EMAIL PROTECTED]> writes:
>
> Also, I would like to see the actual test code. I wonder whether what
> you measured is the ability of the compiler to optimize references to
> successive elements of an array inside a loop; that has little or
> nothing to do with the typical usage of Bu
On Thu, 11 Aug 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Thu, 11 Aug 2005, Qingqing Zhou wrote:
> >> It is said that the BufferBlockPointers is used to speedup the
> >> BufferGetBlock() macro. I compared three ways of getting block pointers.
>
> > Do you have results
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Thu, 11 Aug 2005, Qingqing Zhou wrote:
>> It is said that the BufferBlockPointers is used to speedup the
>> BufferGetBlock() macro. I compared three ways of getting block pointers.
> Do you have results for more recent gcc releases?
Or more than one h
On Thu, 11 Aug 2005, Qingqing Zhou wrote:
> It is said that the BufferBlockPointers is used to speedup the
> BufferGetBlock() macro. I compared three ways of getting block pointers.
> I.e., existing method (arrary method), calculating block pointer by adding
> base addr and offset*blockid method (
13 matches
Mail list logo
