Hello Hans,
--- Hans Leidekker hans@it.vu.nl wrote:
This makes wininet build on MinGW.
Changelog: Move to Windows sockets.
I asked Alexandre about a patch to move Wininet to Winsock and he said it took to much of a performance hit to merge. Is there a way we can bench mark it to show how much of a hit Winsock vs Unix sockets is going to give us? He suggested that we find a way to make Wininet use Unix sockets on Unix and Winsock on Windows.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
How about this.
Use #ifdef stuff so that when building on WINE, it uses unix sockets. But when building on win32 (which would include MingW and ReactOS), it uses winsock.
On April 4, 2004 10:18 pm, Jonathan Wilson wrote:
Use #ifdef stuff so that when building on WINE, it uses unix sockets.
We have to be smart about this, having #ifdefs all over the file is not acceptable. But from the look of the patch that was just posted, it certainly looks like we can achieve this without too much pain. But yes, I'm also curious how much of a hit we're taking.
On Monday 05 April 2004 05:21, Dimitrie O. Paun wrote:
Use #ifdef stuff so that when building on WINE, it uses unix sockets.
We have to be smart about this, having #ifdefs all over the file is not acceptable. But from the look of the patch that was just posted, it certainly looks like we can achieve this without too much pain. But yes, I'm also curious how much of a hit we're taking.
Here are some timings for a loop of 100 synchronous HTTP GETs from localhost on a 777 bytes file:
Unix sockets
real 0m4.099s | real 0m4.137s | real 0m4.092s | real 0m4.104s user 0m0.480s | user 0m0.503s | user 0m0.514s | user 0m0.533s sys 0m0.312s | sys 0m0.283s | sys 0m0.280s | sys 0m0.303s
Windows sockets
real 0m4.172s | real 0m4.255s | real 0m4.219s | real 0m4.867s user 0m0.888s | user 0m0.858s | user 0m0.807s | user 0m0.936s sys 0m0.910s | sys 0m0.820s | sys 0m0.839s | sys 0m0.988s
So yes, there is a performance hit. Especially the 'user' and 'sys' measurements are respectively nearly 2 and 3 times higher than with Unix sockets.
So, is this a problem? Depends on what's important to you, but I'd argue that it's more important for Wine to open up wininet (and consequently winsock) to more users and developers. That may eventually attract more developers to fix bugs or even the performance issues with our implementation.
I would also argue that performance in a typical scenario is probably not bounded by wininet's implementation but by the user's bandwidth or, for example, by his browser's rendering speed.
By the way, 100 *asynchronous* HTTP GETs in a tight loop will reliably crash Wine, both with Unix sockets and Windows sockets.
-Hans
Hans Leidekker hans@it.vu.nl writes:
So, is this a problem? Depends on what's important to you, but I'd argue that it's more important for Wine to open up wininet (and consequently winsock) to more users and developers. That may eventually attract more developers to fix bugs or even the performance issues with our implementation.
There's no real reason that we cannot use Unix sockets on Unix and Windows socket on Reactos with the same code, it just needs a bit of header magic; and this will be useful for Winelib apps too.
By the way, 100 *asynchronous* HTTP GETs in a tight loop will reliably crash Wine, both with Unix sockets and Windows sockets.
Yep, wininet is not really thread-safe at this point.
On Monday 05 April 2004 19:24, Alexandre Julliard wrote:
There's no real reason that we cannot use Unix sockets on Unix and Windows socket on Reactos with the same code, it just needs a bit of header magic; and this will be useful for Winelib apps too.
Hmm, I'd like to agree with that.
Yep, wininet is not really thread-safe at this point.
But given Mike's suggestion of using Win32 synchronisation primitives to tackle this, how would we make the Unix socket case thread safe?
-Hans
Hi,
I hope that we use Han's patch. It's going to make it easier to implement thread safety (as we can use WaitForMultipleObjects on the handles) and will make porting easier for Reactos.
IMO, wininet is not really performance critical, and we can probably improve things in the winsock layer a bit too.
Mike
Hans Leidekker wrote:
So yes, there is a performance hit. Especially the 'user' and 'sys' measurements are respectively nearly 2 and 3 times higher than with Unix sockets.
So, is this a problem? Depends on what's important to you, but I'd argue that it's more important for Wine to open up wininet (and consequently winsock) to more users and developers. That may eventually attract more developers to fix bugs or even the performance issues with our implementation.
I would also argue that performance in a typical scenario is probably not bounded by wininet's implementation but by the user's bandwidth or, for example, by his browser's rendering speed.
By the way, 100 *asynchronous* HTTP GETs in a tight loop will reliably crash Wine, both with Unix sockets and Windows sockets.
-Hans
On April 5, 2004 1:57 pm, Mike McCormack wrote:
IMO, wininet is not really performance critical, and we can probably improve things in the winsock layer a bit too.
I second that. Moreover, it seems that it's not that much of a performance hit (as experienced by the user, 4.1s vs. 4.2s), but rather higher CPU utilization. And for Wine, we have a ton of places which are a lot more used which are more wasteful. Not to say that we should waste cycles left, right, and center, but it does seem that this patch is certainly within acceptable limits, and with some tweaks to winsock (which will help other things as well) it can probably be significantly improved.
-
Alexandre Julliard -
Dimitrie O. Paun -
Hans Leidekker -
Jonathan Wilson -
Mike McCormack -
Steven Edwards