| 00:10.58 | Maloeran | That truck is so saturated of degenerative cases which produce packed long thin triangles. Performance will suddently bump up at some point when I write the missing prep pass |
| 00:35.48 | brlcad | that's an interesting feat because there's about 3 predominant coding styles in brl-cad |
| 00:36.16 | brlcad | at least until I finally run source formatting to make it all consistent |
| 00:36.21 | Maloeran | Yes I noticed, I tried to get used to the one documented in HACKING |
| 00:36.28 | brlcad | ahh |
| 00:36.43 | Maloeran | ( though I fail miserably ) |
| 00:37.03 | brlcad | that's mostly K&R style |
| 00:37.31 | brlcad | the next most popular is probably BSD style |
| 00:38.45 | Maloeran | Yes... I learned C at 12 without internet or books, just a compiler and some code ; I don't think I follow any standard |
| 00:43.58 | Maloeran | and I learned x86 assembly from typing gcc -S instead of gcc -s once by mistake ;), the old good days |
| 00:44.29 | brlcad | :) |
| 01:34.49 | *** join/#brlcad korrupthed (n=squee@bas1-london14-1167879640.dsl.bell.ca) |
| 01:35.46 | korrupthed | the site is not comin up .. n e one got a download link i can follow? |
| 01:39.48 | *** part/#brlcad korrupthed (n=squee@bas1-london14-1167879640.dsl.bell.ca) |
| 02:27.39 | brlcad | damn sourceforge |
| 02:28.05 | brlcad | i think they're blocking us as we are several hundred MB over quota |
| 02:28.13 | brlcad | i'll put in a request for an increase |
| 02:28.27 | brlcad | in the meantime, there's the mirror: http://ftp.brlcad.org/ |
| 02:28.35 | Maloeran | You mean there were too many downloads of brlcad? |
| 02:28.48 | Maloeran | Perhaps that should go in the topic |
| 02:29.13 | *** topic/#brlcad by brlcad -> http://ftp.brlcad.org (mirror of http://brlcad.org, down for 'maintenance') || BRL-CAD is an open source solid modeling software suite || Developers needed! Read the HACKING file for details on getting involved || Release 7.8.4 is posted, next release will be 7.10.0 |
| 02:29.20 | brlcad | you were saying? :) |
| 02:29.35 | brlcad | nobody reads the topic, but there it is |
| 02:29.41 | brlcad | not too many downloads |
| 02:30.35 | brlcad | there is a default quota on the amount of space you can utilize on the web space provided to projects (which is separate from the project pages and the file release system section) |
| 02:31.00 | Maloeran | Ah, I see |
| 02:31.02 | brlcad | we already have a massively increased quota on the file release system as each release uses about a GB if all binaries are made |
| 02:31.27 | Twingy | larger than open office? |
| 02:31.39 | brlcad | but for the web space, ti's still the default 100MB, and we're at 300MB or so |
| 02:31.54 | brlcad | Twingy: no idea |
| 02:32.13 | Twingy | what are you paying for you colo? |
| 02:32.21 | brlcad | probably, just because there are so many more binaries |
| 02:32.47 | brlcad | it's not a colo, it's dedicated |
| 02:33.02 | Twingy | I thought you payed for a colo somewhere for brlcad.org |
| 02:33.13 | brlcad | brlcad.org is sf.net |
| 02:33.19 | Twingy | you gave it up? |
| 02:33.34 | brlcad | .bz (i.e. ftp.brlcad.org and bzflag.bz) is my server |
| 02:33.43 | Twingy | that's colo right? |
| 02:33.50 | brlcad | no, it's dedicated.. :) |
| 02:34.04 | brlcad | i get the whole box, the whole pipe |
| 02:34.09 | brlcad | i just don't own the hardware |
| 02:34.16 | Twingy | oh yea, ok |
| 02:34.17 | brlcad | less fuss |
| 02:34.19 | Twingy | what are you paying for that |
| 02:34.33 | brlcad | i don't recall exactly, it's pettance |
| 02:34.38 | brlcad | ~spell pettance |
| 02:34.49 | brlcad | something like 65 |
| 02:35.02 | Twingy | I just switched to comcast workplace 6Mb/768 for $80 a mo, they got 8Mb/1Mb for like $100 something |
| 02:35.09 | Twingy | no bandwidth cap |
| 02:35.17 | Twingy | static ip etc |
| 02:35.25 | brlcad | "no bandwidth cap" |
| 02:35.50 | brlcad | 768 up would be a killer |
| 02:36.01 | Twingy | how about 1Mb? |
| 02:36.55 | Maloeran | Connections sure are expensive down there, I'm paying less for a 10mbits commercial |
| 02:37.11 | Maloeran | And they are paying half of that for 20mbits in Norway and Sweden, but.. :) |
| 02:37.16 | Twingy | I think bandwidth is proportional to the population of the area |
| 02:37.38 | Maloeran | Ah yes, indeed |
| 02:37.43 | brlcad | 1M might work, but that's still less than what I have |
| 02:38.01 | Twingy | but you have hands on access to your box so you could use one box as raid/fileserver/webserver |
| 02:38.08 | brlcad | I can sustain 4Mbit over the entire month before I cap out, about 1.5TB |
| 02:38.17 | Twingy | kk |
| 02:38.57 | Twingy | I've pondered the idea of doing colo here and using solar panels to power machines |
| 02:39.37 | Twingy | the little 500MHz nano-itx boards only use 2.5W |
| 02:39.38 | brlcad | i'm about to replicate to a server in germany soon, need redundancy on some of the services for bz and some of the web hosts |
| 02:40.01 | Twingy | they would be very economical to offer dedicated on |
| 02:40.05 | brlcad | the deal is about the same there, maybe 5 bucks cheaper even |
| 02:40.21 | brlcad | heh |
| 02:40.29 | brlcad | "Site Down due to cloudy day" |
| 02:40.33 | Twingy | naw |
| 02:40.37 | Twingy | it's grid tied |
| 02:41.22 | Twingy | for folks that don't need much bandwidth, I could probly pitch it for $29.95/mo for your own box |
| 02:42.11 | Twingy | I'd prefer charging based on bandwidth and power consumption though |
| 02:42.22 | Twingy | that'd be real easy to compute |
| 03:33.33 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 04:36.54 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 05:44.47 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 06:32.28 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 09:34.41 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 13:51.32 | *** join/#brlcad Maloeran (n=maloeran@195.139.172.210) |
| 16:01.04 | brlcad | brlcad.org isn't down because of quota usage apparently, it was a larger vhost problem that affected lots of projects not just ours |
| 16:01.24 | brlcad | since it's just vhost services, brlcad.sourceforge.net actually still works as one would expect |
| 16:18.21 | Maloeran | Erik or brlcad, what's the little program found in brlcad to convert raw pixels to pix or some other format? ( to use pixdiff ) |
| 16:42.15 | brlcad | pix files are raw image files |
| 16:43.14 | brlcad | first quadrant, integer array, interlaced, 8 bit per channel, 3 channel (RGB) |
| 16:43.37 | Maloeran | Okay, I was not seeing any output, but the files are indeed identical |
| 16:43.47 | brlcad | so basically, if you just write out RGBRGBRGB, you can use pixdiff |
| 16:43.57 | Maloeran | *nod* Thanks |
| 16:44.40 | brlcad | try pixcmp |
| 16:44.47 | brlcad | more numerically informative |
| 16:45.35 | Maloeran | Right, that will do nicely |
| 16:47.29 | brlcad | the brl-cad benchmark uses that same tool to validate results, off by one values are 'okay', but off by many from the expected results are considered an error |
| 16:48.03 | Maloeran | You will get "off by many" whenever a ray happens to hit the edge of a triangle or not |
| 16:48.19 | Maloeran | I'm just comparing my scalar vs SSE packed paths, and : 1432833 matching, 7164 off by 1, 3 off by many |
| 16:50.06 | Maloeran | If we were to raytracer the counter of a single triangle, just the ray-triangle intersection algorithm used will make a few pixels bump in or out |
| 16:50.21 | Maloeran | to raytrace the contour |
| 16:51.03 | brlcad | it's to say that you're usually comparing to stable results with something that should be the similar or the same situation |
| 16:51.39 | brlcad | if you can explain the deviation, demonstrably (not just intuition), then it's generally a non-issue |
| 16:52.33 | brlcad | but it's often been the case where off by many errors have cropped up even in rt that "seemed reasonable" at a glance that could be explained away as floating point or edge cases, etc, only to find out later that there was numerical instability not being accounted for |
| 16:53.41 | Maloeran | Yes, I'll have to check my math on that later on too |
| 16:54.03 | brlcad | intuitively, the scalar vs sse packed paths can of course be different if only because of different mathematical manipulations, but it not necessarily the case that you can't get them to have no off by many values ;) |
| 16:54.49 | ``Erik | *yawn* |
| 16:54.55 | brlcad | food coma? |
| 16:55.00 | ``Erik | kinda |
| 16:55.08 | ``Erik | bigassed morning meeting contributing |
| 16:55.10 | Maloeran | Just the order of operations would change the result |
| 16:55.36 | brlcad | sure would |
| 16:55.54 | brlcad | but how much and whether the drift is something that can be adjusted for is another issue |
| 16:56.01 | brlcad | maybe, maybe not |
| 16:56.30 | Maloeran | I could use pictures out of ADRT or so, to rely on as a reference |
| 16:56.38 | brlcad | the point is usually to trace the ray and watch the results to be able to deterministicly say why it's different |
| 16:56.56 | brlcad | yeah, though you'll probably have issues matching cameras |
| 16:57.16 | Maloeran | Yes... and ADRT seemed to rely on magical constants, I'm not sure if that's really reliable |
| 16:57.18 | brlcad | and even then, you're still bound to have off by lots |
| 16:58.27 | brlcad | i had a little fun a few weeks ago, took a single sphere and ray-traced it with rt |
| 16:59.15 | Maloeran | I assume librt is fairly accurate overall |
| 16:59.17 | brlcad | then proceeded to tessellate the sphere to varying orders of |
| 16:59.25 | brlcad | facetization |
| 17:00.08 | brlcad | using pixcmp to compare the differences, increasing the tessellation at each level to see how closely I could minimize the deviation error |
| 17:00.14 | brlcad | it was rather interesting |
| 17:00.53 | brlcad | I couldn't make the off by manys go away, but was able to reduce them to a mere hundred or so on a 512x512 |
| 17:01.12 | Maloeran | That's about what I would expect |
| 17:01.25 | brlcad | ended up getting up to 10M triangles before getting bored with it iirc |
| 17:02.48 | brlcad | which is about 50 triangles per pixel? :) |
| 17:03.25 | Maloeran | :) You'll always get many "off by many" near the edge, especially in a case like this |
| 17:04.01 | Maloeran | I get many "off by one" just for supplying the vectors to the API or having them automatically generated |
| 17:04.14 | brlcad | actually, the edges were dead on |
| 17:04.59 | brlcad | the off by many errors were around a highly specular hilight area |
| 17:05.07 | brlcad | which also makes sense |
| 17:05.43 | brlcad | where a tiny deviation results in a wrong energy contribution |
| 17:05.49 | Maloeran | The edges were correct? I'm surprised, the wonders of double precision I guess |
| 17:06.36 | brlcad | with enough triangles, I was actually able to get a majority of the sphere to not have even off by one errors |
| 17:07.11 | brlcad | but we are talking about lik 1M triangles.. for just one .. sphere .. :) |
| 17:08.07 | Maloeran | I think results would have been off for many pixels if you had used floats, not matter how many triangles were used |
| 17:08.23 | brlcad | probably |
| 17:08.29 | brlcad | an exercise for another day |
| 17:08.42 | Maloeran | As accuracy is so critical, I guess I'll have to write a SSE2 double precision path |
| 17:09.42 | brlcad | i was just more interested with sort of estimating how many triangles will it generally take to get the energy deviation to match the implicit within some % |
| 17:15.38 | brlcad | front, top, left, 35,25, and a few random ;) |
| 17:16.46 | Maloeran | Traversal is faster for axis-aligned points of view, that would be a bit biased |
| 17:18.27 | Maloeran | Any thoughts on if I need to test scalar, scalar with vector generation, SSE, SSE with gen, double, etc.? That list could be long |
| 17:18.41 | Maloeran | On top of various combinations of preparation quality/memory/speed hints |
| 17:21.18 | brlcad | that's why only three would be axis aligned |
| 17:21.38 | brlcad | but those happen to be .. frequently used views for various purposes, so it's also relevant |
| 17:21.46 | Maloeran | *nod* Okay |
| 17:23.19 | brlcad | not really sure about what all you need to test.. that depends on a lot of factors, especially the expected use and need |
| 17:23.47 | brlcad | though following the scientific process would make me lean towards testing them all especially given it's just going to be automated |
| 17:24.19 | Maloeran | It just implies I need two libraries to test float and double, for example |
| 17:27.15 | ``Erik | why? build for float, run tests, b uild for double, run tests... |
| 17:29.48 | *** join/#brlcad PrezKennedy (n=Apathy@c-68-55-177-2.hsd1.md.comcast.net) |
| 17:32.18 | Maloeran | The front-end is meant to support multiple libraries already though, if I can figure how to do that with autoconf. On a different topic, the triangles of truck_bots.g sure are not oriented in a coherent way |
| 17:32.46 | Maloeran | Any simple brlcad command to attempt fixing this? |
| 18:01.43 | ``Erik | oriented as in uniform winding? |
| 18:04.06 | Maloeran | Preferably, yes |
| 18:18.29 | Maloeran | Logically, when converting from CSG to triangles, it should be terribly simple to orient the triangles properly |
| 18:18.59 | Maloeran | You know very well what is "in" and what is "out" at that point |
| 18:19.35 | ``Erik | yeah, logically... |
| 18:19.43 | ``Erik | but the converter is... imperfect. |
| 18:20.13 | Maloeran | That's what should be fixed, rather than trying to fix the triangles afterwards or raytracing results |
| 19:11.47 | Maloeran | Eh well, Mark forgot the arrangements for the conference and Beatrice doesn't seem to be taking her emails ; registration is only possible on-site now. I think I'll have to try an ancient audio communication device |
| 19:13.59 | ``Erik | what conference? |
| 19:14.23 | Maloeran | Baltimore visualization conference |
| 19:14.29 | Maloeran | Oct 29 to Nov 3 or so |
| 19:30.45 | Maloeran | No more success by phone. With some luck, I'll just miss that conference ;) |
| 19:39.54 | ``Erik | ah, heh |
| 19:40.05 | ``Erik | I'd rather be going to nycbsdcon :/ |
| 19:40.08 | ``Erik | stupid overlap |
| 19:45.53 | ``Erik | but on sourceforge, it doesn't have the dash in the short project name, brl-cad :) |
| 19:46.21 | archivist | and this room is minus the - |
| 19:47.31 | brlcad | ``Erik: yep, and there's actually documentation written about exactly when it's okay |
| 19:47.33 | Maloeran | Eh well, pick a different nickname? ;) |
| 19:47.35 | brlcad | which I can see you haven't read :) |
| 19:48.43 | brlcad | it's not because I use brlcad or not, it's to retain coherency/consistency on the name of the project |
| 19:49.02 | brlcad | e.g. BRL-CAD is the official name, dash and all |
| 19:50.06 | brlcad | speaking of which.. |
| 19:52.50 | ``Erik | it's ok when I say it's, brl-cad :> |
| 19:53.48 | ``Erik | alexis: I was in err on the 'bundle' statement, it just means packets of rays, and limiting to either all parallel or all co-originating is ok |
| 19:54.10 | ``Erik | also; the conference thingy, it's not about the conference, it's about presense in the area (meeting type crap) according to lee |
| 19:54.55 | Maloeran | That's fine for Lee, but I'm not really fond of that |
| 19:55.05 | ``Erik | parse which? my tongue in cheek statement about it (brlcad vs BRL-CAD) being ok when I say it's ok? :D |
| 19:56.04 | Maloeran | Thanks for the clarification on ray bundles, that's quite simple |
| 19:56.08 | ``Erik | mal: I just reported status, and carried response back *shrug* technically, this is between lee and mark, and then mark and you |
| 19:56.09 | tofu | it's all good, but it does dilute slightly to not be consistent even as minor as it is |
| 19:56.14 | ``Erik | sorry about the misinformation earlier :) |
| 19:57.07 | ``Erik | well, the 'perspective' case is not necessarily a regular grid of rays, it could be a random-looking scattering generated by someone elses software... |
| 19:57.29 | Maloeran | Of course so, one can supply arbitrary vectors if so desired |
| 19:57.35 | ``Erik | like, say, if I'm using it to do radiosity and I have an optimization where I don't shoot as many towards darker areas *shrug* |
| 19:58.12 | Maloeran | "Reported status", that implies uncompleted regression tests right? :) There's not much missing |
| 19:58.19 | ``Erik | heh, arl-cad :D |
| 19:58.44 | ``Erik | um, 'reported status' was more like "clarify a couple things for me, and oh, he might not make it to the conference" |
| 19:59.17 | Maloeran | Any reason provided or asked for not making it to the conference? |
| 19:59.20 | tofu | ~nickometer ``Erik |
| 19:59.23 | ``Erik | http://hardware.slashdot.org/comments.pl?sid=201421&cid=16490605 |
| 19:59.27 | ``Erik | hah |
| 19:59.33 | ``Erik | ~nickometer tofu |
| 19:59.41 | ``Erik | wow, lame script |
| 19:59.42 | ``Erik | :) |
| 19:59.54 | Maloeran | ~nickometer Maloeran |
| 20:00.04 | ``Erik | must be my stealth marks |
| 20:00.20 | Maloeran | Your stealth marks are no match for a french canadian keymap |
| 20:00.44 | ``Erik | the keymap isn't where the stealth comes from, it's the character map on ... lesser os's. |
| 20:01.03 | ``Erik | (many windows/mirc users think it's ''erik, and get confused when they can't whois or privmsg me) |
| 20:01.21 | ``Erik | http://content.ytmnd.com/content/a/2/2/a224551a525ebf5e30cedf1f4ae16b99.gif |
| 20:01.31 | Maloeran | Speaking of which, I wonder how you do ^ with an us/en keymap, is the character used for anything besides programming? |
| 20:02.17 | Maloeran | Ahaha |
| 20:02.18 | ``Erik | shift-6 |
| 20:02.43 | Maloeran | "Accept teaching without resistance". I sure remember why I quit school |
| 20:03.10 | ``Erik | only at the worst primary schools |
| 20:03.37 | ``Erik | secondary schools tend to be a lot more involved with a lot more participation and a lot less teacher idiocity |
| 20:04.00 | ``Erik | (it's a GOOD thing if you cna prove the professor wrong :) |
| 20:04.35 | Maloeran | I went to a good high school, for musically gifted people where 55% of the time there was spent on music.. so it was bearable |
| 20:04.41 | Maloeran | College was a shock |
| 20:06.04 | Maloeran | I was thrown out of a physics class there for arguing with the teacher about the spin of electrons, I had my Hawking book to prove my point, I quit the following day |
| 20:06.34 | ``Erik | wow, I'd seen similar arguments, never seen that result, though... |
| 20:06.38 | ``Erik | colleges in canada must suck ass |
| 20:07.15 | Maloeran | I went to a fairly "normal" college, out of a high-end school for talented people, so the shock was brutal |
| 20:08.12 | Maloeran | I'm sure there are stupid teachers everywhere |
| 20:08.53 | ``Erik | definitely, but some environments are more accepting of stupid behaviors than others |
| 20:09.32 | Maloeran | It wasn't just the teachers, the pace was so terribly slow, the students were so.. ignorant and unmotivated. It was a radical change of environment |
| 20:10.05 | Maloeran | But I really had enough of violin after 10 years, seriously :) |
| 20:16.35 | ``Erik | heh, unless you go down into the city, it's called a "fiddle" here... ;> *duck* |
| 20:17.28 | ``Erik | and brl-cad is from the land of fiddles, banjos, and toothless people in overalls, pheer wv *duck* :D |
| 20:18.27 | Maloeran | Cool, need a violin for the ARL orchestra or something? :) |
| 20:18.39 | ``Erik | heh |
| 20:20.08 | ``Erik | damn openbsd does not compile pretty. |
| 20:22.22 | Maloeran | Compiling obsd or compiling something there? |
| 20:22.28 | ``Erik | compiling obsd's world |
| 20:22.30 | ``Erik | keeps breaking |
| 20:26.12 | ``Erik | hm, rayforce fails on my leenewx opterwang thingy |
| 20:26.22 | ``Erik | Preparation time : 35.583 seconds |
| 20:26.22 | ``Erik | Error flag : 0 |
| 20:26.22 | ``Erik | -- Memory allocation listing at ../../../RF/context.c:208 -- |
| 20:26.23 | ``Erik | <PROTECTED> |
| 20:28.59 | Maloeran | What's faling? |
| 20:29.01 | Maloeran | failing, even |
| 20:29.09 | ``Erik | also; "The posix_memalign() function is part of the Advisory Information option and need not be provided on all implementations." (per http://www.opengroup.org/onlinepubs/000095399/functions/posix_memalign.html ) |
| 20:29.29 | Maloeran | Right, I'll change that soon |
| 20:30.04 | Maloeran | 35 seconds is awful somehow |
| 20:30.06 | ``Erik | um, I don't know what's failing? heh, it generates an rtch file, about twice as big as the rtml |
| 20:30.13 | ``Erik | well, that's an amd64 linux box |
| 20:30.34 | ``Erik | uhhh, and the roter lowe |
| 20:30.35 | Maloeran | The cache file uses 64 bits indices, so it's big |
| 20:30.44 | ``Erik | -rw------- 1 erikg 42 88915180 Oct 18 16:25 roter-lowe.rtch |
| 20:30.51 | Maloeran | Woah :) |
| 20:31.36 | Maloeran | I'm aware that cache files need some packing |
| 20:32.06 | ``Erik | $ uname -osrvmpi |
| 20:32.06 | ``Erik | Linux 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 17:57:31 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux |
| 20:32.27 | Maloeran | Does it render otherwise? What do you mean by failing? |
| 20:32.31 | ``Erik | but when it gets done generating the cache file, reports the error code (0), then says a list is empty and exits |
| 20:33.01 | Maloeran | That means no error occured and there's no memory leak. envCreateWindow() must have failed |
| 20:33.15 | Maloeran | The SDL window creation |
| 20:33.49 | Maloeran | It's not clear how it could fail though |
| 20:34.01 | ``Erik | that did it |
| 20:34.08 | ``Erik | DISPLAY wasn't set |
| 20:34.18 | Maloeran | Yes, that explains it |
| 20:35.02 | ``Erik | around 7-14 fps (depending on how much is in view) |
| 20:35.32 | Maloeran | For the M1 model? |
| 20:36.04 | Maloeran | That's acceptable for now, tracing of volumes ( or frustum culling, whatever you want to call it ) will bump the numbers up soon |
| 20:36.07 | ``Erik | the boat |
| 20:36.15 | ``Erik | the model that shouldn't be is 7-9 |
| 20:36.42 | ``Erik | I have a feeling that the remote X part might be bottlenecking it now |
| 20:37.03 | Maloeran | 7-14fps on the 1.7m frigate despites all the diagonal ropes all over the place? That's not too bad |
| 20:37.22 | Maloeran | Every ray is being traced entirely at the moment ; there's no volume tracing at all, so I'm not displeased with that |
| 20:37.25 | ``Erik | well, the deck is barely visible, since the camera is kinda below the keel, heh |
| 20:37.53 | ``Erik | and when it swings around, the camera goes through the inside |
| 20:38.24 | *** join/#brlcad b0ef (n=b0ef@062016141085.customer.alfanett.no) |
| 20:38.53 | Maloeran | Yes well, you have to uncomment the other origin[] in main.c |
| 20:39.23 | Maloeran | The boat and the M1 have different scales and origins, so you have to switch between two blocks of code from one model to the other. That will be cleaner eventually ;) |
| 20:41.39 | ``Erik | 2.4-2.8 with the ship and the right origin, heh |
| 20:42.08 | Maloeran | That's much more like it |
| 20:42.31 | Maloeran | I never tried the boat with the SSE code, I think the laptop's ram is not enough to prep |
| 20:42.58 | ``Erik | hm, I have the ram |
| 20:43.07 | ``Erik | this 8 core opteron has 32g ram |
| 20:43.10 | ``Erik | and 1.8ghz chips |
| 20:43.11 | Maloeran | Eheh |
| 20:43.24 | ``Erik | noisy piece of shit, too |
| 20:43.31 | Maloeran | It will perform... better with volume tracing, a fixed prep, and threads |
| 20:43.38 | ``Erik | gimme threaded distributed code, boy :D |
| 20:44.03 | ``Erik | 24 opterons should have a fair amount of push |
| 20:44.11 | Maloeran | I know! :) I'll complete the code before distributing it though |
| 20:44.45 | ``Erik | 43.2 ghz of opteron unfage, with 96g of ram |
| 20:45.45 | Maloeran | 35 seconds of prep was the frigate? |
| 20:46.19 | ``Erik | yeah |
| 20:46.20 | Maloeran | I'm just making sure, I had enough weird experiences with absurd prep times on your boxes... :) |
| 20:46.22 | Maloeran | Good |
| 20:46.37 | ``Erik | only 7.2g disk space, though |
| 20:46.41 | ``Erik | er |
| 20:46.42 | ``Erik | 7.2tb |
| 20:46.44 | ``Erik | heh |
| 20:47.26 | Maloeran | Cool, I'm sure I can come up with a cache file format to fill that |
| 20:47.47 | Maloeran | XML-based layed out binary, a bit at a time, with 256 bits indexing |
| 20:51.15 | ``Erik | heh, 'xml based' was enough... :( |
| 20:51.29 | ``Erik | the most verbose and useless reinvention of s-expressions I've ever seen |
| 20:51.47 | Maloeran | It's much better when used to describe binary data too |
| 20:54.23 | ``Erik | xml... based... |
| 20:54.33 | ``Erik | :> |
| 20:59.34 | Maloeran | That's the spirit! XML, SQL and Java are the future |
| 20:59.41 | ``Erik | if you strap a piece of buttered toast to the back of a cat, butter side up, and drop the cat out a window, it will fall to approximately a foot above the street, and hover there, spinning. |
| 21:00.10 | ``Erik | huh... xml, sql, and java... that combo sounds, uh, familiar. |
| 21:00.32 | archivist | na not my cat as it is devoid of self righting and ... life |
| 21:01.15 | ``Erik | throw in jini, hibernate, rio, 'naked objects', service based architecture, and an obscene focus on process, content management, control, and cmmi and you have yourself a winner... |
| 21:01.17 | ``Erik | *cough* |
| 21:02.28 | archivist | buzz words give me headaches |
| 21:03.02 | ``Erik | archivist: that was the quick&dirty description of the software project I recently escaped from... I foresee... no success wrt to it. |
| 21:03.57 | Maloeran | We should write a distributed processing raytracer for it, where every sector, node and triangle access goes through a SQL query |
| 21:04.17 | ``Erik | they were, uh |
| 21:04.22 | ``Erik | talking about kinda doing that actually |
| 21:04.29 | ``Erik | because the jni interface to librt is "too hard" |
| 21:04.40 | Maloeran | Ahahah |
| 21:04.40 | archivist | I just bought a book at the weekend as it had a buzz word on the cover and I thought I should be able to say I knew something about it |
| 21:04.44 | ``Erik | so they were gonna write the raytrace component in java |
| 21:04.45 | ``Erik | *cough* |
| 21:04.57 | Maloeran | This is so sad |
| 21:05.05 | archivist | even php would be faster |
| 21:05.50 | ``Erik | well done php would be faster than what they're trying to do, yes... but well done java CAN be 'reasonable' performance-wise... well done java is rare, though |
| 21:06.06 | ``Erik | people either approach is as 'weird c++' or go way overboard on oo :( |
| 21:06.12 | Maloeran | If you do care about performance, just don't use Java |
| 21:06.16 | ``Erik | very few understand how a jvm works |
| 21:07.08 | archivist | "overboard on oo" they've read too much UML bs |
| 21:08.03 | ``Erik | class Blah extend Meh {} <-- common construct. |
| 21:08.09 | ``Erik | extends, even |
| 21:08.13 | ``Erik | *cough* |
| 21:08.53 | archivist | tis right to be bitter about extends crap upon crap |
| 21:09.21 | ``Erik | dude, I could literally bitch for hours |
| 21:09.22 | ``Erik | :) |
| 21:09.57 | Maloeran | That doomed Java project must have caused a profound psychological trauma |
| 21:10.07 | Maloeran | As it would have for any other sane programmer |
| 21:10.09 | archivist | oo has created a new kind of quck and dirty programming |
| 21:10.54 | ``Erik | not so much quick, just a whole lot of dirty? :D |
| 21:11.55 | Maloeran | I think it's quick for very simple thing, but it doesn't scale |
| 21:12.00 | Maloeran | things* |
| 22:06.24 | ``Erik | heh, baltimore has all that if you go downtown, too *shrug* :) |
| 22:08.40 | Maloeran | Oh I'm sure it does. Until I moved two weeks ago, I wasn't in reach of delivery for the really good restaurants |
| 22:19.17 | tofu | mmm.. indian food |
| 22:19.28 | tofu | i miss living in the city |
| 23:02.03 | *** join/#brlcad spldart (n=spldart@cpe-70-116-149-121.houston.res.rr.com) |
| 23:04.56 | *** part/#brlcad spldart (n=spldart@cpe-70-116-149-121.houston.res.rr.com) |
