Difference in speed between Linux GCC and VS .NET 2003
Rayne
I have written a program in Linux and compiled it on GCC. The program
took about one second to run. Then I converted the same program into
something that can run on Windows (Vista) and compiled it using Visual
Studio .NET 2003. However, this program now takes about 9 - 10 seconds
to run (in both debug and release mode).
The program does the following:
It uses the pcap library (WinPcap WpdPack 4.0.2 for Windows) to first
set up a filter using IP addresses. Then going through a folder, it
reads every pcap file in it and runs pcap_loop on each pcap file. The
callback function for pcap_loop checks for certain criteria and writes
the contents to files.
The changes I've made to convert the program from Linux to Windows is:
1) Using FindFirstFile and FindNextFile instead of struct dirent
2) I had to define structures for IP, TCP and UDP myself for the
Windows program, since I can't find netinet/ip.h, netinet/tcp.h and
netinet/udp.h on Windows
3) Using CreateFile and WriteFile instead of fwrite (fwrite was giving
me problems with the output)
Other than that, the program is pretty much kept the same.
I thought the file I/O could be the cause of the difference in speed,
but after commenting out every WriteFile, the Windows program is still
slower. Could using WinPcap in Windows be the cause?
Thank you.
Regards,
Rayne
David Schwartz
> I thought the file I/O could be the cause of the difference in speed,
> but after commenting out every WriteFile, the Windows program is still
> slower. Could using WinPcap in Windows be the cause?
There are a few ways to track this kind of thing down, but my favorite
way to do it is to note the time on program startup and have a
function that writes an entry to a log file along with the time since
program startup and the time since the last log entry. Then add lines
of code to the program to log when key events happened (when you open
a file, when you finish processing something, and so on).
From those logs, you should be able to tell what each program was
doing for the time it was running. Once you know what the Windows
program is doing for those 8 seconds, the answer should be pretty
clear.
It will likely be something silly, like the Windows program doing lots
of DNS or something.
DS
Richard Russell
> I have written a program in Linux and compiled it on GCC. The program
> took about one second to run. Then I converted the same program into
> something that can run on Windows (Vista) and compiled it using Visual
> Studio .NET 2003. However, this program now takes about 9 - 10 seconds
> to run (in both debug and release mode).
GCC runs fine on Windows (e.g. using mingw or cygwin) so if you're
happy with the performance from GCC, why recompile using Visual
Studio?
http://www.mingw.org/
http://www.cygwin.com/
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Auric__
> I have written a program in Linux and compiled it on GCC. The program
> took about one second to run. Then I converted the same program into
> something that can run on Windows (Vista) and compiled it using Visual
> Studio .NET 2003. However, this program now takes about 9 - 10 seconds
> to run (in both debug and release mode).
[snip]
> I thought the file I/O could be the cause of the difference in speed,
> but after commenting out every WriteFile, the Windows program is still
> slower. Could using WinPcap in Windows be the cause?
It might be because GCC compiles to machine code, while VS.Net compiles to
bytecode that must then be interpreted.
--
Tinsel is really snakes' mirrors.
-- Steven Wright
Rayne
David - I will try that later.
Richard - I was under the impression that cygwin is similar to VMware,
in that Linux and Windows occupy 2 separate memory space, and
communication between programs would be quite inconvenient. Would a
native Windows program be able to easily access the files written (to
a folder) by the Linux program?
Auric - The other portions of the entire program run at the same
speed, this is the only part that runs slower in Windows.
Richard Russell
> Richard - I was under the impression that cygwin is similar to VMware,
> in that Linux and Windows occupy 2 separate memory space, and
> communication between programs would be quite inconvenient. Would a
> native Windows program be able to easily access the files written (to
> a folder) by the Linux program?
I've never used cygwin myself, but I don't think that's right. AIUI
cygwin simply uses a custom DLL to provide some Linux-like services to
a Windows program; it's not in any sense 'running' Linux.
My preferred Windows development platform is mingw, which is simply
GCC with a set of libraries appropriate to Windows; it generates
native Windows executables like any other. The only significant
limitation I've encountered is that you can't link with Microsoft C++
libraries, because they use a proprietary format, but if you're
programming in plain C that won't be an issue.
I'm not suggesting it's likely that switching to cygwin or mingw will
solve your speed issue, because it probably results from something
other than the compiler, but if you want to support your application
on both Linux and Windows it seems to me you're making your life
unnecessarily complex by not using the same compiler (GCC) for both.
Check out the web links I gave before. I'm pretty sure that cygwin or
mingw would be suitable for your application.
Auric__
> I was under the impression that cygwin is similar to VMware,
> in that Linux and Windows occupy 2 separate memory space, and
> communication between programs would be quite inconvenient. Would a
> native Windows program be able to easily access the files written (to
> a folder) by the Linux program?
Cygwin and VMware have no similarities whatsoever. Cygwin is essentially a
POSIX layer (mostly provided by cygwin1.dll), while VMware is an x86
emulator. Some reading:
http://en.wikipedia.org/wiki/Cygwin
http://en.wikipedia.org/wiki/VMware
http://en.wikipedia.org/wiki/Compatibility_layer
> Auric - The other portions of the entire program run at the same
> speed, this is the only part that runs slower in Windows.
[shrug] Okay. It was just a thought.
--
A broken spirit is what you gained.
Ulrich Eckhardt
> I have written a program in Linux and compiled it on GCC. The program
> took about one second to run. Then I converted the same program into
> something that can run on Windows (Vista) and compiled it using Visual
> Studio .NET 2003. However, this program now takes about 9 - 10 seconds
> to run (in both debug and release mode).
So it seems like it's not in the program, otherwise the debug/release should
make a difference.
> The changes I've made to convert the program from Linux to Windows is:
[...]
> 2) I had to define structures for IP, TCP and UDP myself for the
> Windows program, since I can't find netinet/ip.h, netinet/tcp.h and
> netinet/udp.h on Windows
#include <winsock2.h>
This unfortunately must come before <windows.h>, which in turn is included
by things like <stdio.h>.
> 3) Using CreateFile and WriteFile instead of fwrite (fwrite was giving
> me problems with the output)
"problems with the output" is pretty vague. Chances are that your code is
simply not written in a portable way. A good starter here would be to use
the "binary" flag when opening the file, it makes a difference on any
DOS-derived/influenced OS, but not on POSIX systems.
> I thought the file I/O could be the cause of the difference in speed,
> but after commenting out every WriteFile, the Windows program is still
> slower. Could using WinPcap in Windows be the cause?
Yes, it could be the cause.
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Rayne
statements I have in my code is the cause. Moving these memcpy
statements to only where they are needed shaved about 6 seconds off
the runtime. The Windows version is still slower than the Linux
version, but at least the difference isn't as great.
I'm curious to know why there is this difference in the 2 platforms/
compilers when using memcpy.
David Schwartz
One possibility is that the 'memcpy's are getting called differently
or different numbers of times on the two different platforms. There
may, for example, be structures you are copying that are larger on one
platform.
Anther is that the two platforms have different 'memcpy'
optimizations. One may be optimized for larger copies and the other
for smaller, or one may be optimized for aligned copies and the other
not so much.
It can also be a weird interaction. For example, header files on one
platform may make the size of the data copied known at compile time.
But on the other platform, the header files make the size copied not
known until run time.
DS
Michael Wojcik
> Rayne wrote:
>
>> 2) I had to define structures for IP, TCP and UDP myself for the
>> Windows program, since I can't find netinet/ip.h, netinet/tcp.h and
>> netinet/udp.h on Windows
>
> #include <winsock2.h>
winsock2.h has definitions for the IP, TCP, and UDP headers? I didn't
see them in a quick scan through that file, or those it includes.
> This unfortunately must come before <windows.h>, which in turn is included
> by things like <stdio.h>.
The problem is that windows.h, by default, includes winsock.h, which
conflicts with winsock2.h.
You can also define _WINSOCKAPI_ before including windows.h, to
suppress the contents of winsock.h - that's what winsock2.h does,
since of course it too includes windows.h (as do nearly all MS headers).
Or define WIN32_LEAN_AND_MEAN before including windows.h, if you don't
need any of the other things WIN32_LEAN_AND_MEAN suppresses:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <winsock2.h>
WIN32_LEAN_AND_MEAN prevents windows.h from including the following:
cderr.h
commdlg.h
dde.h
ddeml.h
dlgs.h
lzexpand.h
mmsystem.h
nb30.h
ole.h
ole2.h
rpc.h
shellapi.h
wincrypt.h
winefs.h
winperf.h
winscard.h
winsock.h
winspool.h
It significantly reduces how much namespace windows.h stomps on, as
well as letting you include winsock2.h unmolested.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Ulrich Eckhardt
> Ulrich Eckhardt wrote:
>> Rayne wrote:
>>
>>> 2) I had to define structures for IP, TCP and UDP myself for the
>>> Windows program, since I can't find netinet/ip.h, netinet/tcp.h and
>>> netinet/udp.h on Windows
>>
>> #include <winsock2.h>
>
> winsock2.h has definitions for the IP, TCP, and UDP headers?
Yes, it has definitions required to use TCP and UDP and some other
protocols. I don't know if it defines structures that define the respective
protocol's packet headers. It's not clear what exactly is needed.
;)