469,626 Members | 1,025 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,626 developers. It's quick & easy.

C program verrrry slow on Win98 DOS shell

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.
Nov 13 '05 #1
11 2691
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?


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

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown
Nov 13 '05 #2
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?

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?

--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41

Nov 13 '05 #3
In comp.lang.c Brett <ca******@yahoo.com> 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?


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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #4
ca******@yahoo.com (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.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
You hate people.
But I love gatherings. Isn't it ironic.
Nov 13 '05 #5
On Tue, 21 Oct 2003 16:06:34 UTC, ca******@yahoo.com (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?


As you sayd: DOS

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch wird jetzt ausgeliefert!
Nov 13 '05 #6
Brett wrote:

<snip>
where is my bottleneck on DOS?


Redmond, Washington USA

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

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

Nov 13 '05 #7
Michel Bardiaux <mb*******@peaktime.be> wrote in message news:<3F**************@peaktime.be>...
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?

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?


I'm using long int's and plain pointers.
Nov 13 '05 #8
"Brett" <ca******@yahoo.com> wrote in message
news:93************************@posting.google.com ...
Michel Bardiaux <mb*******@peaktime.be> wrote in message

news:<3F**************@peaktime.be>...

[...]
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

Nov 13 '05 #9
ca******@yahoo.com (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?
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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 13 '05 #10

On 2003-10-21 ca******@yahoo.com (Brett) said:
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.

Nov 13 '05 #11
Morris Dovey <mr*****@iedu.com> wrote in message news:<RW******************@news.uswest.net>...
Brett wrote:

<snip>
where is my bottleneck on DOS?


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.
Nov 13 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by zalekbloom | last post: by
2 posts views Thread by GSpiggle | last post: by
4 posts views Thread by JakeP | last post: by
10 posts views Thread by Jos Vernon | last post: by
8 posts views Thread by Paul Bromley | last post: by
reply views Thread by G Gerard | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.