[Rd] (no subject)
Byron Ellis
byron.ellis at gmail.com
Mon Apr 7 20:42:10 CEST 2008
FWIW, on my apparently somewhat slower MacBook running R-2.7.0 on 10.5:
Quartz (Screen)
user system elapsed
0.747 0.008 0.760
Quartz (PNG)
user system elapsed
0.622 0.006 0.628
X11 (Xlib)
user system elapsed
0.858 0.067 1.714 (Almost all communication overhead)
X11 Cairo segfaults on my system for some reason somewhere in GTK. So
the Quartz implementation isn't that far out of the running.
On Mon, Apr 7, 2008 at 6:45 AM, Roger D. Peng <rpeng at jhsph.edu> wrote:
> For what it's worth, one area where I've noticed a big change is when I add to a
> plot in a for loop. For example, many calls to 'lines' or 'points'. Notice:
>
> > x <- runif(2000, -1, 1)
> > y <- runif(2000, -1, 1)
> > X11(type = "cairo")
> > plot(0,0)
> > system.time(for(i in 1:2000) points(x[i], y[i]))
> user system elapsed
> 1.296 3.528 21.963
>
> > X11(type = "Xlib")
> > plot(0,0)
> > system.time(for(i in 1:2000) points(x[i], y[i]))
> user system elapsed
> 0.444 0.032 0.509
>
>
> This is not a particularly wonderful example and I think in most situations
> there are better ways to do something like this than putting 'points' in a loop.
> But I wonder how many developers assume that this type of operation will run
> quickly?
>
> -roger
>
> Prof Brian Ripley wrote:
> > Martin M x 2,
> >
> > Yes, no news in either of your most recent messages. That's a really ugly
> > plot, though, and I do want to protest about either of these being worth
> > doing fast.
> >
> > On my home system
> >
> >> F <- ecdf(rnorm(10000))
> >> system.time(plot(F))
> > user system elapsed
> > 1.343 0.035 1.410
> >> x11(type="Xlib")
> >> system.time(plot(F))
> > user system elapsed
> > 0.022 0.002 0.083
> >
> > and if something is worth plotting, it is surely worth waiting 1.4s for?
> > (About 1/4 the time is spent on antialiasing.)
> >
> > Martin Morgan's example is atypical (how often do people do scatterplots
> > of 10,000 points? Or ecdfs, come to that?), but I see
> >> X11(type="Xlib")
> >> system.time(doplots(df)) # gcFirst=TRUE is the default
> > user system elapsed
> > 0.174 0.005 0.187
> >> X11(type="cairo")
> >> system.time(doplots(df))
> > user system elapsed
> > 2.315 0.035 2.388
> >> X11(type="nbcairo")
> >> system.time(doplots(df))
> > user system elapsed
> > 1.844 0.057 1.920
> >
> > However, I think the plots produced are pretty uniformative whereas using
> > a smaller translucent filled disc as the symbol would give more
> > information (and "Xlib" cannot do that).
> >
> > The BioC package flowViz has some quite extreme examples of arrays of
> > scatterplots of ca 25,000 points, and they are acceptably fast with
> > type="cairo" on my system (they certainly plot much faster than I would
> > need to appreciate what they are trying to say).
> >
> > It is very easy to change the default default (X11.options(type="Xlib") in
> > .Rprofile), and so the only question was 'what is best for most users?'.
> > As we think they will have local displays and be working with hundreds
> > rather than tens of thousands of points, the current default default seems
> > the best compromise.
> >
> > IncidentaSubject: Re: [Rd]lly, windows() and quartz() are nowhere near as fast as Xlib on
> > the same or similar hardware. On my laptop
> >
> >> system.time(plot(F))
> > user system elapsed
> > 0.14 0.43 0.72
> >> system.time(doplots(df))
> > user system elapsed
> > 0.38 0.58 1.25
> >
> > and I don't usually feel that machine is slow (it was its 3rd birthday
> > last week).
> >
> > I don't know how you live without graphics acceleration -- I've seen it on
> > my systems (1600x1200 and 1680x1050) when drivers have failed to update
> > and know I don't even want to text edit without it.
> >
> >
> > On Sat, 5 Apr 2008, Martin Maechler wrote:
> >
> >>>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk>
> >>>>>>> on Sat, 5 Apr 2008 16:27:52 +0100 (BST) writes:
> >> BDR> On Sat, 5 Apr 2008, Martin Morgan wrote:
> >> >> Yes, thank you, this fixes the problem for me.
> >> >>
> >> >> As a follow-up, and again with my ignorance of where
> >> >> processing is actually occuring, it seems like the X11
> >> >> window content is drawn directly rather than being drawn
> >> >> to a buffer and then blit on to the screen -- the
> >> >> original appearance of the plot is slow, compared to,
> >> >> e.g., hiding and then revealing the image once it has
> >> >> been plotted.
> >>
> >> BDR> That is not so for the default type="cairo". The
> >> BDR> problem is likely to be that the bitblt is across the
> >> BDR> network, whereas repaint is a bitblt from a local copy.
> >>
> >> BDR> There are some comments on the X11() help page -- you
> >> BDR> may want to try type = "nbcairo". Some changes are
> >> BDR> planned for R 2.8.0 which will improve performance, but
> >> BDR> for now things are tuned for the most common case of a
> >> BDR> local X11 display (although type = "nbcairo" works
> >> BDR> quite well over my home wireless network).
> >>
> >> Sorry to chime in; I had wanted to bring this to Brian's
> >> attention a few days ago, but always got side-tracked:
> >>
> >> Here are results on my IBM/Lenowo X41 notebook
> >> model name : Intel(R) Pentium(R) M processor 1.50GHz
> >> cpu MHz : 600.000
> >> bogomips : 1198.37
> >> MemTotal: 1546600 kB
> >>
> >> with *no* graphics acceleration:
> >> Everything is local but not really fast hardware
> >>
> >>> F <- ecdf(rnorm(10000))
> >>> system.time(plot(F))
> >> user system elapsed
> >> 3.204 0.024 3.402
> >>> x11(type="Xlib")
> >>> system.time(plot(F))
> >> user system elapsed
> >> 0.068 0.000 0.354
> >> which is somewhat dramatic,
> >> and for tk*() pseudo-animations, I have definitely needed to use
> >> type = "Xlib"
> >>
> >> Martin
> >>
> >>
> >> >> R version 2.8.0 Under development (unstable) (2008-04-05
> >> >> r45102)
> >> >>
> >> >> Thank you again for tracking down the original issue.
> >> >>
> >> >> Martin
> >> >>
> >> >> Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
> >> >>
> >> >>> I think I have found this -- if so, it was an X11 timing
> >> >>> issue and we needed to re-read the X11 window size at a
> >> >>> later time. Please try r45102 or later.
> >> >>>
> >> >>> On Fri, 4 Apr 2008, Prof Brian Ripley wrote:
> >> >>>
> >> >>>> On Thu, 3 Apr 2008, Martin Morgan wrote:
> >> >>>>
> >> >>>>> I apologize if this is too obscure to reproduce, or
> >> >>>>> some idiosyncratic aspects of my system. If I create a
> >> >>>>> plot, e.g.,
> >>>>>>> plot(1:10) I get a graphics device as expected. I then
> >> >>>>> click on the 'zoom' box on my X11 window, so the
> >> >>>>> window expands to occupy the entire screen. The plot
> >> >>>>> is redrawn at the scale of the large window, but is
> >> >>>>> clipped to the 'unzoomed' size. I only see the top
> >> >>>>> left portion of the plot, occupying the space of the
> >> >>>>> original image. Here are the R essentials; I'm using
> >> >>>>> X11 on a recent SuSE, connecting via a moderately
> >> >>>>> out-of-date cygwin from Windows. I'm happy to provide
> >> >>>>> more detail if pointed in the right direction (and
> >> >>>>> will trouble shoot myself if this is not a general
> >> >>>>> problem).
> >> >>>>
> >> >>>> We've seen it, but not all systems do it. At present
> >> >>>> it looks like a cairo bug, but more work is needed on
> >> >>>> it. If we haven't found a workaround by release time,
> >> >>>> it will be documented on the help page.
> >> >>>>
> >>>>>>> sessionInfo()
> >> >>>>> R version 2.8.0 Under development (unstable)
> >> >>>>> (2008-04-03 r45066) x86_64-unknown-linux-gnu locale:
> >> >>>>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
> >> >>>>> attached base packages: [1] stats graphics grDevices
> >> >>>>> utils datasets methods base
> >>>>>>> capabilities() jpeg png tcltk X11 aqua http/ftp sockets
> >> >>>>> libxml TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE fifo
> >> >>>>> cledit iconv NLS profmem cairo TRUE TRUE TRUE TRUE
> >> >>>>> TRUE TRUE Martin
> >> >>>>> --
> >> >>>>> Martin Morgan Computational Biology / Fred Hutchinson
> >> >>>>> Cancer Research Center 1100 Fairview Ave. N. PO Box
> >> >>>>> 19024 Seattle, WA 98109 Location: Arnold Building M2
> >> >>>>> B169 Phone: (206) 667-2793
> >> >>>>> ______________________________________________
> >> >>>>> R-devel at r-project.org mailing list
> >> >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >> >>>>>
> >> >>>>
> >>>>> --
> >>>>> Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied
> >> >>>> Statistics, http://www.stats.ox.ac.uk/~ripley/
> >> >>>> University of Oxford, Tel: +44 1865 272861 (self) 1
> >> >>>> South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG,
> >> >>>> UK Fax: +44 1865 272595
> >> >>>>
> >> >>>
> >>>> --
> >>>> Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied
> >> >>> Statistics, http://www.stats.ox.ac.uk/~ripley/
> >> >>> University of Oxford, Tel: +44 1865 272861 (self) 1
> >> >>> South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG,
> >> >>> UK Fax: +44 1865 272595
> >> >>
> >> >> --
> >> >> Martin Morgan Computational Biology / Fred Hutchinson
> >> >> Cancer Research Center 1100 Fairview Ave. N. PO Box
> >> >> 19024 Seattle, WA 98109
> >> >>
> >> >> Location: Arnold Building M2 B169 Phone: (206) 667-2793
> >> >>
> >>
> >> --
> >> Brian D. Ripley, ripley at stats.ox.ac.uk
> >> BDR> Professor of Applied Statistics,
> >> BDR> http://www.stats.ox.ac.uk/~ripley/ University of
> >> BDR> Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road,
> >> BDR> +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865
> >> BDR> 272595
> >>
> >> BDR> ______________________________________________
> >> BDR> R-devel at r-project.org mailing list
> >> BDR> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
>
> --
> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Byron Ellis (byron.ellis at gmail.com)
"Oook" -- The Librarian
More information about the R-devel
mailing list