C program verrrry slow on Win98 DOS shell

[Brett]

Hi. I wrote a program in C that spends most of its time doing integer
arithmetic (on a data set loaded at run time), with a negligible
amount of I/O. I compiled it with lcc-win32 as a console application.
The program took 10 hrs to crunch a particular batch of data. I also
compiled with Open Watcom 1.1 with similar results. However, I
compiled the program on Linux (I have a dual boot system) with gcc,
and it took 12 MINUTES to crunch the same data. Can someone answer:
where is my bottleneck on DOS?

I'm running the console as a DOS shell under Windows 98 on an Athlon
XP 1900+ with 512 MB ram. I'm only using the standard C libraries. My
config.sys file is empty. My Autoexec.bat file only contains PATH
information. Do I need to add lines for emm386, himem, and all that
rot? Or is it something else entirely? Please advise. Thanks.

 

[David Rubin]

Hi. I wrote a program in C that spends most of its time doing integer
arithmetic (on a data set loaded at run time), with a negligible
amount of I/O. I compiled it with lcc-win32 as a console application.
The program took 10 hrs to crunch a particular batch of data. I also
compiled with Open Watcom 1.1 with similar results. However, I
compiled the program on Linux (I have a dual boot system) with gcc,
and it took 12 MINUTES to crunch the same data. Can someone answer:
where is my bottleneck on DOS?

All your data is sent to a Microsoft server for storage and analysis

/david

 

[Michel Bardiaux]

Hi. I wrote a program in C that spends most of its time doing integer
arithmetic (on a data set loaded at run time), with a negligible
amount of I/O. I compiled it with lcc-win32 as a console application.
The program took 10 hrs to crunch a particular batch of data. I also
compiled with Open Watcom 1.1 with similar results. However, I
compiled the program on Linux (I have a dual boot system) with gcc,
and it took 12 MINUTES to crunch the same data. Can someone answer:
where is my bottleneck on DOS?

I'm running the console as a DOS shell under Windows 98 on an Athlon
XP 1900+ with 512 MB ram. I'm only using the standard C libraries. My
config.sys file is empty. My Autoexec.bat file only contains PATH
information. Do I need to add lines for emm386, himem, and all that
rot? Or is it something else entirely? Please advise. Thanks.

Do you use int, short or long? Plain, near, far, huge pointers?

 

[Christopher Benson-Manica]

Hi. I wrote a program in C that spends most of its time doing integer
arithmetic (on a data set loaded at run time), with a negligible
amount of I/O. I compiled it with lcc-win32 as a console application.
The program took 10 hrs to crunch a particular batch of data. I also
compiled with Open Watcom 1.1 with similar results. However, I
compiled the program on Linux (I have a dual boot system) with gcc,
and it took 12 MINUTES to crunch the same data. Can someone answer:
where is my bottleneck on DOS?

There's an interesting thread regarding optimization issues on
comp.lang.c++.moderated ("Huge C++ Optimization Hole") that might possibly be
relevant...

 

[Derk Gwen]

(e-mail address removed) (Brett) wrote:
# Hi. I wrote a program in C that spends most of its time doing integer
# arithmetic (on a data set loaded at run time), with a negligible
# amount of I/O. I compiled it with lcc-win32 as a console application.
# The program took 10 hrs to crunch a particular batch of data. I also
# compiled with Open Watcom 1.1 with similar results. However, I
# compiled the program on Linux (I have a dual boot system) with gcc,
# and it took 12 MINUTES to crunch the same data. Can someone answer:
# where is my bottleneck on DOS?

If the data is too large too fit in real memory, I would expect the
difference is in virtual memory implementations. One OS is thrashing on
your code, the other isn't. There's not too much you can do in a system
independent way to avoid thrashing: maintain locality of reference as
much as possible.

 

[The Real OS/2 Guy]

Hi. I wrote a program in C that spends most of its time doing integer
arithmetic (on a data set loaded at run time), with a negligible
amount of I/O. I compiled it with lcc-win32 as a console application.
The program took 10 hrs to crunch a particular batch of data. I also
compiled with Open Watcom 1.1 with similar results. However, I
compiled the program on Linux (I have a dual boot system) with gcc,
and it took 12 MINUTES to crunch the same data. Can someone answer:
where is my bottleneck on DOS?

As you sayd: DOS

 

[Morris Dovey]

Brett wrote:

where is my bottleneck on DOS?

Redmond, Washington USA

If it runs better under Linux, then why not just run it under Linux?

 

[Brett]

Do you use int, short or long? Plain, near, far, huge pointers?

