On 3/16/2009 7:37 AM, clipka wrote:
> Chambers<ben### [at] pacificwebguycom>  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?

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.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

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.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> On 3/15/2009 5:37 PM, dkanter wrote:
> > I'm benchmarking a system and if I use some custom compiled results, not only
> > does that add a lot of work to my plate (since I have no clue what condition
> > the source code is in), but it also makes my results much more difficult to
> > reproduce (and I'd need to install yet another set of tools on the test system).
>
> 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.
>
> --
> ...Chambers
> www.pacificwebguy.com

There seem to be quite a few questions, and I'll respond to them all at once.

RE: 32b v. 64b from Chambers

I'll be using Windows Server 2008 (64).  The problem with 32 bit binaries is
that they are fairly different than 32 bit ones (e.g. registers) and tend to
de-emphasize the pressure on the caches and TLBs.  When you use a 64 bit app,
you get 2x the registers, but all your pointers are 64 bits instead of 32b...so
your caches are effectively smaller.  It's just part and parcel of using x86 and
I

Good question though.

RE: Compiling from Clipka and Jim Henderson

I'm assuming that the 3.7 beta 30 was available online at some point (i.e. there
was an official beta) but taken down at the beginning of March.  If there was no
official beta 30, then that is, as you pointed out an entirely different can of
worms.  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*).

That's the main reason why I don't want to try and compile the source code.  I
like things to be readily reproducible.  It's quite enough to be running with
pre-release hardware, there's no need for more uncertainty and complexity.

And yes Jim, I'm not afraid to admit that some small part of this is that I'd
rather not get my hands dirty with the POV-Ray codebase.  That's really a 2nd
or 3rd order motivation next to the issue of reproducibility, but I'm not
afraid to admit I'm lazy.

My goal is not to work on POV-Ray.  I currently use POV-Ray to measure
performance for systems and I think that it serves POV-Ray users both by
setting performance expectations and publicity of POV-Ray.

So if someone can help me that'd be great.  Has anyone perhaps downloaded 3.7
beta 30 for Win64?  Could you share the files or email them to me?  Or maybe
one of the contributors can go back through and grab beta 30 for me.

David

Post a reply to this message

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] pacificwebguycom> 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