Re: Performance problem with gcc 4.9.2-3 on 64 bit

Marco Atzeri wrote: >On 2/27/2015 5:49 PM, Bengt Larsson wrote: >> Below are two benchmarks that explore maximum floating point >> performance. loopm6 is double precision floating point and loopm6fp is >> parallell single-precision. They are manually unrolled multiply-add >> loops. >> >> I used to

Re: Performance problem with gcc 4.9.2-3 on 64 bit

On 2/27/2015 5:49 PM, Bengt Larsson wrote: Below are two benchmarks that explore maximum floating point performance. loopm6 is double precision floating point and loopm6fp is parallell single-precision. They are manually unrolled multiply-add loops. I used to reach 2.8 and 11 GFlops on these. No

Performance problem with gcc 4.9.2-3 on 64 bit

Below are two benchmarks that explore maximum floating point performance. loopm6 is double precision floating point and loopm6fp is parallell single-precision. They are manually unrolled multiply-add loops. I used to reach 2.8 and 11 GFlops on these. Now I only get 2 and 6. If you explore the inn

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

Hi All... From: Reini Urban To: [EMAIL PROTECTED] Subject: Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem]) Date: Mon, 22 Nov 2004 08:41:56 +0100 Karl M schrieb: Back on Octber 4-6, Corinna, Chris and Bob Byrnes were discussing temporarily reverting some of the pipe

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

REAIYR>. Thanks. > > Subject: Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance > > problem]) > > Date: Sun, 21 Nov 2004 20:05:56 -0500 > > > > Hi All, > > > > One temporary solution is to use the Cygwin version of unison, rather than > &

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

Hi Michael, You can take the sources of whatever unison version you want to match the unison on your server, and compile it in cygwin. You can also control the version of unison on your server by compiling unison in your home directory on the server, and using the '-servercmd' option of unison

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

This solution is problematic as the Unisons avail with Cygwin are beta versions 2.9.2 or 2.10.2 whereas the latest stable unison is 2.9.1. Normally this wouldn't be a problem except these versions will not run with a 2.9.1 version at the other end (Unison seems somewhat unique in that regard -

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

Karl M schrieb: Back on Octber 4-6, Corinna, Chris and Bob Byrnes were discussing temporarily reverting some of the pipe changes until a better solution is found so that native unison and other native programs would work with pipes (with ssh for example) on XP SP2. With the release of the 1.5.1

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

Karl M wrote: > Back on Octber 4-6, Corinna, Chris and Bob Byrnes were discussing > temporarily reverting some of the pipe changes until a better solution is > found so that native unison and other native programs would work with pipes > (with ssh for example) on XP SP2. > > With the release of t

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

synchronize read-only attributes between machines, but file permissions remain inherited from the directories. Thnaks, ...Karl From: Adrian Corduneanu To: [EMAIL PROTECTED] Subject: Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem]) Date: Sun, 21 Nov 2004 20:05:56 -0500

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

Hi All, One temporary solution is to use the Cygwin version of unison, rather than the native Windows version. The Cygwin unison package is available through setup, or can easily be compiled from sources in the Cygwin environment. Adrian Karl M wrote: Hi All... Back on Octber 4-6, Corinna, Chri

Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])

Hi All... Back on Octber 4-6, Corinna, Chris and Bob Byrnes were discussing temporarily reverting some of the pipe changes until a better solution is found so that native unison and other native programs would work with pipes (with ssh for example) on XP SP2. With the release of the 1.5.12 cygw

Re: 1.5.11-1: sftp performance problem

On Mon, Sep 13, 2004 at 01:45:17PM -0400, Bob Byrnes wrote: >On Sep 9, 1:46pm, Peter Siebold wrote: >-- Subject: 1.5.11-1: sftp performance problem >> I updated to the newest version of cygwin dll on 9/7/4 and after sftp >> suffered performance issues when issuing a get on a

Re: 1.5.11-1: sftp performance problem

On Sep 9, 1:46pm, Peter Siebold wrote: -- Subject: 1.5.11-1: sftp performance problem > > I updated to the newest version of cygwin dll on 9/7/4 and after sftp > suffered performance issues when issuing a get on a large file. File > transfers now stall and do not complete. After do

1.5.11-1: sftp performance problem

I updated to the newest version of cygwin dll on 9/7/4 and after sftp suffered performance issues when issuing a get on a large file. File transfers now stall and do not complete. After downgrading to version of 1.5.10-3 of cygwin sftp then it works fine. Both configurations used openssh 3.9p1-1

Re: Performance problem

