Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FPC for DOS / FreeDOS (DOSX)

posted by Rugxulo Homepage, Usono, 14.04.2008, 20:40

> Take e.g. delphi or other wirthian languages, and you'll see it otherwise.
> Slow compiling is a notorious C/C++ problem, not a HLL problem. It
> originates in the constant reinterpretation of headers
It seems that OpenWatcom is faster to compile than GCC. And its output gets about 85% of GCC's speed. But yeah, I do wonder why no C compiler ever bundles all the .H files into one big database (since they aren't updated often).

> It is more from when I was young and had some BBS software in assembler
> long ago
If people still used 486s or non-superscalar architectures (e.g. VIA ?), they'd probably all be assembly programmers. But since clock speed (and cpu improvements) have all gotten better, it's less of an issue ... in most cases. Still, I wonder who is completely satisfied with 100% of their programs and thinks they don't need to be any faster. (Any compiler/compressor could be ideally faster.)

> And in general, if projects get larger, you simply want to catch every bug
> where and when you can, _before_ you have to compile with debug info.
Uh, I wouldn't call C++ the easiest thing to debug (but to be fair, I don't know or use it).

> So you don't use any software written by others on your 486?
99% of the software I (rarely) use on my 486 is written by someone else. I'm not one of the geniuses that writes their own OS and all the apps (although they do exist). Just trust me, in case you've forgotten, a 486 is slow! Therefore, you are bound to say, "Man, this is annoying, couldn't it be faster?" Even using a P166 is much much less annoying (approx. 10x faster). Heck, even using my P4 w/ XP makes me irritated sometimes.

> Well, maybe if you invested the same amount of time in the HLL code as in
> your handtuned assembler, than it would.

No. The compiler is inherently limited, pure assembly is not. It doesn't mean you can't optimize at the HLL level (search Google for C optimizations), but their generic optimizations don't always pan out.

> The point is not the assembler,
> but the invested time to speed it up. Most engineers don't want to invest
> those magnitudes of time for something that is old hat in two years.

The problem here is that you're assuming everyone has newest, latest Core 2 "Penryn" processors with quad cores, etc. Sure, those are very fast (supposedly, never tried myself). But 95% of the world doesn't use those yet. So you can code blissfully ignorant of the whole world or you can spend time working towards that which is slower but still functional.

BTW, assembly doesn't usually get slower with newer processor upgrades. Sure, the advantage can disappear (see HA C-- rewrite), but the person writing it had a tangible reason to: his own personal computer. If you don't have a 486, you won't write for one. It's personal when you do, though, because you want it to run faster.

> If you finish such project for larger pieces of software, you can start
> rewriting it for newer processors before it is finished.
Sure, if you have infinite amounts of money and are willing to upgrade your cpu. Most people don't do that, however.

> I do agree they could speed up some very much used primitives (and
> compression is certainly one of them) on x86, and keep the C code for the
> rest (and afaik most compression already contains asm)
Only the best compressors have asm speedups. The rest just wimp out and say, "Good enough" (and that's probably fair in some cases). But just FYI, there are reasons why Zip/Gzip (Deflate) and BZip2 (BWT) are still popular despite much better compression available: low memory footprint and fast.

> > And in case you haven't noticed my previous posts, 7ZA + HX is
> > much faster than p7zip (DJGPP).
>
> And that proves exactly WHAT? THat you and japeth put in more time for
> some optimizing?

p7zip is pure C/C++ (last I checked) while HX is definitely not. (And I had no involvement in writing any code for that.) You cannot expect pure HLL to always be faster than all pure assembly. In fact, it IS assembly (once translated).

> FASM or Octasm (both written in themselves) are faster than YASM (C)
> which is faster than NASM (C).
>
> That only proves that you care more about speed than the YASM and NASM
> authors. Not that asm is superior
The YASM and NASM I use are DOS/DJGPP compiles, and DJGPP is not the best optimizing compiler (although fairly good). So that makes a difference too.

"Bare" Assembly (language) is of course superior because without it you can't run anything! Even HLL all becomes assembly eventually. It doesn't mean you should write everything in pure assembly. A skilled coder who knows what he/she is doing can outmatch a braindead compiler any day. But HLLs have advantages too, just not 100% of the time (which I hope you aren't advocating).

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22755 Postings in 2121 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum