[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] gnubg on mac os x
From: |
Jim Segrave |
Subject: |
Re: [Bug-gnubg] gnubg on mac os x |
Date: |
Fri, 24 Jan 2003 19:02:13 +0100 |
User-agent: |
Mutt/1.4i |
On Fri 24 Jan 2003 (18:00 +0100), Olivier Baur wrote:
> Hello.
>
> I'm wondering if porting gnubg to Mac OS X is currently planned or in
> progress ?
>
> If not, I'm willing to do this.
I hope my comments below don't sound too negative, consider it as a
devil's advocate sort of reply.
> I've already been able to build it (from yesterday's CVS snapshot) and
> run it in an X windowing system (works either with "XDarwin" or Apple's
> newly released "X11" X servers). Maybe I could consider release a "full
> binary download" (pre-built) version for Mac OS X users?
>
> I'm also willing to :
> - throw in multiprocessor support [as soon as I can put my hands on a
> bi-proc G4 :-) ]
I've got a bad feeling that there won't be much of a gain there - it's
not a threaded application.
> - port it to a full Aqua version (ie, use Apple's GUI instead of
> X+GTK/Guile's)
The trouble with that is that you'd have to keep updating the porting
as features are added/changed. Unless there's some simple automation
possible or you provide a GTK->Aqua API
> - add vector-computing for use with G4 processors' built-in superscalar
> unit (known as "Velocity Engine" or "AltiVec") -- I have noticed that
> during rollouts/evaluations, the CPU would spend 70% of its time
> evaluating the neural net, which can be basically thought as a matrix
> product between the different layers, which in turn is a perfect
> candidate algorithm for vectorization and dramatic performance
> improvement
Interesting idea - I wonder how much that might help for those who
have vector hardware.
> Please keep me informed if any of these projects are already being
> worked on, so I don't start working on something that's on the verge of
> being completed.
Certainly within a GTK environment, any feedback on porting problems
would be very useful, as the desire is to keep the code as platform
independant (or adaptable) as possible.
--
Jim Segrave address@hidden