Vladimir Baltchev wrote: In fact you have 3 gl.h in cygwin but only one library - libGL, and it's the X11 one... Nope. There is also libopengl32.a (in /usr/lib/w32api). That's the one used by the OpenGL package, and the one using hardware acceleration if available. and: OK, guys, I understan

Re: Performance problem

Vladimir, Just a clarification. OpenGL on Cygwin is *not* slow. OpenGL support in Cygwin/XFree86 *is* slow, because they do software emulation. If you use OpenGL with X, you will either have to bear the cost of this emulation, or rewrite the UI of your application to use the non-X OpenGL packag

Re: Performance problem

OK, guys, I understand what Andre is saying, but he said cygwin is offering an opportunity to use a OpenGL package different from the X11 one. In fact I am trying to use cygwin to avoid havy porting effort. Obviousely OpenGL on cygwin is slow and I'll forget about cygwin if I have to rewrite the

Re: Performance problem

Vladimir, I think you're a little too fixated on the portability aspects such that you're not really processing what Andre is saying. If you want absolute minimal porting changes, the route you took is the proper one, but you will suffer extreme performance degradation due to the fact that all of

Re: Performance problem

In fact you have 3 gl.h in cygwin but only one library - libGL, and it's the X11 one... Vladimir Baltchev wrote: The combination OpenGL X11 works fine on Unix. That's because it is hardware accelerated on Unix. We are trying to use cygwin to port our applications on Windows. The cyg

Re: Performance problem

Vladimir Baltchev wrote: The combination OpenGL X11 works fine on Unix. That's because it is hardware accelerated on Unix. We are trying to use cygwin to port our applications on Windows. The cygwin's OpenGL gives us the dependency on the X11 cygwin simulation on Windows which is slow, I gess..

Re: Performance problem

The combination OpenGL X11 works fine on Unix. We are trying to use cygwin to port our applications on Windows. The cygwin's OpenGL gives us the dependency on the X11 cygwin simulation on Windows which is slow, I gess... - If I am interpreting the output below correctly, you ar

Re: Performance problem

If I am interpreting the output below correctly, you are developing an OpenGL program under X11; that's the main reason it is so slow. OpenGL under X11 renders everything in software, without any hardware acceleration, so it's rendering is orders of magnitude slower. It is true that Cygwin's I/

Re: Performance problem

General observation: There are quite a few more optimizations that can have *some* impact on performance. Options for processor specific code and increased math speed. Note also -O2 is not maximum optimization, -O3 is: -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2

Re: Performance problem

Some amount of benchmarking has been done. You can see the email archives for reports from various interested folks with their comparisons. If you haven't already, visit . The FAQ covers some common issues that may affect your results. However, it sounds to me from t

Re: Performance problem

Thanks Larry, I know about the license. About the speed - it's several times slower... May be it worth the effort to make some benchmarking... Vlad Larry Hall wrote: Vladimir Baltchev wrote: Hi there, We are about to port Unix - Irix and Linux applications to Windows using Cygwin. However the C

Re: Performance problem

Vladimir Baltchev wrote: Hi there, We are about to port Unix - Irix and Linux applications to Windows using Cygwin. However the Cygwin version is very slow compared to Linux, even I compiled with the optimize option -O2. It is a Windows 2000, the program is a segmentation editor using Qt, OpenG

Performance problem

Hi there, We are about to port Unix - Irix and Linux applications to Windows using Cygwin. However the Cygwin version is very slow compared to Linux, even I compiled with the optimize option -O2. It is a Windows 2000, the program is a segmentation editor using Qt, OpenGl and some image processi

/proc/registry performance problem

Running "ls /proc/registry/HKEY_LOCAL_MACHINE" takes 5 to 10 seconds on my NT build machine. Using gdb to step through it, the culprit is the GetSecurityInfo() call in get_nt_object_attribute(). A google search shows up the following, a bug in GetSecurityInfo() in Windows that looks like it might

Re: pipe performance problem

Rob, I'm not sure if this finding ever made it through here as such, but in my experiments, nice-ing "mkisofs" up (negative nice value) and "cdrecord" down (positive nice value) I could turn certain failure of a 270 MB recording session into probable success. Still, the behavior was not ideal:

Re: pipe performance problem

On Fri, 2002-11-29 at 13:00, Christopher Faylor wrote: > Of course, it is entirely possible that there is something wrong with > the logic in cygwin and that a pipe is waiting 10ms for every read or > something like that. I don't know. I don't see how that's possible > from the code in ready_for

Re: pipe performance problem

