Prev: application crash on DispatchMessage !
Next: loading dll (lame encoder)
From: Richard Russell on 31 Dec 2009 04:56
On Dec 31, 1:11 am, Rayne <lancer6...(a)yahoo.com> wrote:
> 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.

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.

From: Auric__ on 31 Dec 2009 09:50
On Thu, 31 Dec 2009 01:11:34 GMT, Rayne wrote:

> 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.
From: Ulrich Eckhardt on 4 Jan 2010 03:07
Rayne wrote:
> 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

From: Rayne on 4 Jan 2010 03:55
I included some timing statements, and I believe the 2 memcpy
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.
From: David Schwartz on 4 Jan 2010 09:27
On Jan 4, 12:55 am, Rayne <lancer6...(a)yahoo.com> wrote:
> I included some timing statements, and I believe the 2 memcpy
> 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.

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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: application crash on DispatchMessage !
Next: loading dll (lame encoder)