Re: Timing graphics in the real world

*To*: mathgroup at smc.vnet.net*Subject*: [mg123022] Re: Timing graphics in the real world*From*: Yves Klett <yves.klett at googlemail.com>*Date*: Mon, 21 Nov 2011 04:25:18 -0500 (EST)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <201111191145.GAA18886@smc.vnet.net> <jaaljn$18q$1@smc.vnet.net>

Hi, why not supply the whole code so we can run some (subjective) timings? If you have lots of elements, try to use the multi-primitive syntax (e.g. Polygon[{{a,b,c},{d,e,f},...}]) which can drastically speed up the rendering. Regards, Yves Am 20.11.2011 11:43, schrieb Ralph Dratman: > 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 >> >

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

**Re: Timing graphics in the real world**

**Re: What is the point of having Initializations in DynamicModule and Manipulate?**

**Re: Timing graphics in the real world**

**Re: Timing graphics in the real world**