On Thu, Nov 28, 2002 at 06:45:18PM -0800, Randall R Schulz wrote: >You mentioned "... on all flavors of Windows ...", suggesting that there >are better options on certain varieties of Windows, so another alternative, >perhaps less onerous (perhaps not) would be to use whatever OS-specific >facil

Re: pipe performance problem

Chris, At 18:00 2002-11-28, you wrote: ... ready_for_read is called for certain devices prior to actually reading from the device. It's purpose is to provide an interruptible method for "blocking" prior to reading since cygwin's signals need to act like UNIX signals and there is no real way

Re: pipe performance problem

On Fri, Nov 29, 2002 at 02:16:18AM +0100, thomas wrote: >Christopher Faylor <[EMAIL PROTECTED]> wrote: >> You're aware that it is a major holiday in the US, right? Guess what? >> I'm in the US. You shouldn't expect instant responses to your musings >> even in the best of times but certainly not n

Re: pipe performance problem

Christopher Faylor <[EMAIL PROTECTED]> wrote: > You're aware that it is a major holiday in the US, right? Guess what? > I'm in the US. You shouldn't expect instant responses to your musings > even in the best of times but certainly not now. I'm sorry, I wasn't really aware of it. > However, I'

Re: pipe performance problem

Randall R Schulz <[EMAIL PROTECTED]> wrote: > problem. In particular, you'll need to supply a patch script that will > allow others to replicate your results and evaluate whether there are any > potential problems with your solution that you're might be overlooking. There's already my problem. I

Re: pipe performance problem

Thomas, I think that's unwarranted. You needn't be so pessimistic. You've done good work in tracking down the source of an undesirable characteristic, but you need to follow through. Traditionally, the thing to do would be to write a single post (perhaps under a new "Subject:" thread) in which

Re: pipe performance problem

On Fri, Nov 29, 2002 at 01:26:00AM +0100, thomas wrote: >well i guess nobody considers this a problem ... too bad for the >cdrecord/cdrdao users out there. You're aware that it is a major holiday in the US, right? Guess what? I'm in the US. You shouldn't expect instant responses to your musings

Re: pipe performance problem

well i guess nobody considers this a problem ... too bad for the cdrecord/cdrdao users out there. thomas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ:

Re: pipe performance problem

Ok now i really found the problem. If i always return from fhandler_base::ready_for_read with 1 at the first line and skip all the checks in there everything works. $ time cat test.iso | nice -0 dd of=/dev/null 352512+0 records in 352512+0 records out real0m5.528s user0m2.155s sys 0m

Re: pipe performance problem

It seems to be a mystery whats going on, at least i'm not clever enough find it out :( Both sides of the pipe (cat and dd) wait at the same time, but what for? Is one waiting for the other and vice versa? I have no idea. Look here: 23 2139047 [main] cat 3660 fhandler_base::write: binary write

Re: pipe performance problem

Christopher Faylor <[EMAIL PROTECTED]> wrote: > On Thu, Nov 28, 2002 at 01:20:46AM +0100, thomas wrote: >>Christopher Faylor <[EMAIL PROTECTED]> wrote: >> >>> If there is no data in a pipe it can wait for 10ms waiting for it, yes. >>> See ready_for_read/peek_pipe in select.cc. >> >>Yep i saw the S

Re: pipe performance problem

On Thu, Nov 28, 2002 at 01:20:46AM +0100, thomas wrote: >Christopher Faylor <[EMAIL PROTECTED]> wrote: > >> If there is no data in a pipe it can wait for 10ms waiting for it, yes. >> See ready_for_read/peek_pipe in select.cc. > >Yep i saw the Sleep (10) and though the same thing, but i figured that

Re: pipe performance problem

thomas <[EMAIL PROTECTED]> wrote: >26 245082 [main] dd 3100 readv: DEBUG 1.a syscalls.cc >23 245105 [main] dd 3100 readv: DEBUG 1.b syscalls.cc >23 245128 [main] dd 3100 readv: DEBUG 2.a syscalls.cc >23 245151 [main] dd 3100 readv: readv (0, 0x240FD9C, 1) blocking, sigcatchers

Re: pipe performance problem

Christopher Faylor <[EMAIL PROTECTED]> wrote: > If there is no data in a pipe it can wait for 10ms waiting for it, yes. > See ready_for_read/peek_pipe in select.cc. Yep i saw the Sleep (10) and though the same thing, but i figured that can't be it when i commented it out, compiled a new cygwin1.d

Re: pipe performance problem

On Wed, Nov 27, 2002 at 10:39:05PM +0100, thomas wrote: >10 ms delay, and there's many of them. Exactly every 612 lines or every >34816 bytes (34kb). Which is about 210 seconds delay on a 700MB file. If there is no data in a pipe it can wait for 10ms waiting for it, yes. See ready_for_read/peek_p

