 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dennis Clarke wrote:
>
> Mark Gordon wrote:
> >
> > Ron Parker wrote:
> > >
> > > On Tue, 10 Apr 2001 12:53:43 -0400, Dennis Clarke wrote:
> > > >I use Sun Solaris as my primary workstation so I can help you with this.
> > > >First you will need to get a recent copy of Pov-Ray and the binaries on the
> > > >Pov-Ray site are grossly out of date with no hope of that changing. God only
> > > >knows why.
> > >
> > > Something about none of us having a Sun machine to test them on. Anybody
> > > has an old SparcStation they were just gonna throw out, let me know.
> >
> > I'm flirting with the notion of picking up a SunBlade at the current
> > price, but it may be a few months (maybe after SIGGRAPH).
> >
> > -Mark Gordon
>
> Don't do it Mark! Those things are flowing through to people that simply
> don't know any better. The SunBlade 100 is simply Sun's way of recoving their
> initial R&D expenses on the SunFire processor. The SunBlade 100 does not have
> an UltraSparc III processor. It has an UltraSparc IIe processor with little
> or no effective cache. No one in the Sun world would consider a processor
> with 256k of cache when the currently shipping UltraSparc II processors have
> 4Mb and 8Mb of cache. That little box is cheap for a reason. Wait a little
> while. In a rapidly falling market you will see the older systems [ Sun Ultra
> 2 for example ] dropping in price. There is a system on eBay right now with
> dual 300MHz processors and 256Mb RAM for next to nothing [ $1500.00 ] with a
> Creator Card for graphics. Don't spend your hard earned money on that
> SunBlade 100 junk. Get an old Ultra 2 or Ultra 60 with real processors for
> about the same price and get great performance.
>
> Dennis
To be honest, I don't need processing power; I need something I can use
to build binaries. Cache is nice, but if the binaries build a bit
slower, it doesn't matter that much to me. Don't worry; I won't shame
Sun with my benchmarks. ;-)
Still, it's probably going to be a few months before it happens, so I'll
see what's on the market in a few months.
-Mark Gordon
-Mark Gordon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 12 Apr 2001 01:35:48 -0400, Mark Gordon wrote:
>To be honest, I don't need processing power; I need something I can use
>to build binaries. Cache is nice, but if the binaries build a bit
>slower, it doesn't matter that much to me. Don't worry; I won't shame
>Sun with my benchmarks. ;-)
You can build binaries on Linux. You only need the Sun for making sure
they work.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Thu, 12 Apr 2001 01:35:48 -0400, Mark Gordon wrote:
> >To be honest, I don't need processing power; I need something I can use
> >to build binaries. Cache is nice, but if the binaries build a bit
> >slower, it doesn't matter that much to me. Don't worry; I won't shame
> >Sun with my benchmarks. ;-)
>
> You can build binaries on Linux. You only need the Sun for making sure
> they work.
>
> --
> Ron Parker http://www2.fwi.com/~parkerr/traces.html
> My opinions. Mine. Not anyone else's.
Good point. I'd considered cross-compiling, but it was rather pointless
without a way to test. I suppose a beefier machine would make the
testing go faster. Even though it takes a while to compile POV-Ray, it
takes a lot longer to test it thoroughly...
-Mark Gordon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Gordon wrote:
>
> To be honest, I don't need processing power; I need something I can use
> to build binaries. Cache is nice, but if the binaries build a bit
> slower, it doesn't matter that much to me. Don't worry; I won't shame
> Sun with my benchmarks. ;-)
>
> Still, it's probably going to be a few months before it happens, so I'll
> see what's on the market in a few months.
>
> -Mark Gordon
Ah well, that's a different issue then now isn't it. So, do you know if
you will want to build binaries that are specifically targeted for the
UltraSparc chip with VIS extensions or will backward compatibility to
older Sparc chips be ok? From what I know you can create binaries that
are targeted thus :
Really OLD Sparc V1: Sun demand paged SPARC executable dynamically linked
OLD Sparc V1 : ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, not stripped
UltraSparc : ELF 32-bit MSB executable SPARC32PLUS Version 1,
V8+ Required, UltraSPARC1 Extensions Required,
dynamically linked, stripped
UltraSparc 64bit : ELF 64-bit MSB executable SPARCV9 Version 1,
dynamically linked, not stripped
You can use either gcc or the Forte development tools ( $$ !! ) to generate
the binaries for all of the above. I can not remember the last time that I
saw anyone create binaries for the original Sparc chip circa 1991 [ or
there-about ]. The gcc compiler will not do a very good job with 64bit apps
and you will need the Forte tools to do your work justice. Everything else
can be done on a rock bottom UltraSparc system. I think that an old Ultra5
will do nicely.
Dennis
ps: I'm not sure what the binaries for the new SunFire chip will be like but
I expect ELF 64-bit MSB executable SPARCV9 Version 2 or something like it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dennis Clarke <dcl### [at] interlog com> wrote:
: UltraSparc 64bit : ELF 64-bit MSB executable SPARCV9 Version 1,
: dynamically linked, not stripped
I once compiled a 64-bit compile of povray for UltraSparc using Sun's own
cc compiler (full optimizations on, of course). I thought it would kick ass.
To my disappointment the 32-bit gcc compile was faster. It seems that
gcc can optimize better even with non-native code (that is, code made for
older sparcs).
PS: I'm really waiting for a gcc that supports 64-bit UltraSparc code...
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ad8cade@news.povray.org> , Warp <war### [at] tagpovrayorg>
wrote:
> I once compiled a 64-bit compile of povray for UltraSparc using Sun's own
> cc compiler (full optimizations on, of course). I thought it would kick ass.
> To my disappointment the 32-bit gcc compile was faster. It seems that
> gcc can optimize better even with non-native code (that is, code made for
> older sparcs).
Maybe it was mostly memory overhead caused by 64 bit integers and
pointers?
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: Maybe it was mostly memory overhead caused by 64 bit integers and
: pointers?
I have to take that back.
I just tested it again, and with a small test scene the 64-bit compile was
about 7% faster than the gcc compile. Perhaps I just did just something wrong
the first time.
On the other hand, the binary is almost twice as large... :)
Btw, the 'int' type is still 32-bit. It's the 'long' type which becomes
64-bit. (And of course pointers are 64-bit.)
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> I have to take that back.
> I just tested it again, and with a small test scene the 64-bit compile was
> about 7% faster than the gcc compile. Perhaps I just did just something wrong
> the first time.
> On the other hand, the binary is almost twice as large... :)
>
> Btw, the 'int' type is still 32-bit. It's the 'long' type which becomes
> 64-bit. (And of course pointers are 64-bit.)
I have to agree with your findings. I have not seen my builds of POV-Ray run
any faster when I select the 64bit UltraSparc target and turn on a bunch of
optimizations. Perhaps the problem is with the application itself :)
Dennis
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 15 Apr 2001 19:22:32 -0400, Dennis Clarke wrote:
>optimizations. Perhaps the problem is with the application itself :)
Nah, couldn't be.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that 64 bits means that you can do more, not that you can do it
faster.
(Well, of course unless the program is specifically optimized to be very
fast in 64-bit systems...)
Of course optimizing directly for the target platform should make faster
code than optimizing for an older one. However, AFAIK sparcs are designed
so that even old code run almost at maximum speed in newer cpu's. I also
think that gcc optimizes better than Sun's cc, which can also explain why
the gcc 32-bit compile matches so well the cc 64-bit compile.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
