From: "Tom ST Denis" Newsgroups: comp.os.msdos.djgpp References: <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: 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" wrote in message news:92mb9j$soc$1 AT slb6 DOT atl DOT mindspring DOT net... > > "Tom ST Denis" 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