Re: pipe performance problem

Hi List, I'm back with more information, I've narrowed down the problem further with another strace session. I've run: cat test.iso | strace -o dd1.log nice --1 dd of=/dev/null cat test.iso | strace -o dd0.log nice --0 dd of=/dev/null nice --1 needs much longer, like already shown in another th

Re: pipe performance problem

es are master on their own channel with no slaves. I'd pretty much rule out a performance problem here. > So, where do I get this CD recording software you're using? I don't know if > you built it yourself or got a pre-built binary, but I think I'd like to > conf

Re: pipe performance problem

Thomas, At 14:04 2002-11-22, you wrote: ... now please correct me if i'm wrong, but when it works with 1.1.18 and not with 1.3.x and the only constant that changes is cygwin, wouldn't every fan of logic scream out loud then: it's cygwin! :) Don't bite my head off, Tuvok, but your "logic" is f

Re: pipe performance problem

On Fri, Nov 22, 2002 at 11:04:15PM +0100, thomas wrote: >Christopher Faylor <[EMAIL PROTECTED]> wrote: >>If the relevant code was obvious then it would be trivial to fix. I'm >>not even convinced that there is a cygwin problem here. It doesn't >>appear to be doing anything wrong. However, unless

Re: pipe performance problem

Christopher Faylor <[EMAIL PROTECTED]> wrote: > If the relevant code was obvious then it would be trivial to fix. I'm > not even convinced that there is a cygwin problem here. It doesn't > appear to be doing anything wrong. However, unless you are doing something > with ttys I don't see why tha

Re: pipe performance problem

On Fri, Nov 22, 2002 at 10:00:59PM +0100, thomas wrote: >well i'm a bit lost here. can someone point me in some direction what >to do next? where is the relevant code, i figured it must be pipe.cc >and tty.cc or is there some other place? If the relevant code was obvious then it would be trivial

Re: pipe performance problem

well i'm a bit lost here. can someone point me in some direction what to do next? where is the relevant code, i figured it must be pipe.cc and tty.cc or is there some other place? also do i have to recompile the binaries when i build a new cygwin1.dll to test the changes? thomas -- Unsubscribe

Re: pipe performance problem

Max Bowsher <[EMAIL PROTECTED]> wrote: > thomas <[EMAIL PROTECTED]> wrote: >> it seems that the pipe code with recent cygwin versions causes a >> performance problem when much data (3.6 MB per second in this case) is >> transferred from one program to another. &

Re: pipe performance problem

thomas <[EMAIL PROTECTED]> wrote: > it seems that the pipe code with recent cygwin versions causes a > performance problem when much data (3.6 MB per second in this case) is > transferred from one program to another. > > i use mkisofs to make an iso filesystem from files on t

pipe performance problem

hello, it seems that the pipe code with recent cygwin versions causes a performance problem when much data (3.6 MB per second in this case) is transferred from one program to another. i use mkisofs to make an iso filesystem from files on the fly and pipe the output directly to cdrecord which

Re: RPClib performance problem

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > Hello all, > > David Geldreich wrote: > > Andrej Falout wrote: > > > rpclib on CygWin? As in Sun RPC (XDR) lib on CygWin? Where did you get it? > >In fact, I found the sources from where was coming my rpclib > >http://dever

Re: RPClib performance problem

Hello all, David Geldreich wrote: > Andrej Falout wrote: > > rpclib on CygWin? As in Sun RPC (XDR) lib on CygWin? Where did you get it? In fact, I found the sources from where was coming my rpclib http://devernay.free.fr/hacks/sunrpc-4.0.2.tar.gz -- Unsubscribe info: http://cygwi

Re: RPClib performance problem

Hello all, Andrej Falout wrote: > > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > says... > > I suspect my problem is coming from rpclib, but I cannot manage to find from >where this libs > > come. > > rpclib on CygWin? As in Sun RPC (XDR) lib on CygWin? Where did you get it?

Re: RPClib performance problem

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > I suspect my problem is coming from rpclib, but I cannot manage to find from >where this libs > come. rpclib on CygWin? As in Sun RPC (XDR) lib on CygWin? Where did you get it? -- Yours, Andrej Falout, http://www.falout.com/discla

RPClib performance problem

Hello cygwiners, I am currently trying to debug performance problem of a program compiled with cygwin. I made a little RPC client/server application, client requesting an image and the server returning it. With the client under linux, I got a 10Mb/s, with the server either on linux