Menu
▾
▴
gnuplot-beta
|
From: Jim K. <je...@kl...> - 2005-01-10 20:31:14
|
I'm using gnuplot to create PDF files most of the time. I find that the unbuffered setting to make X11 work with the mouse and pasteboard vastly increases the syscall overhead for this batch operation. Would it make sense to add an argument to be able to permit buffering? I'm using cygwin so perhaps there is some set of porting options that interact on this platform. Thanks - Jim |
|
From: Jim K. <je...@kl...> - 2005-01-11 05:47:42
|
Jim Kleckner wrote:
> I'm using gnuplot to create PDF files most of the time. I find that
> the unbuffered setting to make X11 work with the mouse and pasteboard
> vastly increases the syscall overhead for this batch operation. Would
> it make sense to add an argument to be able to permit buffering? I'm
> using cygwin so perhaps there is some set of porting options that
> interact on this platform.
I looked at the code lower down where the "interactive" variable is set.
The most minimal change seemed to be to duplicate the isatty code as
follows:
diff -u -r1.72 plot.c
--- plot.c 25 Aug 2004 22:33:16 -0000 1.72
+++ plot.c 11 Jan 2005 05:26:21 -0000
@@ -422,7 +422,9 @@
* Do any non-X platforms suffer from the same problem?
* EAM - Jan 2004.
*/
- setvbuf(stdin, (char *) NULL, _IONBF, 0);
+ if (isatty(fileno(stdin))) {
+ setvbuf(stdin, (char *) NULL, _IONBF, 0);
+ }
#endif
My regression tests before the change (on a 3GHz P4 HT machine) used:
940.66user 628.54system 25:19.91elapsed
and after:
621.38user 5.32system 10:22.86elapsed
The difference is so big because I'm using gnuplot-py to drive
the plots and it uses a pipe and inline data (quite a lot of it).
Comments? I might easily be missing something important
here.
Jim
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-11 06:46:14
|
On Monday 10 January 2005 09:47 pm, Jim Kleckner wrote:
> I looked at the code lower down where the "interactive" variable is set.
> The most minimal change seemed to be to duplicate the isatty code as
> follows:
>
> diff -u -r1.72 plot.c
> --- plot.c 25 Aug 2004 22:33:16 -0000 1.72
> +++ plot.c 11 Jan 2005 05:26:21 -0000
> @@ -422,7 +422,9 @@
> * Do any non-X platforms suffer from the same problem?
> * EAM - Jan 2004.
> */
> - setvbuf(stdin, (char *) NULL, _IONBF, 0);
> + if (isatty(fileno(stdin))) {
> + setvbuf(stdin, (char *) NULL, _IONBF, 0);
> + }
> #endif
This code was added originally because it was needed in order
that piped input not lose large runs of input characters
at the start of the file and also after "pause -1" statements.
It may be that your particular environment does not need this,
but I am pretty sure that the modification you propose above
will re-break the same cases that caused the problem in the
first place.
In other words, a test on isatty() is not what is needed.
I think a command line option, as you originally suggested,
is the only safe way to disable this. Users can try it with
and without the extra option to determine whether their
particular environment requires immediate flushing or not.
> My regression tests before the change (on a 3GHz P4 HT machine) used:
> 940.66user 628.54system 25:19.91elapsed
> and after:
> 621.38user 5.32system 10:22.86elapsed
I see why you want this. But speed is no good if the program
does not function properly, and previous experience showed that
unbuffering the input stream was needed for at least some
implementations of piped input.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-11 17:43:48
|
On Monday 10 January 2005 10:46 pm, Ethan Merritt wrote:
> >
> > diff -u -r1.72 plot.c
> > --- plot.c 25 Aug 2004 22:33:16 -0000 1.72
> > +++ plot.c 11 Jan 2005 05:26:21 -0000
> > @@ -422,7 +422,9 @@
> > * Do any non-X platforms suffer from the same problem?
> > * EAM - Jan 2004.
> > */
> > - setvbuf(stdin, (char *) NULL, _IONBF, 0);
> > + if (isatty(fileno(stdin))) {
> > + setvbuf(stdin, (char *) NULL, _IONBF, 0);
> > + }
> > #endif
>
>
> I see why you want this. But speed is no good if the program
> does not function properly, and previous experience showed that
> unbuffering the input stream was needed for at least some
> implementations of piped input.
I have changed my mind. The behavior is not likely to differ
from user to user, only from one platform to another. So it should
be a configuration option for building on that platform, not a
run-time option on the command line.
How about we wrap the code as follows:
#ifndef UNBUFFERED_STDIN
setvbuf(stdin, (char *) NULL, _IONBF, 0);
#endif
and you can provide a brief set of instructions for how to set
this conditional compilation flag during the cygwin configuration setup.
I have not used cygwin, so I don't know exactly how that is done.
It would be nice if you also checked that this doesn't interfere
with correct execution of "pause" commands, however, since as I
recall that was one of the original problems this was supposed to fix.
For instance, please check that "mousevariables.dem" works properly with
buffered input under cygwin.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Jim K. <je...@kl...> - 2005-01-11 19:15:02
|
Ethan Merritt wrote:
>On Monday 10 January 2005 10:46 pm, Ethan Merritt wrote:
>
>
>>>diff -u -r1.72 plot.c
>>>--- plot.c 25 Aug 2004 22:33:16 -0000 1.72
>>>+++ plot.c 11 Jan 2005 05:26:21 -0000
>>>@@ -422,7 +422,9 @@
>>> * Do any non-X platforms suffer from the same problem?
>>> * EAM - Jan 2004.
>>> */
>>>- setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>>+ if (isatty(fileno(stdin))) {
>>>+ setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>>+ }
>>> #endif
>>>
>>>
>>I see why you want this. But speed is no good if the program
>>does not function properly, and previous experience showed that
>>unbuffering the input stream was needed for at least some
>>implementations of piped input.
>>
>>
>
>I have changed my mind. The behavior is not likely to differ
>from user to user, only from one platform to another. So it should
>be a configuration option for building on that platform, not a
>run-time option on the command line.
>
>How about we wrap the code as follows:
>
>#ifndef UNBUFFERED_STDIN
> setvbuf(stdin, (char *) NULL, _IONBF, 0);
>#endif
>
>and you can provide a brief set of instructions for how to set
>this conditional compilation flag during the cygwin configuration setup.
>I have not used cygwin, so I don't know exactly how that is done.
>
>It would be nice if you also checked that this doesn't interfere
>with correct execution of "pause" commands, however, since as I
>recall that was one of the original problems this was supposed to fix.
>For instance, please check that "mousevariables.dem" works properly with
>buffered input under cygwin.
>
>
>
cygwin looks like a unix box with X11 and it already appears in
configure I see.
I have just been doing configure and build and it works fine (I pre-install
the PDF library so that it will get detected at configure time).
The demo seems to work the same way with buffering on or off.
It also seems to work correctly with one exception. A tab or enter
does not terminate the keystroke.dem sub-test.
Jim
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-11 19:20:59
|
On Tuesday 11 January 2005 11:14 am, Jim Kleckner wrote: > > The demo seems to work the same way with buffering on or off. > It also seems to work correctly with one exception. A tab or enter > does not terminate the keystroke.dem sub-test. OK. Thanks. That last is a known bug. I've got a fix for it, but it's currently wrapped in a larger patchset that I want to have discussed on the mailing list. Maybe I should break it out separately. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Jim K. <je...@kl...> - 2008-06-30 20:01:08
Attachments:
gnuplot-setvbuf.patch
|
Ethan Merritt wrote:
> On Monday 10 January 2005 10:46 pm, Ethan Merritt wrote:
>>> diff -u -r1.72 plot.c
>>> --- plot.c 25 Aug 2004 22:33:16 -0000 1.72
>>> +++ plot.c 11 Jan 2005 05:26:21 -0000
>>> @@ -422,7 +422,9 @@
>>> * Do any non-X platforms suffer from the same problem?
>>> * EAM - Jan 2004.
>>> */
>>> - setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>> + if (isatty(fileno(stdin))) {
>>> + setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>> + }
>>> #endif
>>
>> I see why you want this. But speed is no good if the program
>> does not function properly, and previous experience showed that
>> unbuffering the input stream was needed for at least some
>> implementations of piped input.
>
> I have changed my mind. The behavior is not likely to differ
> from user to user, only from one platform to another. So it should
> be a configuration option for building on that platform, not a
> run-time option on the command line.
>
> How about we wrap the code as follows:
>
> #ifndef UNBUFFERED_STDIN
> setvbuf(stdin, (char *) NULL, _IONBF, 0);
> #endif
>
> and you can provide a brief set of instructions for how to set
> this conditional compilation flag during the cygwin configuration setup.
> I have not used cygwin, so I don't know exactly how that is done.
>
> It would be nice if you also checked that this doesn't interfere
> with correct execution of "pause" commands, however, since as I
> recall that was one of the original problems this was supposed to fix.
> For instance, please check that "mousevariables.dem" works properly with
> buffered input under cygwin.
The attached patch achieves the speedup and works
properly with mousevariables.dem.
The use of __CYGWIN__ makes it specific to that platform.
I suspect this would also help other platforms.
Please consider for upstream inclusion.
Thanks - Jim
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-12 00:22:53
|
On Tuesday 11 January 2005 11:14 am, Jim Kleckner wrote: > > > cygwin looks like a unix box with X11 and it already appears in > configure I see. But does it define some symbol I can test on to see if the current ./configure is being run on cygwin? I don't see any mention of cygwin in any of gnuplot's own configuration files. The closest I can find is the forced definition of __WIN32__ in the file config/config.cyg but I am not sure how specific that is. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Jim K. <je...@kl...> - 2005-01-12 02:59:32
|
Ethan Merritt wrote: > On Tuesday 11 January 2005 11:14 am, Jim Kleckner wrote: > >>cygwin looks like a unix box with X11 and it already appears in >>configure I see. > > > But does it define some symbol I can test on to see if the > current ./configure is being run on cygwin? > > I don't see any mention of cygwin in any of gnuplot's own configuration > files. The closest I can find is the forced definition of __WIN32__ > in the file config/config.cyg but I am not sure how specific that is. I just noted comments in FAQ and INSTALL. gcc has __CYGWIN__ defined for the platform. BTW, the comment in INSTALL seems wrong now as cygwin seems to configure and build for X11 "out of the box". The comment says something about copying a makefile.cyg and using that. Not needed if you are using cygwin for X11 and not trying to build a native windows app with mingw. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-12 04:31:01
|
On Tuesday 11 January 2005 06:59 pm, Jim Kleckner wrote: > > I just noted comments in FAQ and INSTALL. > gcc has __CYGWIN__ defined for the platform. That does not, by itself, make it easy to test in the configure script. I'm sure it's possible to exploit it somehow and feed back a symbol to autoconf, but I'll leave that to the autoconf experts. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2005-01-12 07:38:04
|
> I just noted comments in FAQ and INSTALL. > gcc has __CYGWIN__ defined for the platform. > > BTW, the comment in INSTALL seems wrong now as > cygwin seems to configure and build for X11 > "out of the box". The comment says something > about copying a makefile.cyg and using that. > Not needed if you are using cygwin for X11 and > not trying to build a native windows app with > mingw. With cygwin, you can either 1. build native Win API wgnuplot.exe as described above, or 2. build X11 gnuplot.exe by the unixish ./configure; make procedure Into INSTALL, it should probably be added a note at the end of the MSW section about the possibility 2 and refer to the Unix section. --- PM |
