| 00:11.26 | pra5ad | sean |
| 00:11.39 | pra5ad | whats with wendy getting all agitated about g-var |
| 00:12.05 | pra5ad | apparently it was part of a ttm |
| 00:14.36 | ``Erik | ahhhhhh |
| 00:54.16 | animall | stupid question, on make benchmark |
| 00:54.41 | animall | is the output needed for comparison with other systems? |
| 00:58.46 | brlcad | animall: depends, but generally no |
| 00:59.29 | animall | ok |
| 00:59.55 | animall | im taking the source into work tomorrow, ill run it on one of the machines in development |
| 00:59.56 | brlcad | animall: the output is useful to see how stable the numbers are, how rapidly it converges, how many iterations it took |
| 01:00.08 | brlcad | but the summary VGR count is what ultimately matters |
| 01:00.22 | brlcad | and that is both reported in the output and saved in text file named 'summary' |
| 01:00.31 | animall | k |
| 01:00.44 | brlcad | be sure to run ./configure with --enable-optimized --disable-debug for best performance |
| 01:00.44 | animall | ill see how much of a punch quad dual cores can hammer out |
| 01:00.54 | animall | running that now |
| 01:01.13 | animall | hehe, make the engineers freak out |
| 01:01.35 | brlcad | fwiw, 'make benchmark' is installed with brl-cad as a tool named 'benchmark' |
| 01:02.16 | brlcad | what sort of numbers are you getting now? |
| 01:02.35 | animall | 1109.09 843.08 1170.35 933.45 856.26 4.29 819.42 |
| 01:02.57 | brlcad | eek |
| 01:02.57 | animall | single core Celeron D in em64t with 800mhz fsb/ ich5 southbridge |
| 01:03.02 | brlcad | ahh |
| 01:03.27 | brlcad | that must be unoptimized i take it? |
| 01:03.27 | animall | and a vanilla FC5 2.6.16-1 kernel |
| 01:03.31 | animall | correct |
| 01:03.59 | brlcad | the last number there, 819 was the VGR count |
| 01:04.10 | animall | i've still got to update the southbridge and northbridge microcode, DFI fragged up and shipped the wrong mircrocode out on this board |
| 01:04.17 | animall | k |
| 01:04.22 | brlcad | that's a linear metric, so a machine with 800 and another with 1600 means the second is 2x performance |
| 01:04.36 | animall | k |
| 01:05.06 | animall | not too bad for a board/cpu/ram that ran me like $300 |
| 01:05.34 | brlcad | you can get all sorts of interesting results tweaking compilation options, of course too -- default is usually just a handful of non-platform-limiting options geared towards gcc |
| 01:05.36 | animall | next box is going to run around $6K |
| 01:06.20 | brlcad | you can tack on CC and CFLAGS/CPPFLAGS/LDFLAGS to configure and it will carry then through as well |
| 01:06.22 | animall | gcc does have some quirks |
| 01:06.27 | animall | ok |
| 01:06.59 | animall | I havent looked at the code yet, I might later on this summer after I finish some driver upgrades at work |
| 01:07.35 | brlcad | optimized vs default will generally result in about a 2x increase (diff between -O0 and -O3 -ffast-math) |
| 01:07.50 | animall | ok |
| 01:08.10 | brlcad | for gcc at least |
| 01:08.28 | brlcad | icc and mipspro have their own interesting behaviors |
| 01:08.32 | animall | lesson learned on -O3 is that cross platform compiles turn into a blithering mess |
| 01:08.38 | animall | icc is a pain in the butt |
| 01:08.50 | brlcad | heh |
| 01:08.50 | animall | i have to work with it everyday |
| 01:09.06 | brlcad | i like icc's dual-pass optimization mode |
| 01:09.26 | animall | that is good, esp if the system has the correct microcode |
| 01:09.32 | brlcad | gcc has one too, but not nearly as nice (at least not nearly as familiar) |
| 01:10.11 | animall | dual pass in gcc is a bit more of a cpu hog, and on a system with 600+ users for doing development, it has a tendancy to tick off people |
| 01:10.49 | brlcad | 600+ users on a system, eeww |
| 01:11.10 | brlcad | hopefully a 512 processor altix or something |
| 01:11.32 | brlcad | something massive smp at least |
| 01:12.14 | animall | quad xeons with HT |
| 01:12.26 | animall | its due for an upgrade this year though |
| 01:12.46 | brlcad | that's quite a load of users for a system that "small" |
| 01:13.09 | animall | yeah, but it holds the load, mainly for test scripts and compiling code changes |
| 01:13.10 | brlcad | are they not cpu intensive users? I could eat that much up easily on a daily basis |
| 01:13.15 | animall | majority of the load is vim |
| 01:13.19 | brlcad | heh |
| 01:13.35 | animall | mainly its maybe 30 people killing the cpu |
| 01:14.26 | brlcad | so 'only' a load of about 50 all the time ;) |
| 01:16.36 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/TODO: geometry example of building 238 is pushed back |
| 01:21.26 | *** join/#brlcad akin (n=akin5040@85.103.26.204) | |
| 01:21.49 | brlcad | hello akin |
| 01:22.12 | *** part/#brlcad akin (n=akin5040@85.103.26.204) | |
| 01:22.21 | brlcad | goodbye akin |
| 01:27.03 | animall | 1403.47 |
| 01:27.17 | animall | run with optimized |
| 01:27.33 | animall | pretty much about it on the load |
| 01:29.06 | animall | run 3 w/ --disable-debug |
| 01:30.28 | brlcad | that's looking more reasonable |
| 01:31.00 | brlcad | --disable-debug doesn't really give you much except a slight hint of memory coherence |
| 01:31.07 | brlcad | --enable-optimized gives the bang |
| 01:34.31 | animall | freed up some mem also, maybe that will help |
| 01:35.17 | animall | model name: Intel(R) Celeron(R) CPU 2.53GHz |
| 01:35.54 | animall | ive got the same model with dual core waiting an ICH7 board with a i965 northbridge |
| 01:39.49 | brlcad | free'ing up memory shouldn't be a big difference unless you actually needed to swap to exec |
| 01:40.12 | brlcad | the models intentionally are not large to avoid memory paging timings |
| 01:40.42 | brlcad | what will be a factor is L1/L2 cache sizes and register efficiency |
| 01:42.24 | pra5ad | heh bldg 238 |
| 01:42.44 | pra5ad | including the trap doors and croc pit? |
| 01:42.56 | brlcad | but of course |
| 02:20.16 | animall | 1569.93 |
| 02:20.32 | animall | --enable-optimize --disable-debug |
| 02:20.35 | animall | not bad |
| 03:32.22 | *** join/#brlcad digitalfredy (n=digitalf@200.119.94.168) | |
| 03:32.40 | digitalfredy | brlcad: ping |
| 07:30.27 | *** part/#brlcad digitalfredy (n=digitalf@200.119.94.168) | |
| 10:27.50 | *** join/#brlcad DTRemenak|RDP (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 12:36.49 | *** join/#brlcad Erroneous (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 14:13.49 | *** join/#brlcad animall (n=jwmcc@adsl-068-209-088-106.sip.gsp.bellsouth.net) | |
| 15:44.26 | *** join/#brlcad animall (n=jwmcc@adsl-068-209-088-106.sip.gsp.bellsouth.net) | |
| 15:57.20 | *** join/#brlcad rogier (n=rogier@16-65-dsl.ipact.nl) | |
| 18:33.11 | *** join/#brlcad pier (n=pier@151.56.249.2) | |
| 18:34.10 | Maloeran | Question for anyone familar with BRL-CAD and its raytracers, what is the use for VOXELs? Is raytracing support required for scenes that mix triangles and voxels? |
| 20:24.40 | pier | logout |
| 20:29.05 | *** join/#brlcad PrezKennedy (n=Apathy@c-68-33-243-45.hsd1.md.comcast.net) | |
| 20:31.02 | *** join/#brlcad digitalfredy (n=digitalf@200.119.94.123) | |
| 20:31.09 | digitalfredy | brlcad: ping |
| 20:41.11 | brlcad | digitalfredy: pong |
| 20:41.19 | digitalfredy | hello |
| 20:41.28 | digitalfredy | i'm reading your mail |
| 20:42.51 | brlcad | Maloeran: i presume you mean the 'vol' volumetric primitive? |
| 20:45.32 | brlcad | The vol primitive is a basic (mostly unoptimized) volume primitive that supports visualization of cell data like you might get from a CT or MRI scan. implemented for medical visualization primarily, though it has other uses. |
| 20:46.41 | brlcad | not sure what you mean by "is raytracing support required for scenes that mix triangles and voxels" .. BRL-CAD supports raytracing of arbitrary collections of primitives |
| 20:46.46 | brlcad | necessarily has to |
| 20:51.23 | Maloeran | Right. The SOW for developing high-performance raytracing software for BRL-CAD requests support for VOXEL datasets, that was unexpected |
| 22:25.53 | *** join/#brlcad iday (n=iday@c-68-55-177-228.hsd1.md.comcast.net) | |