Re: Timing graphics in the real world
- To: mathgroup at smc.vnet.net
- Subject: [mg123009] Re: Timing graphics in the real world
- From: Ralph Dratman <ralph.dratman at gmail.com>
- Date: Sun, 20 Nov 2011 05:37:12 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <201111191145.GAA18886@smc.vnet.net>
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 >
- Follow-Ups:
- Re: Timing graphics in the real world
- From: Ralph Dratman <ralph.dratman@gmail.com>
- Re: Timing graphics in the real world
- From: Oliver Ruebenkoenig <ruebenko@wolfram.com>
- Re: Timing graphics in the real world
- References:
- Timing graphics in the real world
- From: Ralph Dratman <ralph.dratman@gmail.com>
- Timing graphics in the real world