 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 16 Mar 2009 18:18:16 -0700, Chambers wrote:
> On 3/16/2009 9:50 AM, Jim Henderson wrote:
>> What, so you'd rather offload the work from your plate to the
>> developers who volunteer their efforts to develop the software?
>>
>> Jim
>
> That's not exactly fair; he's not asking anyone to do the work for him,
> he's asking if the work's already been done.
Fair enough, but he did respond to your response saying that he didn't
want to compile it himself and that your suggestion wasn't constructive.
Just rubbed me the wrong way - we seem to have a lot of people who come
in here and demand that the beta be updated, and they don't seem to
understand that the people who do the work on this stuff volunteer their
time.
But perhaps I did overreact.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 16 Mar 2009 10:37:52 -0400, clipka wrote:
> Chambers <ben### [at] pacificwebguy com> wrote:
>> Fair enough. Just out of curiosity, is there a reason you can't use
>> the 32 bit builds? They run just fine under Vista x64, and should be
>> OK under XP if that's what you're using.
>
> Hum... benchmarking 64-bit systems with a 32-bit app? Doesn't seem to
> make much sense to me. Sure, they will run, but will the results say
> anything about 64-bit performace?
Generally 64-bit and 32-bit performance are going to be very similar; the
advantage to 64-bit systems is the ability to address more memory.
But I'd agree with Ben's assertion that if you benchmark using the same
app compiled either 32-bit or 64-bit on different platforms, you'll get a
reasonable measure of comparative performance.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"dkanter" <dka### [at] gmailcom> wrote:
> The whole goal of this exercise is for me to get a *modern* and
> *official* beta for 64 bit Windows (and an older official beta counts, as long
> as it's not *too old*).
Note that any beta older than .30 has expired beyond repair on December 31,
2008, so to get them running you would have to mess with the system clock.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/16/2009 7:07 PM, Jim Henderson wrote:
> But perhaps I did overreact.
I think just about everyone here has "overreacted" to FAQs, for example
the perennial "When will it be released?" :)
--
...Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 16 Mar 2009 23:00:38 -0700, Chambers wrote:
> On 3/16/2009 7:07 PM, Jim Henderson wrote:
>> But perhaps I did overreact.
>
> I think just about everyone here has "overreacted" to FAQs, for example
> the perennial "When will it be released?" :)
True, very true. Often times those FAQ's can be answered by reading
what's already been said on the matter. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> If what you want to do is compare different 64 bit systems to each
> other, then it's possible that this will suit your needs completely.
> Especially considering that the major bottleneck in POV is the double
> precision FPU, which is the same either in 32 or 64 bit mode.
Except that the de-facto chip for floating point calculations in 64-bit
intel-based processors is SSE, while in 32-bit systems it's the FPU. This
means that most compilers will usually automatically use SSE when compiling
for an x86-64 target and FPU when compiling for an x86-32 target.
(x86-64 processors have a FPU and modern x86-32 processors have SSE, but
in the former the FPU is "deprecated" and thus compilers will by default
generate SSE code because x86-64 is guaranteed to have support. In the latter,
however, SSE support is not necessarily guaranteed and thus compilers will
by default generate FPU code, unless specifically told to generate SSE code.)
There may be relevant differences in speed between a 32-bit FPU-using
executable and a 64-bit SSE-using executable when run on a 64-bit system
because of this.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> Generally 64-bit and 32-bit performance are going to be very similar; the
> advantage to 64-bit systems is the ability to address more memory.
Except that the x86-64 architecture has more processor registers than
the x86-32 architecture, which means that 64-bit executables can be
optimized by the compiler better than 32-bit ones. This can cause a
measurable difference in speed.
(OTOH 64-bit programs will inherently consume more memory than 32-bit
ones, which may also affect speed the other way around. Which one is more
significant with POV-Ray, hard to say. I'd say the registers probably win,
though.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
> > If what you want to do is compare different 64 bit systems to each
> > other, then it's possible that this will suit your needs completely.
> > Especially considering that the major bottleneck in POV is the double
> > precision FPU, which is the same either in 32 or 64 bit mode.
>
> Except that the de-facto chip for floating point calculations in 64-bit
> intel-based processors is SSE, while in 32-bit systems it's the FPU.
Uh - "chip"? I guess this wording might (re-) trigger some discussion... :P
> This
> means that most compilers will usually automatically use SSE when compiling
> for an x86-64 target and FPU when compiling for an x86-32 target.
We're talking about POV-Ray here, the 32-bit release of which installs with SSE
support enabled on suitable systems. At least that's what the beta page claims.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 18 Mar 2009 04:21:22 -0400, Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> Generally 64-bit and 32-bit performance are going to be very similar;
>> the advantage to 64-bit systems is the ability to address more memory.
>
> Except that the x86-64 architecture has more processor registers than
> the x86-32 architecture, which means that 64-bit executables can be
> optimized by the compiler better than 32-bit ones. This can cause a
> measurable difference in speed.
>
> (OTOH 64-bit programs will inherently consume more memory than 32-bit
> ones, which may also affect speed the other way around. Which one is
> more significant with POV-Ray, hard to say. I'd say the registers
> probably win, though.)
Interesting, now that's something I didn't know.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/2009 1:21 AM, Warp wrote:
> Except that the x86-64 architecture has more processor registers than
> the x86-32 architecture, which means that 64-bit executables can be
> optimized by the compiler better than 32-bit ones. This can cause a
> measurable difference in speed.
>
> (OTOH 64-bit programs will inherently consume more memory than 32-bit
> ones, which may also affect speed the other way around. Which one is more
> significant with POV-Ray, hard to say. I'd say the registers probably win,
> though.)
Both true, which is why you can't compare a 32bit app on one system to a
64 bit app on another.
However, there's nothing wrong with comparing the same 32 bit app on two
different 64 bit systems.
--
...Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
