Re: Timing graphics in the real world

*To*: mathgroup at smc.vnet.net*Subject*: [mg123074] Re: Timing graphics in the real world*From*: Ralph Dratman <ralph.dratman at gmail.com>*Date*: Tue, 22 Nov 2011 05:37:12 -0500 (EST)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <201111201037.FAA01197@smc.vnet.net>

drawSolidCube[] displays an aggregate of Mathematica Cubelet objects of various colors, placed at integer coordinates in 3D. The volume of the overall cube could be 8, 27, 64 and so forth. I use this to portray the results of integer functions and operators. Usually the smallest size I use is 4x4x4 cubelets. That is drawn quickly enough to watch successive iterations. I have tried sizes up to 30x30x30. Naturally it does get slow with 27,000 cubelets. But drawing should still be reasonably fast at 16x16x16, given the state of today's technology. Tech support at Wolfram tells me a fast graphics card is what I need. There are a great many of them on the market, at a wide range of prices. You can spend $40 or $4,000. (Finally I understand the gamer's obsession with chips, clock speeds and cooling.) While I figure out which card to get, I am looking for software that might render at higher speed, maybe on a second computer. I have also tried a simple projection from 3D into 2D, drawing the result with scaled squares instead of cubelets. That was interesting to construct with Mathematica's tools, but it did not improve the drawing speed. Ralph Dratman On Sun, Nov 20, 2011 at 6:48 AM, Oliver Ruebenkoenig <ruebenko at wolfram.com> wrote: > > > On would need more information on what drawSolidCube[] is? Usually, > GraphicsComplex is efficient. > > Oliver > > > On Sun, 20 Nov 2011, Ralph Dratman 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> wrot= e: >>> >>> 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 trie= s. >>>> 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**:**Re: Timing graphics in the real world***From:*Ralph Dratman <ralph.dratman@gmail.com>

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

**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**