[Bf-committers] To John Walton..

[John K. Walton]

On Wed, 17 Dec 2003, Kiernan Holland wrote:

> 
> >> 
> >> It might require that code that is specific to Irix be seperated out
> >> and made as a linkable library, and then to have special calls to that
> >> specific code from within the GCC compiled portions.. Any build that
> >> prefers a proprietary build over a non-proprietary one will have lots
> >> of problems across the board..
> > 
> >the point is to avoid code that locks you into gcc compiler,
> >since gcc code does not perform as well as mipspro. having a build 
> >system that has problems across the board also includes non-proprietary 
> >ones too. 
> > 
> >it's perfectly reasonable to have code that compiles on all platforms.
> >it's why we got to where we are today.
> >
> 
> So you are asking "Is it possible to abstract the source from being 
> specific to any compiler and still be fair to compile with GCC and
> mipspro?" 

no, i had no questions. but, thanks for asking!

> >> If you want to compile blender to be able to run on a multi-processor
> >> cluster of some sort that would probably call for a different beast,
> >> blender broken up into modules that talk to each other, for instance.
> > 
> >run.. yeah. compile. nah. 
> 
> That's a little vague.. What do you mean?

i meant: i only cared about an MP build, so it would go faster.
currently that would be on a 4 way cc-numa Origin 200. although,
uniprocessor compilation is acceptable since i'm just delivering
binaries. if i had to do development, i would like to play the
lazy test-edit-compile cycle like anyone else.

i don't care about blender executable running on an MP, in other
than the individual processes we have today for 2.x series blenders.
if there is a ground up development, i would definiately architect
it to scale from SMP to clusters.
 
> >from what i've seen it's always simple code issues that the irix compiler
> >is more stringent in reporting. and since you don't have an sgi compiler
> >you don't have any thing base your assertion on anyway.
> 
> Okay.. I don't but neither do many others.. 

and that's ok, we rev the binary much more frequently than in NaN
days.

> I was under the assumption that it was a problem with the SGI compiler and 
> not the GCC.. Evidently its about the specificness of the code to work with
> GCC ??

look at it more pragmatically:
1) the NaN Makefiles only work with mipspro
2) the auto* build system only worked with GCC
3) the auto* build system is broken. in fact, it's multiply broken
   since nobody supports it new fatal errors popup everytime i try it.
4) if, and when, binaries are generated with GCC (3.0.4) they prove
   to be slower in rendering benchmarks than mipspro.
5) there are two people that support irix, chris want and I. we both
   work full time, and are at the limit of what we are capable of
   providing support for.

given the above, a clear engineering choice when a project that is
expected to deliver product quickly, on time, and with limited resources
would be to favor any development options that reflect 1) above.

> >in anycase, this POINT is to be able to use sgi's CASE tools to find
> >performance problems in the code that benefits eveyont not carve
> >out a SGI only hole to. If I wanted to do that i could just fork it.
> 
> That's reasonable.. 

and not improbable.

> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>