| 01:37.39 | brlcad | huh? who wha? |
| 01:39.36 | dtidrow_work | lol |
| 01:43.08 | *** join/#brlcad sand (n=sand@a88-112-54-131.elisa-laajakaista.fi) |
| 01:49.14 | Maloeran | Erik, by inserting if(!(rand()&0xFF))sleep(0); in every blank line of the prep in all functions, I'm able to reproduce your bugs |
| 01:49.22 | brlcad | hehe |
| 01:49.50 | dtidrow_work | is somebody being sarcastic? |
| 01:50.06 | brlcad | i think he means it |
| 01:56.02 | Maloeran | Yes I'm serious, nothing less drastic managed to trigger the bug |
| 01:58.58 | dtidrow_work | crazy |
| 02:52.01 | ``Erik | heh |
| 02:53.13 | ``Erik | dti: multithreaded apps that are very cpu bound when running on a single core have a behavior of saturating their quanta (therefore lucking out with exclusive access to the regions that should be locked) |
| 02:53.36 | ``Erik | but the second you bring that app to a machine with multiple cores and caches, shit goes bad... |
| 02:54.17 | ``Erik | sleep(0) just surrenders the quanta, so shoving it in some place "weird" can produce some of the side effects you see from having multiple alu's |
| 03:39.06 | Maloeran | ``Erik, just sleep()s weren't enough, I needed the rand() |
| 03:39.24 | Maloeran | And I needed a whole lot of them saturated all over the code :) |
| 03:40.40 | Maloeran | It should be shortly fixed now, so I can finally move on to... actual work |
| 04:51.41 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 05:38.03 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 06:38.42 | Maloeran | Ah, I just woke up at 2h with the bug in mind and finally understood |
| 06:40.55 | Maloeran | I'll share the explanation tomorrow if you are curious Erik, that was... subtle. Hrm okay, I'll go sleep on the fix now |
| 07:10.33 | *** join/#brlcad clock_ (i=clock@84-72-63-63.dclient.hispeed.ch) |
| 08:01.57 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 08:15.45 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 09:35.40 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 09:56.56 | brlcad | good times |
| 10:23.01 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 11:38.51 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 11:46.33 | *** join/#brlcad clock___ (n=clock@zux221-122-143.adsl.green.ch) |
| 11:59.26 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 12:29.29 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 12:49.25 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 13:04.14 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 13:29.13 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 14:18.36 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 15:25.30 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 15:32.14 | *** join/#brlcad clock___ (n=clock@zux221-122-143.adsl.green.ch) |
| 15:50.19 | Maloeran | Gah, death to gprof with its complete lack of support for both threads and dlopen'ed libraries. Writing a profiler with GCC's -finstrument-functions seems so easy anyway |
| 15:50.53 | Maloeran | Won't be a match for the all mighty Shark, but gprof isn't hard to beat |
| 15:55.13 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 16:15.48 | brlcad | mm.. Shark |
| 16:15.54 | brlcad | shark is sweet |
| 16:22.40 | dtidrow_work | ? |
| 16:22.43 | dtidrow_work | what is it? |
| 16:22.58 | Maloeran | The OSX profiler, amazingly good |
| 16:42.01 | dtidrow_work | ah |
| 16:43.42 | *** join/#brlcad docelic (i=docelic@ri02-209.dialin.iskon.hr) |
| 16:50.10 | brlcad | one of the best profilers around, free or otherwise (and it's free) |
| 16:51.59 | brlcad | part of the apple "CHUD" tools (Computer Hardware Understanding Developer Tools) |
| 16:52.36 | ``Erik | http://www.macworld.com/news/2006/12/12/allchin/index.php |
| 16:52.37 | ``Erik | heh |
| 16:54.17 | brlcad | http://developer.apple.com/tools/shark_optimize.html |
| 16:54.35 | brlcad | and http://developer.apple.com/tools/sharkoptimize.html |
| 16:54.46 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 16:54.49 | brlcad | and one i've not even tried yet.. http://developer.apple.com/tools/performance/optimizingwithsystemtrace.html |
| 16:57.51 | Maloeran | I read posts in mailing lists from 1999 to 2006 about gprof/glibc/kernel people blaming each other for the failures of gprof |
| 16:58.03 | Maloeran | No one agrees on what the "best" way is, so nothing gets done. Lovely! |
| 17:00.12 | brlcad | shark gets a lot of what it gets, erm most, from the system performance counters on the hardware |
| 17:00.25 | brlcad | which while not standard on x86 hardware, is on most newer systems |
| 17:00.37 | brlcad | but still something gprof knows pretty much nothing about |
| 17:01.19 | brlcad | projects like oprofile seem to be doing better at using the performance counters, but still have a ways to go |
| 17:01.20 | Maloeran | Yes I know. All I'm asking for is the sum of the time spent in functions, and I can't get that |
| 17:01.45 | brlcad | oprofile might do that much for you |
| 17:01.52 | brlcad | http://oprofile.sourceforge.net/about/ |
| 17:02.05 | Maloeran | Oprofile is system-wide and it requires a kernel driver |
| 17:02.24 | Maloeran | I didn't look further as it seemed overkill and inappropriate |
| 17:02.32 | brlcad | kernel module, you insmod it |
| 17:02.46 | brlcad | it gives the numbers you want: http://oprofile.sourceforge.net/examples/ |
| 17:03.21 | ``Erik | is shark on the intel chips yet? |
| 17:03.32 | brlcad | years ago afaik |
| 17:04.50 | Maloeran | Hrmph, then it's no good to see the reasons behind the prep's poor scalability |
| 17:05.40 | brlcad | what's no good? |
| 17:06.11 | brlcad | the chud tools have been available on the intel macs since the early beta days |
| 17:06.23 | Maloeran | I mean if Erik can't run it by lack of root |
| 17:06.33 | brlcad | ahh |
| 17:06.49 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 17:07.27 | brlcad | he probably just needs to make a phone call or send an e-mail and that problem could probably go away |
| 17:10.36 | Maloeran | Ahah, about the name of the GNU BFD library : "The name came from a conversation David Wallace was having with Richard Stallman about the library: RMS said that it would be quite hard--David said "BFD". Stallman was right, but the name stuck." |
| 17:12.29 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 17:13.41 | ``Erik | interesting, um, view choices |
| 17:28.17 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 17:34.34 | *** join/#brlcad clock___ (n=clock@zux221-122-143.adsl.green.ch) |
| 17:40.00 | *** join/#brlcad clock____ (n=clock@zux221-122-143.adsl.green.ch) |
| 17:46.24 | Maloeran | oprofile: configure: error: Unsupported kernel version with 2.6.17 |
| 17:47.20 | Maloeran | Enough of this mess, I'll write a profiler in spare time |
| 18:02.09 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 18:32.39 | ``Erik | commitcommitcommit |
| 18:32.42 | ``Erik | ho hum |
| 18:46.57 | *** part/#brlcad sand (n=sand@a88-112-54-131.elisa-laajakaista.fi) |
| 18:50.25 | Maloeran | Are you sure it got enough ram for the truck? |
| 18:50.47 | Maloeran | It doesn't take that much once cached, but the prep climbs high |
| 20:26.48 | ``Erik | just the file |
| 20:27.29 | ``Erik | I'd hope a gig is enough... I mean, yeah, it's a slow old machine, but it's a slow old unix machine, not one of these pissant desktop crappers |
| 20:30.53 | Maloeran | Ah, neat. I'm not qualifying anything with 1gb ram of "crusty old" yet |
| 20:34.15 | ``Erik | hrm |
| 20:34.31 | ``Erik | this machine might be as old as your 486 heh |
| 20:35.22 | Maloeran | Oh :) |
| 20:37.54 | ``Erik | hm, no, I htink it's only 11 yrs old |
| 20:40.30 | ``Erik | hrmmmm, which is about when pc's were in the 8-16mb range |
| 20:40.31 | ``Erik | :) |
| 20:40.43 | Maloeran | It really amuses me to think that back on that 486, I could barely perform 5-6 fast assembly instructions per pixel to get smooth rendering |
| 20:40.58 | Maloeran | Now, tracing a ray for every pixel against 260k triangles? Ah, no problem |
| 20:41.10 | ``Erik | heh |
| 20:41.25 | ``Erik | you should install 'vice' and code on that some :) I learned a lot on a c64 |
| 20:41.59 | ``Erik | 'kernel' hacking, even, writing mnems (halfway between straight machine code and asm) and pointing the interrupt vector to my new code |
| 20:42.46 | Maloeran | I love optimisation but I'm not too fond of OS stuff. I had written a primitive 32 bits DOS on that 486 |
| 20:43.05 | Maloeran | It could run *some* DOS software within a very primitive multitasking 32 bits OS |
| 20:45.36 | Maloeran | I still keep pieces of old code... Hum, my old DOS isometric tile rendering engine with lighting optimized in assembly for 486/Pentium, I got to read that again sometimes |
| 20:46.05 | Maloeran | :( How so, why? |
| 20:46.13 | ``Erik | was moving several thousand miles |
| 20:46.29 | ``Erik | so dumped a lot of unnecessary possessions |
| 20:46.30 | Maloeran | Well, disks, you can at least bring that |
| 20:46.49 | ``Erik | yeah, but without the drives and computers, they're useless |
| 20:47.40 | Maloeran | The time I lost most of my code was when my father "threw" me out of the house for quitting college, many years ago |
| 20:47.47 | ``Erik | (back then, not only did every os have its own filesystem, but the very nature of disk layout was different bewteen machines and needed their own drives) |
| 20:48.19 | ``Erik | so even if you wrote an appleII or dos program to read a c64 fs, it'd still just get garbage off of the media |
| 20:48.42 | Maloeran | Really? I thought it was possible for some drives, not x86 floppy drives though |
| 20:48.45 | ``Erik | I've seen some hacks for making hw do unnatural things like that, yeah |
| 20:49.03 | ``Erik | but *shrug* hadn't when I pitched the machines... |
| 20:49.24 | ``Erik | yard sale, actually, didn't throw them out, heh |
| 20:49.32 | ``Erik | my mom sold 'em :/ |
| 20:49.36 | Maloeran | You didn't bury them in the woods and marked down the gps coodinates or anything? :) |
| 20:49.40 | Maloeran | Ew. |
| 20:52.30 | Maloeran | Ah, old good times on that 486... Adding one fast assembly instruction per pixel could reduce performance by some 20%, that was amusing optimisation |
| 21:08.09 | *** join/#brlcad docelic (i=docelic@ri02-067.dialin.iskon.hr) |
| 21:49.41 | *** join/#brlcad clock_ (i=clock@84-72-95-205.dclient.hispeed.ch) |