| 04:01.44 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 04:01.44 | *** join/#brlcad Maloeran (n=rayforce@daddelbande.de) [NETSPLIT VICTIM] |
| 04:36.08 | *** mode/#brlcad [+o brlcad] by ChanServ |
| 06:14.44 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 06:53.04 | *** join/#brlcad SWPadnos (n=Me@dsl245.esjtvtli.sover.net) |
| 07:13.17 | *** join/#brlcad clock_ (i=clock@84-72-94-51.dclient.hispeed.ch) |
| 12:05.33 | *** join/#brlcad docelic (i=docelic@ri02-129.dialin.iskon.hr) |
| 15:37.22 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 15:48.05 | Maloeran | Doh! So that's the threaded prep bug |
| 15:50.57 | ``Erik | heh |
| 15:50.58 | ``Erik | what was it? :D |
| 15:51.04 | ``Erik | bad locking? |
| 15:55.45 | Maloeran | Basically, yes. In some specific circumstances, it was launching jobs that it shouldn't have |
| 16:03.56 | ``Erik | ah |
| 16:18.42 | Maloeran | Finally you'll be able to tell me how the stuff scales, prep and tracing :) |
| 16:21.51 | ``Erik | but I still have to hack the config file to define the # of threads? |
| 16:22.20 | ``Erik | libbu has a function to report # of cores, might as well link against it since eventually it'll be shoved into that package |
| 16:23.50 | Maloeran | The define is in rfdemo.c, not the config.h file. Would be easy to specify that by command line or something |
| 16:24.07 | Maloeran | With glibc, get_nprocs() can be used to get the count of processors |
| 16:25.24 | Maloeran | rtContextEnv( RT_THREAD_COUNT_HINT, threadcount, 0 ) <-- rfdemo.c, specifies the count of threads |
| 18:02.01 | *** join/#brlcad clock_ (i=clock@84-72-94-51.dclient.hispeed.ch) |
| 18:11.19 | ``Erik | not every os has glibc... in fact, I can only think of one that does... |
| 18:11.32 | ``Erik | the libbu one calls get_nprocs() on linux |
| 18:11.38 | ``Erik | performs the right sysctl on bsd |
| 18:11.39 | ``Erik | etc |
| 18:11.47 | ``Erik | works everywhere arl cares about... :) |
| 18:12.18 | ``Erik | (lots of OS abstraction in the BRL-CAD (happy, brlcad?) libraries) |
| 18:31.03 | Maloeran | I get the idea, that belongs outside the raytracing library anyhow, in the rfdemo files |
| 18:35.30 | Maloeran | Neat, you support some exotic platforms in there ;) |
| 18:53.39 | ``Erik | heh |
| 18:53.48 | ``Erik | looking at the old vax/vms stuff? or the cray stuff? |
| 18:54.20 | ``Erik | brlcad cranked up a netbsd install on a vms11/70 I think in simh to make sure the product still works there... a bit extreme :) |
| 18:55.00 | ``Erik | <-- has teh top plate of a pdp11/70 (pre-vax dec hw) on his windows machine... windows make that smoking machine almost as useful as an old pdp11 |
| 18:55.05 | ``Erik | makes |
| 18:58.53 | Maloeran | Eheh, very neat |
| 19:00.25 | Maloeran | I suppose there's no harm in just leaving support for these prehistoric platforms there, you can throw it out if it ever gets in the way |
| 19:01.36 | ``Erik | heh |
| 19:02.35 | ``Erik | and I think that too much code is pitiful and unacceptable in the quality aspect |
| 19:03.04 | ``Erik | take a look at linux kernel code... it's obvious how little thinking was put into portability, and how poorly the hacks to "make it work" here and there are |
| 19:03.22 | ``Erik | if you only ever support the specific platform and architecture, yes, you can make those assumptions. |
| 19:03.40 | Maloeran | Yes, but I would say it's about "making it work fast" |
| 19:03.50 | ``Erik | if you code in that fashion, the second you adjust for another platform, you probably LOSE efficiency as the 'to cope with' hacks get introduced |
| 19:04.04 | Maloeran | It's an operating system kernel, I would sacrifice design portability for performance |
| 19:04.12 | ``Erik | heh |
| 19:04.18 | ``Erik | well, suppose you have two choices |
| 19:04.43 | ``Erik | you can make a generic thing that works everywhere, but it's only 95% as the optimal on your development machine... |
| 19:04.49 | ``Erik | so you implement the 100% optimal |
| 19:04.53 | Maloeran | Linux has big chunks of code for each arch it supports, specifically tailored for the architecture |
| 19:04.54 | ``Erik | now someone else has different hw |
| 19:05.15 | ``Erik | so they put in if(thisarch) {do this} else {dothis} |
| 19:05.24 | Maloeran | Solaris did that, very portable code, and its deserves the Slowaris nickname |
| 19:05.49 | ``Erik | and someone else has different hw, so now it's if(thisarch) {dothis} else if(thisarch) {dothis} else {dothis} |
| 19:05.55 | ``Erik | heh, actually |
| 19:06.03 | ``Erik | solaris was designed to be efficient on usparc |
| 19:06.06 | ``Erik | and nothing touches it there |
| 19:06.11 | ``Erik | 'slowaris' is only for the x86 port |
| 19:06.30 | ``Erik | because it wasn't designed with portability in mind... it was designed for insane efficiency... on a usparc/sbus machine. |
| 19:06.34 | Maloeran | Ah I see. I did read some comparisons between Linux and Solaris code design |
| 19:06.50 | ``Erik | solaris is *VERY* tuned to usparc |
| 19:06.54 | ``Erik | linux is *VERY* tuned to x86 |
| 19:07.02 | ``Erik | the minute you stray from their native environment, they SUCK |
| 19:07.03 | ``Erik | :( |
| 19:07.46 | Maloeran | I thought the Linux kernel had huge blocks of arch-specific code, taillored for performance |
| 19:08.02 | Maloeran | While Solaris had elegant layers of abstractions, making it fairly portable, and slow |
| 19:08.35 | ``Erik | solaris is well architected, but x86 was a half-assed afterthough |
| 19:08.55 | ``Erik | the focus was always the latest line of sun hw |
| 19:09.01 | ``Erik | m68k, then sparc, then ultrasparc |
| 19:09.19 | Maloeran | Well, you know me, I'll sacrifice code elegance for performance any time. For a kernel, it matters a lot |
| 19:09.26 | ``Erik | heh |
| 19:09.37 | ``Erik | in the immediate term, that's acceptable |
| 19:09.44 | ``Erik | in the long term, it's what leads to shit code |
| 19:09.46 | ``Erik | like the linux kenrel |
| 19:09.49 | ``Erik | kernel |
| 19:09.55 | ``Erik | goto hell, jump tables out the wazoo |
| 19:10.02 | ``Erik | hack upon hack upon hack |
| 19:10.04 | ``Erik | it's... sad. |
| 19:10.12 | Maloeran | I wouldn't qualify the Linux kernel of "shit code" |
| 19:10.23 | ``Erik | uh |
| 19:10.24 | ``Erik | if you don |
| 19:10.34 | ``Erik | if you don't, then you hav enot looked at much kernel code. |
| 19:10.48 | ``Erik | seriously, dude, I'm BOGGLED that it works AT ALL |
| 19:11.03 | Maloeran | The parts I read were far better than most other open source code I have seen |
| 19:11.11 | ``Erik | hm |
| 19:11.17 | ``Erik | the networking stack is semi-decent |
| 19:11.25 | ``Erik | the scheduler was just gutted and replaced, it's kinda ok |
| 19:11.42 | ``Erik | memory management, file system, drivers... horrible |
| 19:11.53 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 19:12.10 | Maloeran | Memory management may be "horrible" code-wise, but it's still efficient |
| 19:12.41 | ``Erik | efficient on hw with the i386 mmu |
| 19:12.42 | ``Erik | sure |
| 19:13.02 | Maloeran | Of course so :) |
| 19:13.06 | ``Erik | on an alpha? ppc/sp? mips? sparc? vm? of course not |
| 19:13.16 | Maloeran | There are paths for other architectures, but I haven't read them |
| 19:13.26 | Maloeran | I guess far less work was put on them |
| 19:13.32 | ``Erik | the very *NOTION* that there are other paths |
| 19:13.34 | ``Erik | is a hit. |
| 19:13.37 | ``Erik | :( |
| 19:13.52 | Maloeran | It's a compilation time "path", it's only a hit on the time of the programmers |
| 19:14.04 | ``Erik | of course, the performance related stuff I tend to do tend to be rare runs |
| 19:14.16 | ``Erik | so in computing total cost, developer time is in there |
| 19:14.18 | Maloeran | And since it's a kernel, I'm not against having a whole specific path optimized for each architecture |
| 19:14.26 | ``Erik | well |
| 19:14.43 | ``Erik | if it were defined sufficiently that each arch could be a totally independant project, great |
| 19:15.08 | ``Erik | 99.999% of code A) is not that well defined and B) does not have the resource allotment for each plausible arch/os |
| 19:15.14 | Maloeran | Not independant, most of the code can still be shared, but very distinct modules yes |
| 19:15.30 | ``Erik | independant projects can share |
| 19:15.41 | ``Erik | I mean, if you were in tune to the bsd family... |
| 19:15.54 | ``Erik | freebsd, openbsd, netbsd,and dragonfly are all very much distinct projects |
| 19:15.56 | ``Erik | but share a LOT |
| 19:16.11 | ``Erik | all with different focii |
| 19:16.48 | Maloeran | Well, what can I see, Linux is weaker than alternative on certain architectures. I use the architectures that offer the best performance/cost ratio, as most of the world, and it's ia32/amd64 |
| 19:16.57 | Maloeran | can I say* |
| 19:18.16 | ``Erik | for both administrative effort and for 'well written' code efficiency :/ |
| 19:18.38 | ``Erik | understanding the semantics of the fundamentals helps |
| 19:19.03 | ``Erik | like groking the difference between phkmalloc and dlmalloc |
| 19:19.42 | ``Erik | (phk allocs and frees REAL fast, and guarantees contiguous memory... dlmalloc is just a hair slower on alloc and free, but way faster on realloc) |
| 19:19.55 | ``Erik | bsd is phkmalloc, linux is dlmalloc |
| 19:19.56 | ``Erik | :) |
| 19:20.15 | ``Erik | dlmalloc does *NOT* guarantee contiguous memory, physical pages are all over the place ... |
| 19:20.25 | Maloeran | I thought the BSD free() was a bit slow though, perhaps just aggressive on releasing memory pages |
| 19:21.01 | Maloeran | And the OSX free() sure is terribly slow :), one is better write a wrapper |
| 19:21.33 | ``Erik | like, uh, *nix filesystems fight for contiguous data... where windows is all over teh place... linux wire memory is all over the place (fragmented... assume the process closes before issues happen) |
| 19:21.54 | ``Erik | I think linux and fbsd free memory asynchronously, where osX is synchronous |
| 19:22.18 | ``Erik | when you free on linux and fbsd, sometime, that memory will be available.. eventually... on osX, that memory is available when the function returns. Damnit. |
| 19:22.26 | ``Erik | I'd have to doublecheck to be sure |
| 19:22.31 | Maloeran | Continuity matters for file systems, but for memory? Processors don't really care if two pages are next to each other or not, the translation takes care of that |
| 19:22.40 | ``Erik | um |
| 19:22.48 | ``Erik | most cpu's have a mandatory read-ahead |
| 19:23.06 | ``Erik | so, uh |
| 19:23.06 | ``Erik | if you access memory linearly, it DOES matter |
| 19:23.10 | Maloeran | Yes, and that read-ahead relies on the process address space, not the translated addresses |
| 19:23.24 | ``Erik | hrm, true |
| 19:23.40 | ``Erik | :/ |
| 19:23.51 | ``Erik | wench on the phone, code editor with ruby code up, ... etc |
| 19:24.04 | Maloeran | I guess continuous memory pages would still be better in other circumstances though. DMA'ing to devices and so on |
| 19:24.22 | Maloeran | Eh, all right. I need to go eat breakfast before it closes at 15h anyhow |
| 19:24.43 | ``Erik | hehehe :) |
| 19:25.27 | ``Erik | later, duder |
| 19:43.09 | *** join/#brlcad docelic (i=docelic@ri02-010.dialin.iskon.hr) |
| 21:16.16 | *** join/#brlcad docelic (i=docelic@ri02-226.dialin.iskon.hr) |
| 21:55.36 | *** join/#brlcad sand (n=sand@a88-112-54-131.elisa-laajakaista.fi) |
| 21:55.41 | sand | heya |
| 22:15.33 | brlcad | hello, ...back later... |
| 22:20.29 | sand | what's the licence for brlcad? |
| 22:29.41 | Maloeran | LGPL |
| 22:30.25 | Maloeran | Although some pieces are BSD I think |
| 22:33.53 | sand | cool |
| 22:33.56 | sand | why is it not in debian? |
| 22:33.58 | sand | >P |
| 22:36.00 | Maloeran | No idea. It isn't in Gentoo either, but it's fairly simple to install |
| 22:57.35 | brlcad | sand: only because nobody from those projects has completed the effort mostly -- there are partial efforts in place for both debian and gentoo |
| 23:04.16 | sand | ah |
| 23:59.38 | ``Erik | if a debian or gentoo porter were looking to get it hooked up, we'd naturally offer to help how we can... I do the freebsd port, so I can provide a file listing, etc |