Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Mark Mielke <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
My goodness that's a hardware-dependent proposal. Shall we discuss
how many CPUs there are where an integer division is *slower* than
a floating-point op?
Do you have one in m
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Mark Mielke <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> My goodness that's a hardware-dependent proposal. Shall we discuss
>>> how many CPUs there are where an integer division is *slower* than
>>> a floating-point op?
>
>> Do you have one in mind,
Martijn van Oosterhout wrote:
On Wed, Nov 14, 2007 at 06:57:18PM -0800, Josh Berkus wrote:
The question is, for our most common platforms (like AMD and Intel) is the FPU
notably slower/more contended than integer division? I'd the impression that
it was, but my knowledge of chip architectur
On Wed, Nov 14, 2007 at 06:57:18PM -0800, Josh Berkus wrote:
> The question is, for our most common platforms (like AMD and Intel) is the
> FPU
> notably slower/more contended than integer division? I'd the impression that
> it was, but my knowledge of chip architectures is liable to be out of
Josh Berkus <[EMAIL PROTECTED]> writes:
> Nah, if it's only Niagara, it's not worth bothering.
It's not only that aspect of it --- it's that I am 100% convinced that
Magne has misidentified the source of whatever FPU contention he's
seeing. The floating-point code in s_lock() is executed only jus
Greg,
> That says precisely nothing about the matter at hand. Someone should
> simply change it and benchmark it in pgsql. I doubt you'll see a
> difference there on regular AMD/Intel ... and if it makes the sun
> hyperthreaded cpu happier...
Nah, if it's only Niagara, it's not worth bothering.
Gregory Maxwell wrote:
On Nov 14, 2007 10:12 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
http://www.intel.com/performance/server/xeon/intspd.htm
http://www.intel.com/performance/server/xeon/fpspeed.htm
That says precisely nothing about the matter at hand. Someone should
simply change it and
On Nov 14, 2007 10:12 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> http://www.intel.com/performance/server/xeon/intspd.htm
> http://www.intel.com/performance/server/xeon/fpspeed.htm
That says precisely nothing about the matter at hand. Someone should
simply change it and benchmark it in pgsql.
On Nov 14, 2007, at 6:57 PM, Josh Berkus wrote:
Tom,
I've got one upstairs (HPPA), and I believe that it's actually a
pretty
common situation in scientifically-oriented workstations from a few
years back.
Last I checked, scientific workstations aren't exactly a common
platform for
Post
Josh Berkus wrote:
Tom,
I've got one upstairs (HPPA), and I believe that it's actually a pretty
common situation in scientifically-oriented workstations from a few
years back.
Last I checked, scientific workstations aren't exactly a common platform for
PostgreSQL servers.
The question is,
Tom,
> I've got one upstairs (HPPA), and I believe that it's actually a pretty
> common situation in scientifically-oriented workstations from a few
> years back.
Last I checked, scientific workstations aren't exactly a common platform for
PostgreSQL servers.
The question is, for our most commo
On 11/14/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> The other problem with using modulo is that it makes the result depend
> mostly on the low-order bits of the random() result, rather than mostly
> on the high-order bits; with lower-grade implementations of random(),
> the lower bits are materiall
On Wed, 14 Nov 2007, Mark Mielke wrote:
The other problem with using modulo is that it makes the result depend
mostly on the low-order bits of the random() result, rather than mostly
on the high-order bits; with lower-grade implementations of random(),
the lower bits are materially less random t
Mark Mielke <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> My goodness that's a hardware-dependent proposal. Shall we discuss
>> how many CPUs there are where an integer division is *slower* than
>> a floating-point op?
> Do you have one in mind, or is this a straw man? :-)
I've got one upstai
Tom Lane wrote:
=?ISO-8859-1?Q?Magne_M=E6hre?= <[EMAIL PROTECTED]> writes:
I understand the reasoning for the backoff (as of the discussion on
2003-08-05), but is there any particular reason for using floating
point operations here ? Maybe a modulo would be just as good (or
better since it
=?ISO-8859-1?Q?Magne_M=E6hre?= <[EMAIL PROTECTED]> writes:
> I understand the reasoning for the backoff (as of the discussion on
> 2003-08-05), but is there any particular reason for using floating
> point operations here ? Maybe a modulo would be just as good (or
> better since it doesn't involv
Magne Mæhre wrote:
I was playing with a Nevada server and noticed a rush on the FPU
(the Nevada has a single shared FPU for its 32 threads).
Probably you mean Niagara ;-).
Zdenek
---(end of broadcast)---
TIP 1: if posting/readi
I was playing with a Nevada server and noticed a rush on the FPU
(the Nevada has a single shared FPU for its 32 threads).
Looking at the spinlock code, I found :
cur_delay += (int) (cur_delay *
((double) random() / (double) MAX_RANDOM_VALUE) + 0.5);
I understand the reasoning for the
18 matches
Mail list logo
