On my multicore machine the tic-toc timing is practically the same, but cputime() shows a significant speed-up.
Cheers, Olli
> -----Original Message----- > From: Tatsuro MATSUOKA [mailto:address@hidden]
> Sent: 3. elokuuta 2009 12:16 > To: Saarela Olli > Cc: address@hidden > Subject: Re: Plotting with 3.2.0 on Windows is SLOOOOOOWWWW > > Hello >
> The patch I have cosidered for octave_popen2 in iboctave/losyspep.cc > > See > > http://www.nabble.com/Re:-Plotting-with-3.2.0-on-Windows-is-
> SLOOOOOOWWWW-p24766712.html > > For the convenience to understand this problem I show the code of > patched octave_popen2 function. > > ********** > pid_t > octave_popen2 (const std::string& cmd, const string_vector& args, bool
> sync_mode, > int *fildes, std::string& msg) > { > pid_t pid; > PROCESS_INFORMATION pi; > STARTUPINFO si; > std::string command = "\"" + cmd + "\"";
> HANDLE hProcess = GetCurrentProcess(), childRead, childWrite, > parentRead, parentWrite; > DWORD pipeMode; > > ZeroMemory (&pi, sizeof (pi)); > ZeroMemory (&si, sizeof (si));
> si.cb = sizeof (si); > > if (! CreatePipe (&childRead, &parentWrite, 0, 65536) || > ! DuplicateHandle (hProcess, childRead, hProcess, &childRead, 0, > TRUE, DUPLICATE_SAME_ACCESS |
> DUPLICATE_CLOSE_SOURCE)) > { > msg = "popen2: pipe creation failed"; > return -1; > } > if (! CreatePipe (&parentRead, &childWrite, 0, 0) || > ! DuplicateHandle (hProcess, childWrite, hProcess, &childWrite,
> 0, TRUE, DUPLICATE_SAME_ACCESS | > DUPLICATE_CLOSE_SOURCE)) > { > msg = "popen2: pipe creation failed"; > return -1; > } > if (! sync_mode) > {
> pipeMode = PIPE_NOWAIT; > SetNamedPipeHandleState (parentRead, &pipeMode, 0, 0); > } > fildes[1] = _open_osfhandle (reinterpret_cast<long> (parentRead), > _O_RDONLY | _O_BINARY);
> fildes[0] = _open_osfhandle (reinterpret_cast<long> (parentWrite), > _O_WRONLY | _O_BINARY); > si.dwFlags |= STARTF_USESTDHANDLES; > si.hStdInput = childRead; > si.hStdOutput = childWrite;
> > // Ignore first arg as it is the command > for (int k=1; k<args.length(); k++) > command += " \"" + args[k] + "\""; > OCTAVE_LOCAL_BUFFER (char, c_command, command.length () + 1);
> strcpy (c_command, command.c_str ()); > if (! CreateProcess (0, c_command, 0, 0, TRUE, 0, 0, 0, &si, &pi)) > { > msg = "popen2: process creation failed"; > return -1;
> } > SetPriorityClass(pi.hProcess, ABOVE_NORMAL_PRIORITY_CLASS); // added > line > pid = pi.dwProcessId; > > CloseHandle (childRead); > CloseHandle (childWrite); > CloseHandle (pi.hProcess);
> CloseHandle (pi.hThread); > > return pid; > } > ******************* > > SetPriorityClass(pi.hProcess, ABOVE_NORMAL_PRIORITY_CLASS); // added > line > > This make the child process has always has the absolute higher priority
> class. > If the parent process is octave and child process is gnuplot this is > realistic. > However in general sense I have an anxiety for this simple patch > > Your code is worth to be examined.
> > Thanks!! > > Tatsuro > > --- Saarela Olli wrote: > > > Hi, > > > > > octave-3.2.0 occupied 99% cpu activity and thus I guessed that > > > the speed gnuplot made slower and thus led to slooooow plotting.
> > > > Such symptoms can arise if the lack of select() in Windows is worked > around with something like > > > > time_t now = time(NULL); > > while (time(NULL) < now + timeout) {
> > PeekNamedPipe(read_handle, NULL, 0, NULL, &len, NULL)); > > if (len > 0) // data is available > > break; > > } > > > > which would consume all available CPU time until the program at the
> other end of the pipe has > > written something. If this is the case, instead of treating the > symptoms with changed process > > priorities you might want to go closer to the root cause by adding a
> short sleep to the code, > > e.g., > > > > DWORD sleeptime = 1; // 1 millisecond > > time_t now = time(NULL); > > while (time(NULL) < now + timeout) { > > PeekNamedPipe(read_handle, NULL, 0, NULL, &len, NULL));
> > if (len > 0) // data is available > > break; > > Sleep(sleeptime); > > if (sleeptime < 64) > > sleeptime *= 2; > > } > >
> > I don't know my way around Octave's C++ sources and couldn't find > PeekNamedPipe in them, so I > > don't really know if this is the case. The actual loop structure (if > any) could involve calling
> > several functions and instead of PeekNamedPipe can, e.g., call an > unblocking read. Anyway, I > > hope this helps debugging. > > > > Cheers, Olli > > > > >
> > -------------------------------------- > Power up the Internet with Yahoo! Toolbar. > http://pr.mail.yahoo.co.jp/toolbar/