I'm using long int's and plain pointers.

 

[Jason Burgon]

[...]

Do you use int, short or long? Plain, near, far, huge pointers?

I'm using long int's and plain pointers.

Then, and assuming you compiled a (16-bit) DOS application, this is probably
where a lot of the difference lies. Your compiler is likely to produce much
slower 32-bit integer code for a 16-bit platform, and if your data pointers
are 'far', then pointer loads will be several times slower than your 32-bit
equivalent application.

Though I have to say that because you report such a huge speed difference,
that the DOS version is somehow I/O-bound (windows swap file?).

--
Jay

Jason Burgon. Author of Graphic Vision
Version 2.21 available from:
http://homepage.ntlworld.com/gvision

 

[Paul Hsieh]

Hi. I wrote a program in C that spends most of its time doing integer
arithmetic (on a data set loaded at run time), with a negligible
amount of I/O. I compiled it with lcc-win32 as a console application.
The program took 10 hrs to crunch a particular batch of data. I also
compiled with Open Watcom 1.1 with similar results. However, I
compiled the program on Linux (I have a dual boot system) with gcc,
and it took 12 MINUTES to crunch the same data. Can someone answer:
where is my bottleneck on DOS?

Were you using lcc or Open Watcom for Linux? (I was under the
impression that OW was not yet working under Linux, though they are
trying to get it to work.)

Look. These days, gcc is *FAR* superior to either lcc or Watcom
C/C++. Lcc and Watcom C/C++ just clearly doesn't have anywhere near
the amount of work going into it that gcc has had in the last few
years. There are basically only 3 compilers left on the x86
environment where active development especially related to performance
is happening: MSVC++, GCC and Intel C/C++. Anything else is just a
joke (well maybe the Portland Group compilers, but there is very
little hard data on what they have been up to ...)

I'm running the console as a DOS shell under Windows 98 on an Athlon
XP 1900+ with 512 MB ram. I'm only using the standard C libraries.

Probably the saddest part of all of this is that Watcom's libraries
are just a joke. If you saw the same performance with lcc, then
there's a good chance that lcc's standard libraries are also a joke.

[...] My config.sys file is empty. My Autoexec.bat file only contains PATH
information. Do I need to add lines for emm386, himem, and all that
rot? Or is it something else entirely? Please advise. Thanks.

The old WATCOM C/C++ comes with an execution profiler (I don't know if
Open Watcom comes with it, I haven't been able to build it.) You can
use it to isolate where the performance bottleneck is. This, combined
with their excellent inline assembly mechanism, is the one saving
grace of WATCOM C/C++. So performance is still in your hands -- you
just can't rely on the compiler itself to deliver it for you.

 

[DOS Guy]

> Hi. I wrote a program in C that spends most of its time doing
> integer arithmetic (on a data set loaded at run time), with a
> negligible amount of I/O. I compiled it with lcc-win32 as a console
> application. The program took 10 hrs to crunch a particular batch
> of data. I also compiled with Open Watcom 1.1 with similar results.
> However, I compiled the program on Linux (I have a dual boot
> system) with gcc, and it took 12 MINUTES to crunch the same data.
> Can someone answer: where is my bottleneck on DOS?
> I'm running the console as a DOS shell under Windows 98 on an Athlon
> XP 1900+ with 512 MB ram. I'm only using the standard C libraries.
> My config.sys file is empty. My Autoexec.bat file only contains PATH
> information. Do I need to add lines for emm386, himem, and all that
> rot? Or is it something else entirely? Please advise. Thanks.

If your program is a "console application" (which it must be, if
you compiled it with lcc-win32), it's -NOT- "DOS."

Sorry to have to break the news to you, son, but you've written
a WinDoze program.

Even if you invoke it from the pseudo-"DOS prompt" in WinDoze 98,
it still ain't a "DOS" program. It requires the WinDoze kernel
to be present. That's not "DOS."

Oh, sure, your program's text-mode interface LOOKS somewhat like
"DOS." Console applications do. But it -ain't- "DOS."

A "console application" is a WinDoze program. Period. End of
story.

That being the case, then the answer to your question is YES --
you -DO- need to "add lines for emm386, himem, and all that rot."

Get your machine configured properly for WinDoze, and your slow-
ness problem will mostly go away.

And remember: "console application" == "WinDoze program."
Not "DOS."

Future questions about such things should be directed to a
WinDoze programming newsgroup.

 

[Brett]

Brett wrote:



Redmond, Washington USA

If it runs better under Linux, then why not just run it under Linux?

Because I'm developing for several target platforms.