From:	"Tom ST Denis" <tstdenis3160 AT home DOT com>
Newsgroups:	comp.os.msdos.djgpp
References:	<f_v36.53630$59 DOT 14770834 AT news3 DOT rdc1 DOT on DOT home DOT com> <92mb9j$soc$1 AT slb6 DOT atl DOT mindspring DOT net>
Subject:	Re: Support for higher end cpus
Lines:	106
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID:	<nuy36.54098$59.15020373@news3.rdc1.on.home.com>
Date:	Sun, 31 Dec 2000 04:20:35 GMT
NNTP-Posting-Host:	24.156.37.224
X-Complaints-To:	abuse AT home DOT net
X-Trace:	news3.rdc1.on.home.com 978236435 24.156.37.224 (Sat, 30 Dec 2000 20:20:35 PST)
NNTP-Posting-Date:	Sat, 30 Dec 2000 20:20:35 PST
Organization:	Excite AT Home - The Leader in Broadband http://home.com/faster
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Marp" <marp AT 0 DOT 0 DOT 0 DOT 0> wrote in message
news:92mb9j$soc$1 AT slb6 DOT atl DOT mindspring DOT net...
>
> "Tom ST Denis" <tstdenis3160 AT home DOT com> wrote in message
> news:f_v36.53630$59 DOT 14770834 AT news3 DOT rdc1 DOT on DOT home DOT com...
> > I know (from my earlier post) that DJGPP can understand switches such
> > as -march=k6 or -march=i686 but the code it produces doesn't seem to be
> any
> > faster (substantially anyways) then -march=i486.  The output code *is*
> > different just not improved.
> >
> > My basis for this judgement is my compilation of Allegro and my updated
> > Plush lib.  I get about the same FPS in my Plush examples when I use
> > march=k6 (on my Athlon) then I do with march=i486.
> >
>
> The compiler definitely has its limits as to how much it can optimize a
> program. It can only go so far because it has to produce code that's
> logically equivalent to the code that you feed it. I think you will find
> that gcc produces code that's as good as any code made by a proprietary
> compiler. You should try to write code that is as efficient as possible to
> get the best results.

I know that.  But the optimizations the authors must have been thinking of
when they did DJGPP for the i486 are not always what you want for an i686 or
k6.  My point is that newer opts may have been missed.

The code I am using is fairly efficient.  There are no obvious algorithmic
flaws (I haven't looked that deeply at plush3d but it's fairly well written)
and the biggest speed hit is the code required to render surfaces.

> You can improve the performance of allegro programs that use graphics by
> getting a vbe/af driver for your video card. See the allegro web site for
> details about freebe ( http://www.talula.demon.co.uk/ ).

I know of freebe (you're almost patranizing me here...) and the RAGE 128
chipset has no specific drivers.  I have contacted ATI for the specs cuz I
want to try and make a copy.

> > Will there be any development for supporting the K7/PIII/PIV?  It would
> make
> > DJGPP (and it's GCC derivatives such as CYGWIN) jump way ahead of VC++
> 6.0.
> > If GCC supported these new cpus I bet alot of people would be happy!  I
> know
> > I would.
> >
>
> Specific support for these newer cpus may develop eventually, but these
> things take time. It can develop faster if more people with the necessary
> skills make contributions (and people who don't have the skills themselves
> can pay someone who does if it's that important to them). You must also
keep
> in mind that the compiler can only do so much to optimize your code, so
> don't expect any miracles if and when such support arrives. The easiest
> solution is to buy faster hardware ;-)
>
> BTW cygwin is not a derivative of djgpp. GCC was developed by the GNU
> project to go with the operating system they are making. Since the sources
> to these things are freely available, many people thought it would be
useful
> to port these programs to other systems. DJGPP happens to be a dos port of
> gcc, and cygwin happens to be a windows port of gcc. Cygwin is not a port
of
> DJGPP to windows.

I know the relationship.  I am just saying if they worked on GCC then both
will benefit.  Perhaps I was a bit fuzzy on the order of things... oops.

> > For the most part I think just the way the code is rescheduled is the
only
> > thing the compiler *could* do.  But often that makes a big difference.
> > Other things such as MMX/3dNOW instructions could be provided by a
> libext.a
> > or something that is optional for a DJGPP installation.
> >
>
> You can write a library that makes use of such instructions when it's
> functions are used by a program. If you are suggesting something that
would
> provide support for those instructions in some manner that's mostly
> invisible, I'm not sure how something like that could be done, but it's
> certainly not a bad idea. Maybe someone who knows more can comment on
> this...

Things like memcpy and memcmp can be optimized in MMX... asm optimized
qsort's would be decent for 3d code too.

> > I have no clue about compiler development or serious optimization
tricks.
> I
> > just use the compiler and write what I think is efficient algorithms...
so
> I
> > can't help develop this...wish I could..
>
> Doing the best you can is all you can be expected to do :-)

Well I try.  I release my code for free to hopefully help others.  The plush
library I am working on is really cool specially since it's limited to 256
colors!

Tom

- Raw text -