| 00:07.55 | brlcad | mac-: there is fairly extensive introductory material on the main website: http://brlcad.org |
| 00:08.17 | mac- | ok |
| 00:08.21 | brlcad | ah, oop.. thx louipc :) I should finish reading first.. |
| 00:08.28 | mac- | do you know any good CAD for Linux ? |
| 00:09.17 | brlcad | er, you mean other than brl-cad? |
| 00:09.26 | mac- | for drafting |
| 00:09.33 | brlcad | ah.. CADD |
| 00:09.38 | mac- | similar to AutoCAD |
| 00:10.06 | brlcad | the only readily available one is qcad |
| 00:10.22 | mac- | uhm |
| 00:10.43 | brlcad | (free at least) |
| 00:10.50 | mac- | i downloaded GraphiteOne, but i couldn`t launch it |
| 00:10.51 | brlcad | and with any production quality |
| 00:11.19 | mac- | and their support hasn`t reply for my questions |
| 00:12.47 | brlcad | ah, I don't follow the commercial products that closely, even less those specific to drafting, even further less those that aren't open source |
| 00:13.05 | brlcad | (sorry, just not our concern/interest) |
| 00:13.21 | mac- | ok |
| 00:13.24 | louipc | I saw one called FreeCAD on sourceforge, I haven't tried it yet |
| 00:13.57 | brlcad | freecad is mildly useful, but they're even farther from production quality than qcad |
| 00:14.03 | louipc | ouch |
| 00:14.55 | brlcad | it just really takes too much time to build up the foundation for a CAD or CADD or CAM system to achieve production quality for generalized use |
| 00:15.12 | brlcad | might find a tool or two specialized |
| 00:15.56 | brlcad | but freecad and qcad and pythoncad and others try to cater to common audiences, and have a excessively major hill to fight |
| 00:17.18 | louipc | yeah definitely |
| 00:17.44 | brlcad | that's one of the aspects where brl-cad shines -- even if you remove mged and the gui, there's roughly 100+ man-years of development |
| 00:18.40 | dtidrow_work | and at least 25 real years of development behind it |
| 00:18.59 | louipc | do you think you can achieve a professional level GUI with tcl/tk? |
| 00:32.04 | ``Erik | given the # of gui's professionally developed in tcl/tk... probably... |
| 00:46.17 | brlcad | louipc: you can, and even brl-cad's archer shows a lot of what is possible in terms of a better gui more in line with several of the professional system interfaces |
| 00:46.37 | brlcad | that said, our next generation gui probably won't be in tcl/tk |
| 00:53.56 | bjorkBSD | but ... i thought brl-cad *was* professional! |
| 00:54.21 | bjorkBSD | brilly wears a uniform no? |
| 01:00.38 | brlcad | a professional-quality gui? no, that's one of the things it does lack .. in production professional use with professional-quality engine facilities, yes |
| 01:02.23 | bjorkBSD | what will the next gui be in? |
| 01:03.54 | bjorkBSD | in the beginning was the CL, and lo, man took one look at the CLI and thought it was bad. and man created the mouse to eat the CL but verily verily i say unto ye, the CLI served as a useful barrier to entry and kept the waifs away :D |
| 01:08.40 | louipc | @brlcad what are you considering for the next GUI? |
| 01:10.14 | louipc | bjorkBSD: hehe I find the CLI can actually be more efficient if you know what you're doing, and it is well designed |
| 01:12.11 | bjorkBSD | yeah. i hear vista's reintroduced it :D |
| 01:12.38 | bjorkBSD | as far as command line completion goes. |
| 01:12.54 | louipc | oh tab completion? |
| 01:13.15 | bjorkBSD | something like that. i saw it in a youtube video |
| 01:13.36 | louipc | I've heard bad things about vista, and not from windows users nonetheless |
| 01:13.37 | bjorkBSD | ... they've had it in iexplorer for ages, but it seems it's use has been broadened. |
| 01:14.21 | louipc | I tried XP because a linux user said it was the best thing since 3.1 or something. That didn't last for me hah. |
| 01:14.32 | louipc | bad things... *and from windows users... |
| 01:14.46 | louipc | typo |
| 01:14.50 | bjorkBSD | hehe |
| 01:15.08 | bjorkBSD | i have a windows partition i reboot to every now and then. |
| 02:21.32 | *** join/#brlcad bobbens (n=bobbens@84.16.237.134) |
| 04:44.31 | Maloeran | Could anyone tell me what's the common memory and processing models within HPC clusters? I received from a non-programmer by email information that conflicts with my assumptions |
| 04:44.39 | Maloeran | Keywords to wikipedia would do too |
| 04:46.16 | *** join/#brlcad PrezKennedy (n=Matthew@c-69-138-68-160.hsd1.md.comcast.net) |
| 06:36.10 | brlcad | louipc: the CLI is not going away in the least and would actually be more a part of the foundation to the interface (e.g. anything you could do in the gui would be exposed on the cli and vice-versa) |
| 06:39.55 | brlcad | it would be just more of a focus on designing a gui that actually works, is efficient, more consistent, is readily pluggable, and not nearly as much of a bear to maintain/improve as mged's is |
| 06:41.41 | Maloeran | Nevermind the question about cluster processing, Mark had some... weird ideas on the topic :) |
| 06:43.43 | brlcad | most custom designs in general with data localized/replicated in-core or is spread across some out-of-core storage and loaded as needed |
| 06:48.24 | brlcad | most don't have shared process spaces or shared address spaces, but often have shared storage (but not always) so it usually boils down to whether disk memory is sufficient or whether to optimize replicaton/distribution over some communication pipe like tcp sockets, mpi, pvm, etc |
| 06:49.30 | Maloeran | Shared address spaces, that exists? |
| 06:49.44 | Maloeran | It goes against all I know, but it was what Mark apparently assumed |
| 06:50.42 | brlcad | there's a few systems that do, some experimental, some more production |
| 06:51.54 | Maloeran | Woah... but.. |
| 06:52.38 | Maloeran | If the memory address space is shared, it must be a single system made of multiple processors ; you have one memory bank |
| 06:53.07 | Maloeran | It wouldn't be too reasonable to get a page fault for every memory access and synchronize with other processing nodes constantly |
| 06:53.35 | brlcad | not necessarily -- the kernel is simply written/geared towards managing the memory |
| 06:53.51 | brlcad | that's the whole idea around single shared image systems in general |
| 06:54.03 | brlcad | mosix is probably the most popular/common one that you might have heard about |
| 06:54.06 | brlcad | or openmosix |
| 06:54.19 | brlcad | ahh, here's some references http://en.wikipedia.org/wiki/Single-system_image |
| 06:54.35 | Maloeran | I really don't see how this could possibly work |
| 06:55.07 | Maloeran | The only way for the kernel to know what memory is being modified or accessed is to trigger page faults |
| 06:56.18 | brlcad | they do work ;) |
| 06:56.27 | brlcad | to varying degrees of coolness |
| 06:56.33 | Maloeran | Do you have any idea how, briefly? |
| 06:56.44 | brlcad | mosix gets away with it by simply migrating processes to balance load |
| 06:56.45 | Maloeran | How can they track what's being read or written to synchronize the data? |
| 06:56.58 | Maloeran | Yes, they can migrate processes, but they won't share address space |
| 06:57.09 | Maloeran | You couldn't get shared memory between processes |
| 06:57.15 | brlcad | right, that's why they're only a partial SSI |
| 06:57.42 | brlcad | there is still one shared address space, but it's no bigger than the smallest single system's available memory |
| 06:58.07 | brlcad | which isn't entirely true .. but a simple enough simplification |
| 06:58.13 | Maloeran | How can they possibly synchronize that memory? |
| 06:58.57 | brlcad | they don't really need too -- the process moves with it's memory |
| 06:59.49 | Maloeran | Yes, yes, moving processes around is fine. Now, let's say you have process A on the box M and process B on the box N. The two processes have 160mb allocated as shared memory which they use to communicate |
| 07:00.14 | Maloeran | How are they going to manage and synchornize that memory between the two nodes? |
| 07:00.53 | brlcad | that's the entire question behind just how do you do SSI |
| 07:01.00 | brlcad | each of those ssi projects goes about it a different way |
| 07:01.05 | *** join/#brlcad clock_ (i=clock@84-72-63-172.dclient.hispeed.ch) |
| 07:01.22 | Maloeran | I see no other way than constant page faults, which would make performance crawl |
| 07:01.25 | brlcad | some are compiler mods coupled with specific kernels that are fed information about memory access |
| 07:01.55 | brlcad | just because you can't imagine it doesn't mean someone else hasn't :) |
| 07:02.14 | Maloeran | I know that, but I'm asking how it works! :) I guess I should do some reading |
| 07:03.24 | brlcad | well, you might also be thinking shared memory == shared address space and it doesn't |
| 07:03.33 | brlcad | at least not necessarily |
| 07:04.07 | brlcad | whether you even can write C code on a lot of those systems is not possible -- some are very customized academic projects |
| 07:04.24 | Maloeran | brlcad, the box M needs to "know" when the process A writes within the shard memory, so it can update it on box N |
| 07:05.00 | Maloeran | Okay, Mosix doesn't support shared memory |
| 07:05.07 | brlcad | with shared memory -- sure, and there's ways a kernel could be written to propagate that |
| 07:05.19 | brlcad | yes, mosix doesn't |
| 07:05.59 | brlcad | it does process migration in a unified process address space |
| 07:05.59 | Maloeran | The kernel must be told by the processor that writes occur to begin with ; that implies a page fault |
| 07:06.29 | brlcad | implies a "fault" of some sort .. whether memory is managed in pages is an assumption in itself |
| 07:06.55 | brlcad | whether that maps to hardware fault is yet another |
| 07:07.33 | Maloeran | Right, of course so. What I'm trying to say is that page faults, specifically assuming ia32/amd64 hardware, would cripple performance |
| 07:08.08 | brlcad | i believe openssi actually does shared memory across a unified address space |
| 07:08.17 | brlcad | though I haven't looked into how they actually achieved it |
| 07:09.04 | brlcad | hey, you can't get it all for free -- if you're going to be accessing memory across a network link, performance is going to be crippled no matter how creative you get |
| 07:10.05 | brlcad | i mean you're talking the difference of a couple clock cycles to a few nanosecs at best |
| 07:10.34 | brlcad | which is of course...several orders |
| 07:10.49 | brlcad | the fact that it'll even do it (and do it automatically) is what's amazing |
| 07:11.12 | brlcad | just getting it to work at all has been something groups have been working on for longer than I've been alive :) |
| 07:11.19 | Maloeran | I'm asking this because Mark had the assumption that clusters could share memory address space, running threads over the processing network, which is of course incorrect |
| 07:11.34 | Maloeran | But I thought there could be some weird cluster architecture I wasn't aware of |
| 07:12.04 | brlcad | nobody does individual thread-level yet afaik .. even mosix only does process-level |
| 07:12.16 | brlcad | though openssi does thread-group migration iirc, one step closer |
| 07:12.59 | Maloeran | I don't know if it's really amazing, it's absolutely horrible by design :) |
| 07:13.21 | brlcad | openssi might be what he was thinking .. or mosix for that matter and he really just meant unified address space instead of shared and running processes over the network instead of threads |
| 07:13.38 | brlcad | horrible?? |
| 07:13.58 | Maloeran | If you want to distribute processing over a network, just write the software as such |
| 07:14.18 | brlcad | some of those systems are nearly optimal for doing exactly that |
| 07:14.18 | brlcad | with zero effort on your part |
| 07:14.53 | Maloeran | Without shared memory, I still need to handle I/O between processes, I haven't gained anything |
| 07:15.39 | brlcad | perhaps, or maybe you have an application that is already well-designed to not have that assumption or need for interprocess communication |
| 07:15.59 | brlcad | you're making a ton of assumptions about what matters, assumptions that don't hold for a lot of cases |
| 07:16.37 | Maloeran | Right, I should clarify : I'm thinking about distributed processing for a single problem, not running 100 distinct processes |
| 07:17.09 | brlcad | it also depends on the nature of the problem itself of course |
| 07:17.38 | brlcad | if you have a problem that can be independently parallelized, it can likely also be independently distributed seamlessly |
| 07:18.10 | brlcad | (with a given architecture (software and hardware) |
| 07:18.25 | Maloeran | True, but then there isn't much to gain from "apparently" running the 100 processes "locally" rather than booting them on the 100 boxes. It's a bit easier to manage surely |
| 07:18.56 | brlcad | whether there's much to gain depends on the problem too :) |
| 07:19.03 | brlcad | something short-lived, yeah, not much gain |
| 07:19.15 | brlcad | something like the life of your rays, yeah not much gain |
| 07:19.32 | brlcad | something that took minutes/days/weeks to process.. it'd be incredibly useful |
| 07:19.37 | Maloeran | I see the point but it's really a matter of convenience, an user could start the processes on the other boxes "manually" too |
| 07:19.57 | brlcad | sure, but then I could have done that anyways.. |
| 07:20.12 | brlcad | the point of the cluster is to do that stuff for you with the least effort |
| 07:20.46 | brlcad | sometimes that least effort is by custom coding or using mpi or it's by going with a different cluster architecture that does things for you |
| 07:20.56 | Maloeran | Right, so it's a matter of convenience, I realize that |
| 07:21.04 | brlcad | most of the popular (massive) clusters don't do SSI |
| 07:21.17 | brlcad | i think HP's cluster tech does, but nobody else |
| 07:21.34 | brlcad | everyone else predominantly is geared towards mpi |
| 07:23.07 | brlcad | that's what the network cards are optimizing for, the network stacks, etc.. if you want to efficiently scale up to 10k processors and not have to worry (as much) about bottlenecking yourself with interprocess/thread communication, mpi can help (even as heavy as it can be otherwise) |
| 07:24.15 | Maloeran | Yes, MPI is a neat abstraction layer, I won't contest that :) |
| 07:24.58 | brlcad | course if your problem can take advantage of 10k processors or even 1k easily.. then there's not much advantage to be had by the alternative of custom coding some network layer yourself to avoid mpi's (variable) overhead .. even a "2x" savings on something that takes two weeks to compute isn't that interesting |
| 07:26.25 | brlcad | because those are generally problems that are entirely intractible/unfeasible/useless on smaller supercomputers |
| 07:27.44 | brlcad | it's still "at least a couple years" out before I'll be able to do a full-blown fluid dynamics simulation on a dual quad-core workstation to say the least.. ;) |
| 07:28.16 | Maloeran | :) Seems I'll have a chance to try that out soon |
| 07:28.50 | brlcad | full-blown valid-physics down to something like millimeter accuracy at least |
| 07:29.01 | Maloeran | I have only read documentation and code about MPI, I'll try to move on from TCP/IP soon |
| 07:29.23 | brlcad | there are tons of simplifications that can be made on an fluid problem to get them to work on workstations already |
| 07:29.51 | Maloeran | I'll probably get to rewrite SURVICE's fire simulation soon ( fluid dynamics ), it's really filled with simplifications |
| 07:29.53 | brlcad | MPI isn't "great" .. it's been so painful to achieve adoption because the API is a pita |
| 07:30.36 | brlcad | but it's like democracy .. it's not great, but it's the best to have been conceived, adopted, and popularized to date |
| 07:30.37 | Maloeran | The API of MPI seemed appropriate for its purpose... I may think differently when I get to use it |
| 07:30.48 | brlcad | it's gotten tons better |
| 07:31.43 | Maloeran | I was baffled by how slow SURVICE's fire modelling was, especially when I heard how much they simplified the problem. Never let engineers write code, in Fortran 77 too |
| 07:37.52 | Maloeran | If I may, how much is there to lose by using MPI over more tailored specific solutions, for software running on 1-4 nodes or so? |
| 07:52.58 | brlcad | mpi for 1-4 nodes is frankly pointless -- that could just as easily be a command line option for that few nodes |
| 07:55.06 | brlcad | --run-on="node1, node2, node3, node4" etc.. fork a master than remote execs to the nodes or something else .. heck of a lot simpler code and trivial to manage the communication between them without worring about a major bottleneck |
| 07:56.42 | brlcad | it's only once it's over like 16 that it starts to get "hard" imho and things start to matter |
| 07:57.38 | brlcad | how much you loose depends on lot on how many MPI calls you make and how much interprocess/thread communication is going on (which you generally want to minimize of course as much as possible) |
| 07:58.59 | brlcad | compared to strait-up custom tcp, I've seen the mpi overhead be as low as only a couple percent to being a couple hundred |
| 08:00.05 | brlcad | the main benefit of course being that tcp was easy to write for smaller counts of nodes .. but quickly doesn't scale for larger and larger node counts where mpi scales considerably better and doesn't have to be maintained/debugged/tweaked |
| 08:45.18 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 14:04.08 | *** join/#brlcad docelic (n=docelic@212.15.185.210) |
| 15:30.07 | Maloeran | Thanks for the reply, brlcad, I was asleep by then |
| 15:39.28 | ``Erik | mal: have ya read up on 'numa'? |
| 15:39.52 | Maloeran | Sure, some time ago |
| 15:40.39 | ``Erik | hrm, didja forget it? :D (given your conversation before you went to bed, I'd assume...) |
| 15:40.53 | Maloeran | We should store a whole copy of geometry and graphs per memory bank, and have specific threads access it... but I haven't read about the software interfaces to do so |
| 15:41.15 | ``Erik | it's a cluster form with a unified memory space on several independant nodes, each with its own cpu and memory... |
| 15:41.16 | Maloeran | The discussion wasn't really related to NUMA, it was about distributed processing over multiple nodes |
| 15:42.10 | Maloeran | The count of processors in such a design is kept very low, is it not? Up to 16 for an octo-dual-opteron |
| 15:42.24 | ``Erik | an altix is a numa cluster of small single cpu ia64 machines using sgi's numalink to get unsucky bandwidth between 'em and a hacked up suse to handle processor and memory affinity |
| 15:43.15 | Maloeran | That's one single machine though, not a cluster |
| 15:43.23 | ``Erik | no, it's a cluster |
| 15:43.51 | ``Erik | if I walk up to one, it's a bunch of seperat 2u machines, I could pull the numa cables off the back, put in a hard drive and install an os on that one machine |
| 15:44.21 | ``Erik | http://www.gup.uni-linz.ac.at/information/hardware/altix350_front.jpg |
| 15:44.24 | Maloeran | Do opteron clusters work the same way? |
| 15:45.15 | ``Erik | it doesn't matter what the cpu is, it depends on the kernel and interconnect (using something like ethernet would make it absolutely horrible) |
| 15:46.04 | Maloeran | So the Opteron clusters Mark spoke of do have an unified memory space? |
| 15:46.06 | ``Erik | the opteron clusters I have are not numa, they're regular ethernet tcp/ip nodes, each with independant kernels that don't try to assume anything about eachother, and a single disk attachment |
| 15:46.16 | ``Erik | I don't know which clusters mark spoke of... :) |
| 15:46.56 | Maloeran | So opteron clusters do exist having a global memory address space by NUMA? |
| 15:47.32 | ``Erik | I would be surprised if they didn't *shrug* like I said, what cpu it is and NUMA are unrelated |
| 15:48.35 | ``Erik | I could take a stack of old 486's running 10baseT and hack up a numa kernel for 'em... it'd suck, but it's doable |
| 15:48.39 | ``Erik | or, heh, numaPIC :D |
| 15:48.50 | Maloeran | It's certainly not running on a standard motherboard then! |
| 15:49.05 | ``Erik | sure it is... numa is a kernel hack |
| 15:49.32 | Maloeran | NUMA is a hardware solution |
| 15:49.32 | ``Erik | ok, if you miss on level1 cache, it goes to level3... if it misses there, maybe it goes to memory... if it misses there, it goes to swap, right? |
| 15:49.51 | Maloeran | That's not a kernel solution until it misses memory and trigger a page fault |
| 15:49.52 | ``Erik | shove 'other nodes' inbetween memory and swap, that's numa |
| 15:50.03 | ``Erik | no, numa is a kernel hack that lets you fake unified memory |
| 15:50.08 | ``Erik | NUMALink is a hardware solution |
| 15:50.09 | Maloeran | A page fault per memory access is not practical |
| 15:50.22 | ``Erik | yeah it is, IF you have a low latency interconnect |
| 15:50.36 | ``Erik | which is what NUMALink is... sgi's proprietary interconnect, designed with numa archs in mind |
| 15:51.01 | Maloeran | You would spend 50000 times the processing time of *one* memory-accessing instruction to handle that page fault! |
| 15:51.08 | ``Erik | ib and myra could probably do it semi-decently if your kernels scheduler was very aware of affinity |
| 15:51.40 | ``Erik | the trick is that migrations are minimized... if a processor is happily using 1 node, it'll try to keep it on that node... |
| 15:51.56 | ``Erik | if two apps are sharing memory, it'll bias towards running both of those on that one node |
| 15:52.50 | ``Erik | (and accessing another nodes memory, if you're using a decent interconnect (like NUMALink for the altix) may be an order of magnitude slower than local memory, but is several orders better than swap |
| 15:52.52 | ``Erik | ) |
| 15:53.16 | Maloeran | I see, so it does work by page faults |
| 15:53.42 | ``Erik | if the underlying arch does, I'd imagine it'd have to |
| 15:54.15 | Maloeran | NUMA as implemented in an Opteron system is really fast, memory banks bound to other processors are just a bit slower if the hypertransport link is not saturated |
| 15:54.19 | ``Erik | (also; a common use of supercomputers isn't to run one really really big app, but to run a bunch of sorta big apps) |
| 15:54.27 | Maloeran | That's usually what I refer to by NUMA |
| 15:54.59 | ``Erik | you're talking about hypertransport and how it can facilitate numa, not numa |
| 15:55.12 | ``Erik | hypertransport is just a fast interconnect... |
| 15:55.40 | ``Erik | if the kernel is stupid about using it, it'll 'page fault' through to the other cpu's memory banks frequently... no? |
| 15:56.00 | Maloeran | No, it doesn't page fault |
| 15:56.04 | Maloeran | It's a hardware solution :) |
| 15:56.19 | ``Erik | ok, *shrug* then they have both in hw |
| 15:56.26 | Maloeran | The hardware physically routes queries to the memory of other processor banks |
| 15:56.38 | ``Erik | on an sgi altix, afaik, it's a fault and request... and surprisingly fast |
| 15:56.50 | ``Erik | on mosix, it's a fault and request... and depends on the interconnect |
| 15:57.15 | ``Erik | hum |
| 15:57.35 | ``Erik | so it's an mmu hack that requires use of the hw 'task' vectors? |
| 15:57.49 | ``Erik | <-- not versed in hypertransport, is old :) |
| 15:58.33 | Maloeran | The pages are assigned to other memory banks, I guess it's managed as such by the MMU |
| 15:59.10 | ``Erik | well, you have to manage the memory location by task... if the hw does that, you have to tell the hw when you're in a certain task... |
| 15:59.17 | ``Erik | (task as in intel speak for process) |
| 15:59.20 | Maloeran | It's just one big memory bank really, it's just that processors are faster to access their local one |
| 16:00.33 | ``Erik | (as in hypertransport, not hyperthreading) |
| 16:01.30 | ``Erik | hm, works on packets that're either flagged "posted" (for uma and dma) or "nonposted" (for numa)... |
| 16:08.25 | Maloeran | Perhaps proper management of the memory banks, DMA? |
| 16:09.11 | ``Erik | not sure, lots of bit manipulation, probably to make the bank/process association to retain coherency |
| 16:10.06 | ``Erik | linux has a metric assload more than fbsd, mebbe that's why the single process run on a linux opteron outran the same run on a fbsd opteron |
| 16:10.59 | ``Erik | ooh, damnit, now I wanna do kernel hacking to improve the cpu and memory affinity on that quad opteron |
| 16:11.28 | dtidrow | heh |
| 16:11.37 | Maloeran | I can't believe a NUMA system which would page faults for every access, requesting the data before resuming the instruction, could perform comparably to software fetching the data in advance as one big chunk |
| 16:11.39 | ``Erik | stupid raytracer crap |
| 16:12.00 | ``Erik | well, the "page fault" may not call a cpu interrupt, it may be completely hw abstracted and fast *shrug* |
| 16:12.48 | ``Erik | but the os still has to manage the mmu *shrug* it may just be that the interconnect keeps a duplicate copy of the kernels notion of what memory resides where |
| 16:13.10 | Maloeran | I see. |
| 16:14.41 | ``Erik | (per ghz, opteron running 85k rays/sec, g5 at 45k, ia32 at 18k... damn) |
| 16:15.57 | ``Erik | (well, one opteron was 85k, the other was 60k... r12k was 31k, usII was 30k, ia64 at 41k) |
| 16:16.19 | Maloeran | librt this is? |
| 16:16.23 | ``Erik | ja |
| 16:16.49 | ``Erik | the 64 intel amd64 (used to be called EMT or something?) came in at 25k |
| 16:17.24 | ``Erik | oh, with the ia32, 18k for linux, 32k for fbsd... |
| 16:17.58 | dtidrow | in other words, librt is optimized for fbsd |
| 16:18.06 | ``Erik | these are all 'per ghz' on machines with radically differnet cpu speeds and no attention paid to bus speeds or anything, btw |
| 16:18.22 | ``Erik | well, on the opteron, linux came in at 85k where fbsd was 60k |
| 16:18.58 | dtidrow | guess linux has the better memory management inplementation on opteron |
| 16:19.05 | ``Erik | makes me think that it's not an artifact of librt being optimized one way or another, but the OS... amd64 is immature on amd64, but kickin' on ia32 |
| 16:19.27 | dtidrow | fbsd, you mean? |
| 16:19.35 | ``Erik | I think the memory mgmt is all an upfront hit with pools being used, ... |
| 16:19.37 | ``Erik | er, yeah, sorry |
| 16:19.52 | ``Erik | amd: linux>fbsd. ia32: fbsd>linux. |
| 16:20.18 | dtidrow | heh, another reason for me to get AMD :-) |
| 16:20.36 | dtidrow | anyway gotta head in to work - later all... |
| 16:20.41 | ``Erik | later, dude |
| 17:23.23 | *** join/#brlcad bobbens (n=bobbens@84.16.237.134) |
| 18:51.46 | ``Erik | numa is an abstract idea, not a specific implementation... |
| 19:31.44 | Maloeran | Oh hrm. Erik, I briefly mentionned we debated cluster architectures in an email, and he asks, what's your "recommendation"? :) |
| 19:32.02 | Maloeran | I guess he means TCP/IP vs MPI vs NUMA-aware pthreads |
| 19:32.21 | Maloeran | In the context, "he" being Mark |
| 19:36.52 | brlcad | numa-aware pthreads is generally part of single-image systems, not clustering .. otherwise saying "red vs blue vs duckies" |
| 19:37.52 | Maloeran | Altix clusters, for example, have an unified address space though, which means that NUMA-aware threads could reasonably work |
| 19:39.36 | brlcad | there are massive altix smp and clusters of massive altix smp |
| 19:40.14 | brlcad | the clusters don't have a unified address space, altix is cool because it's smp and not a cluster in itself |
| 19:40.51 | Maloeran | All right, that clarifies the definitions. So it's a 512 processors SMP NUMA system |
| 19:41.07 | brlcad | yes |
| 19:41.51 | brlcad | and that'll be quite a price tag at that size to say the least |
| 19:42.02 | ``Erik | <PROTECTED> |
| 19:42.26 | brlcad | pretty much only find those systems at HPC assets (which ARL does happen to have, the MSRC) |
| 19:42.34 | ``Erik | altix is numa, not smp... |
| 19:42.50 | brlcad | altix is numa and smp |
| 19:43.14 | ``Erik | meh, numa is a memory layout, not a cpu scheduling layout, so *shrug* |
| 19:43.59 | ``Erik | but duckies, ... duckies are awesome |
| 19:44.06 | ``Erik | (ever watch 'ze frank'?) |
| 19:44.12 | brlcad | daily ;) |
| 19:44.29 | brlcad | ze frank |
| 19:44.38 | brlcad | ze frank is pretty awesome |
| 19:45.15 | ``Erik | it's on my daily list, too, along with sbemail and the comic page and smacksnot |
| 19:46.01 | archivist | hmm smacks not or smack snot |
| 19:46.18 | ``Erik | smack snot |
| 19:46.25 | ``Erik | aka crack rock |
| 19:46.40 | ``Erik | sometimes slashdot, by the unitiated or sufficiently confused |
| 19:50.14 | brlcad | Maloeran: maybe watch some of these for starters: http://www.zefrank.com/theshow/ then click on "popular shows" on the left |
| 19:50.54 | ``Erik | heh, then blow a solid week watching the entire archive *cough* O:-) |
| 19:51.21 | archivist | I wont be able to read slashdot without the thought smack snot going through my head now |
| 19:51.42 | ``Erik | *bow* |
| 19:52.03 | ``Erik | that's a good thing, right? you'll be able to do something productive, instead? |
| 19:52.28 | archivist | wot hell no |
| 19:54.23 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/misc/Makefile.defs: punty "depends" target |
| 19:59.52 | ``Erik | nothing :) |
| 20:00.00 | ``Erik | there'll be a bigarsed commit in a few |
| 20:00.19 | brlcad | hrm |
| 20:00.22 | ``Erik | but, as the regex.h issue remains, my testing of it is incomplete |
| 20:01.09 | ``Erik | I don't think tcl's regex stuff can be easily removed, it looks like it's use in the symbol resolving functions, as well as in the file routines |
| 20:03.38 | brlcad | i didn't mean remove the regex code, just the files themselves -- or do you mean they're #including .c files or something? |
| 20:04.03 | ``Erik | <-- finds himself going into dirs in the appropriate dep chain order and doing make by hand to get the lib or bin he wants, thinks it'd be keen if he could go where he wants and do "make depends all" |
| 20:04.20 | brlcad | ahh |
| 20:04.23 | brlcad | yeah, that would be useful |
| 20:04.31 | ``Erik | not including .c files, but generic/regex.h is used several places in generic/*.c |
| 20:04.34 | brlcad | i do the cd dir dir dir blah foo too |
| 20:05.14 | brlcad | i think only folks that understand how automake works are generally inclined to do that, but hey that's cool |
| 20:05.18 | ``Erik | it might be best to mv regex.h regex_tcl.h and sed 's/regex\.h/regex_tcl.h' *.[ch] |
| 20:05.38 | brlcad | might also just get away with -DVOID=void |
| 20:05.52 | ``Erik | I'd do it to what we have now, but I ASSUME you're close to committing a new tcl |
| 20:05.57 | brlcad | the more I looked at it last night, the more it looked like it was empty |
| 20:05.59 | ``Erik | that won't be the only thing broken, just the first |
| 20:06.20 | *** join/#brlcad clock_ (i=clock@84-72-63-61.dclient.hispeed.ch) |
| 20:06.31 | ``Erik | unless generic/regex.h just happens to have all the meat of /usr/include/regex.h and it happens to use the same define values and stuff |
| 20:07.21 | ``Erik | well, commit it up, yo... even if it's busted, we could split the load and both go about fixing... *shrug* |
| 20:11.36 | ``Erik | in a branch if ya want *shrug* I'll sync to a branch |
| 20:13.46 | brlcad | commit what up? |
| 20:13.59 | brlcad | -DVOID=void? |
| 20:14.48 | brlcad | still working on finishing this 8.5 testing/building, trying to get subconfigures to work reliably |
| 20:17.07 | dtidrow_work | http://tinyurl.com/3cx56e - good grief |
| 20:17.39 | dtidrow_work | the excessively accesorised toilet |
| 20:19.12 | archivist | lacks a lectern for a heavy book |
| 20:19.24 | brlcad | hrm.. by that math |
| 20:22.09 | brlcad | it's saying the average person spends 11862 hours per day in the bathroom (presumably on the toilet) .. which is roughly 30 minutes a day |
| 20:22.58 | ``Erik | per day? |
| 20:23.31 | ``Erik | heh |
| 20:24.02 | brlcad | i know some people that .. er .. take forever, but then they have "issues" too afaik |
| 20:24.16 | brlcad | well yeah, that depends what all is included |
| 20:24.28 | brlcad | the article makes it sound like you spend all that time on the john |
| 20:25.05 | dtidrow_work | heh - women spend at least 1.5hrs a day in the bathroom, then |
| 20:25.06 | archivist | for a good stiff sh.. the a good read is needed |
| 20:26.45 | brlcad | i never got that, i'm in and out every time -- there's no by the time I finish a couple sentances, it's over |
| 20:27.16 | ``Erik | need something to tear pages out of if there's no tp *shrug* |
| 20:28.13 | dtidrow_work | clearly ``Erik belongs to the church of vi |
| 20:28.24 | ``Erik | yes, the vim sect |
| 20:31.05 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (13 files in 13 dirs): beginnings of DEPS flags for "make depends" chaining. |
| 20:46.34 | brlcad | ahh |
| 20:48.28 | ``Erik | ? |
| 20:49.47 | brlcad | instead of (re)listing the dependencies.. they're already listed in a couple places |
| 20:50.27 | brlcad | you could parse over the libadd/ldadd stuff, or peek at the _DEPENDENCIES vars or peek in the .deps dirs and build up that directory list automatically |
| 20:51.08 | brlcad | so you don't have to maintain a separate list that'll eventually be out of sync when someone adds a new lib and doesn't notice the DEPS var |
| 20:51.29 | brlcad | it'd always be perfectly in sync |
| 20:51.39 | ``Erik | spoze I coulda tried that, and did sed-fu to strip it down *shrug* but if I did that, then people who're over-verbose in attaching libraries would cause a LOT of duplicate computation |
| 20:52.16 | ``Erik | <-- already annoyed with the amount of replication of computation with the hand-minimized list |
| 20:53.22 | brlcad | replication? |
| 20:54.56 | ``Erik | yeah... if I do 'make depends' in, say, mged... rt->bn->bu->tcl, tk->tcl, so tcl gets two passes |
| 20:54.58 | brlcad | if you need to rebuild mged and be portably sure, it's got to walk the dependency hierarchy for each ldadd lib .. |
| 20:55.28 | brlcad | hmm.. sounds like you need to build up the list of what to do before actually doing it |
| 20:55.38 | ``Erik | I was half tempted to give each dir an "am I built?" target and stopping if that's yes |
| 20:56.00 | ``Erik | that's one way, but to be portable across makes, ... :/ |
| 20:56.56 | brlcad | sure across makes |
| 20:56.56 | brlcad | you do the same traversal you have in depends now .. but make it do two walks .. just not runnning depends on the first walk |
| 20:57.52 | ``Erik | mebbe in the future... |
| 20:58.39 | brlcad | it is, but the hooks they provide should make it work |
| 20:58.47 | brlcad | i fixed a handful of things, there still another problem? |
| 20:58.59 | brlcad | could have disabled more, but I tried to only disable minimal |
| 20:59.07 | ``Erik | how'd you disable it? |
| 20:59.31 | brlcad | Makefile.am cppflags to turn stuff on/off |
| 21:00.05 | brlcad | right |
| 21:00.15 | brlcad | i commited a fix for that yesterday |
| 21:00.18 | ``Erik | libdm/dm_obj.c |
| 21:00.25 | ``Erik | I updated today, it's still breakin' O.o |
| 21:00.27 | brlcad | at least I thought I did |
| 21:00.43 | ``Erik | (also don't remember seeing a cia msg) |
| 21:01.19 | brlcad | huh, that's odd |
| 21:02.05 | brlcad | hrm, maybe the commit errored/timed out and I didn't notice |
| 21:03.58 | brlcad | ahh, yeah, something happened |
| 21:03.59 | brlcad | M pngconf.h |
| 21:04.17 | brlcad | probably queried for a pass and I didn't notice or something |
| 21:06.29 | ``Erik | that's the included png... I'm trying to use the system png |
| 21:07.14 | ``Erik | like guard the setjmp in bu.h and make sure png.h is included before bu.h |
| 21:07.27 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/libpng/pngconf.h: disable the linux setjmp.h double-inclusion protection (at least for now) on the assumption that we will get the same setjmp.h and this won't be a problem. add a note that this was modified by us for BRL-CAD. |
| 21:07.38 | ``Erik | since the png fucktards can't figure out how to guard headers right *cougH* |
| 21:07.46 | brlcad | pngconf.h is installed on the system? |
| 21:08.03 | ``Erik | yes$ ls -l /usr/include/pngconf.h |
| 21:08.03 | ``Erik | lrwxrwxrwx 1 root root 18 Aug 11 12:34 /usr/include/pngconf.h -> libpng12/pngconf.h |
| 21:08.24 | ``Erik | rhel64 on an opteron |
| 21:08.47 | ``Erik | shuffling headers and gaurding in bu.h sound about right? I can take care of it while you do tcl |
| 21:09.05 | brlcad | could work it out so that png.h is just included before our stuff -- it should be actually |
| 21:09.13 | ``Erik | 'k, I'll go about that |
| 21:09.17 | ``Erik | hurry up and finish tcl :D |
| 21:09.32 | brlcad | common.h -> system headers -> public interface headers -> private headers |
| 21:09.37 | ``Erik | so i can unhack regionfix.c and proe-g.c on my thing |
| 21:09.42 | brlcad | png.h is a system header |
| 21:10.18 | brlcad | another fix would be to just set -DPNG_SETJMP_NOT_SUPPORTED |
| 21:10.31 | brlcad | and it skips it altogether |
| 21:12.13 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libdm/dm_obj.c: pull system headers up ahead of our headers |
| 21:14.24 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/canon/png-ipu.c: pull system headers up ahead of our headers |
| 22:02.23 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 23:37.14 | louipc | more |
| 23:37.20 | louipc | erk |
