Re: Timing graphics in the real world

*To*: mathgroup at smc.vnet.net*Subject*: [mg123010] Re: Timing graphics in the real world*From*: DrMajorBob <btreat1 at austin.rr.com>*Date*: Sun, 20 Nov 2011 05:37:23 -0500 (EST)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <201111191145.GAA18886@smc.vnet.net>*Reply-to*: drmajorbob at yahoo.com

I suppose you'd need to adjust Plot/Show options such as PerformanceGoal, PlotPoints, MaxRecursion... or limit the use of elements like Opacity or Mesh that lead to a lot of rendering band-width. Rasterize might help, in that it allows you to control ImageResolution. I can't think of anything else, off-hand. Bobby On Sat, 19 Nov 2011 16:44:05 -0600, Ralph Dratman <ralph.dratman at gmail.com> wrote: > Thank you, Bobby. I understand that. Now how do I speed up the > graphics? I am prepared to spend $ if necessary! Or... maybe I am > asking this particular question in the wrong forum. If so... my > apologies. I don't wish to be a pest. > > Ralph > > On Sat, Nov 19, 2011 at 3:24 PM, DrMajorBob <btreat1 at austin.rr.com> > wrote: >> A quote from Help: >> >> "AbsoluteTiming[expr] measures only the time involved in actually >> evaluating >> expr, not time involved in formatting the result." >> >> Graphics rendering occurs in the FrontEnd, not the Kernel, so >> AbsoluteTiming >> doesn't count it. >> >> Bobby >> >> On Sat, 19 Nov 2011 05:45:59 -0600, Ralph Dratman >> <ralph.dratman at gmail.com> >> wrote: >> >>> I am trying to find out why a piece of 3D graphics code takes a long >>> time when scaled up to a lot of little objects. For this purpose I >>> begin by timing ten runs of a small instance. Here's what my function >>> calls look like: >>> >>> noneOfThat[] := >>> Module[{}, {drawSolidCube[], drawSolidCube[], drawSolidCube[], >>> drawSolidCube[], drawSolidCube[], drawSolidCube[], drawSolidCube[], >>> drawSolidCube[], drawSolidCube[], drawSolidCube[]}] >>> >>> where SolidCube is actually not solid, but rather an aggregate of >>> about 20 cubelets per image in this first test case. >>> >>> AbsoluteTiming[noneOfThat[]] >>> {0.072105, ...} >>> >>> or if you prefer, >>> >>> Timing[noneOfThat[]] >>> {0.071197, ...} >>> >>> The timing answers are consistent within about 10% across several >>> tries. >>> Nice. >>> >>> Just one problem: here in my universe, on a Core Duo Mac Mini at 2.4 >>> GHz with about 2 GB of free memory, the actual process described above >>> takes about 10 seconds. The cores stay at around 50% usage (each) >>> while this is happening. Drawing is taking about 140 times longer than >>> Mathematica says! >>> >>> Next I try the same task with a 2x increase in linear size of the >>> cube, leading to an 8x increase in volume and number of objects, with >>> again 10 repetitions in straight-line Mathematica code. >>> >>> AbsoluteTiming then says 0.62970 while Timing says 0.574067, both in >>> the neighborhood of 8 times the earlier figures. Real-world time is >>> about 85 seconds, also in line with the 8x scaling. >>> >>> Again the processors seem to be about half busy, and once again it >>> takes about 140 times as long to do the real drawing as Mathematica >>> reports. >>> >>> I'm speculating all this means Mathematica is sending my graphics >>> hardware a bunch of asynchronous drawing calls while simultaneously >>> announcing, "Done!" >>> >>> I infer that a faster graphics card might make a world of difference. >>> To make that possible, I could switch to a Windows or Linux system if >>> necessary. >>> >>> If possible, I would like the new real-world drawing time to be at >>> least ten times better than the figures reported here. >>> >>> Comments, please? I would be particularly interested to learn about >>> any specific hardware that might improve the speed. >>> >>> Thank you very much. >>> >>> Ralph Dratman >>> >> >> >> -- >> DrMajorBob at yahoo.com >> -- DrMajorBob at yahoo.com

**References**:**Timing graphics in the real world***From:*Ralph Dratman <ralph.dratman@gmail.com>