| 01:37.41 | IriX64 | interesting |
| 01:38.11 | IriX64 | and obviously they keep adding to it. |
| 01:40.07 | IriX64 | good to know i'm not in there, was worried for a moment :) |
| 04:04.01 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050142.dsl.bell.ca) |
| 04:36.58 | IriX64 | brlcad just out of curiosity, does that magic number, is it returned from gl, and is it guaranteed to be the same on everybodys system? |
| 04:38.13 | IriX64 | I took it out of my copy, and am curious if im breaking anything else? |
| 04:38.33 | IriX64 | still compiling, i'll know soon. |
| 04:49.24 | Maloeran | Magic variables as first member in structs are used to uniquely identify the chunk of data for debugging purposes |
| 04:52.26 | Maloeran | Speaking of which, I find it strange that there's no global switch to disable these checks and remove the magic variables |
| 05:07.08 | IriX64 | they're merely checking a passed pointer to a struct for validity, in fb_close trying to close the device. |
| 05:12.17 | IriX64 | works ty. |
| 05:12.23 | IriX64 | rt too :) |
| 05:16.18 | IriX64 | was failing on the open. |
| 05:18.52 | IriX64 | my way i still check the pointer for validity, but it's not tied to that funny number. |
| 05:20.36 | IriX64 | just use the same name for the new check, it passes, i recompiled everything. |
| 05:25.56 | IriX64 | still need the other two variables (ptr and str) . |
| 05:26.11 | IriX64 | for backwards compatibility :) |
| 05:31.37 | IriX64 | http://www.pastebin.ca/index.php my code for what its worth, nothing else need change. |
| 05:37.11 | IriX64 | now to build an x version for myself. |
| 05:38.00 | brlcad | IriX64: removing the check doesn't fix anything any more than spraying perfume on crap makes it smell good |
| 05:38.34 | brlcad | it's a value defined by BRL-CAD and repeatedly checked for validity in the case of bug injection or bad compilation logic |
| 05:38.39 | IriX64 | well my crap not only smells good it does what its supposed now :) |
| 05:39.07 | brlcad | it's still crap |
| 05:39.22 | IriX64 | but crap that works is no longer crap |
| 05:39.30 | brlcad | that's BS |
| 05:39.35 | brlcad | you've just masked the problem |
| 05:39.40 | brlcad | and created an unstable system |
| 05:39.51 | IriX64 | urf ok just ignore that snippit i pasted |
| 05:40.00 | brlcad | there's no guarantee now that you might coorrupt a geometry database or cause other harm |
| 05:40.19 | IriX64 | man we're dealing with video here its not rocket science. |
| 05:40.21 | brlcad | just because it no longer aborts doesn't mean the problem is fixed, it aborted for a very important reason |
| 05:40.36 | IriX64 | yeah the damn numbers didint match. |
| 05:40.53 | IriX64 | one is supplied by me one by u go figure. |
| 05:41.02 | brlcad | that's just the check |
| 05:41.08 | brlcad | do you even realize what the check means? |
| 05:41.14 | IriX64 | but it bombs on a simple open |
| 05:41.23 | brlcad | it means you have corrupted memory, the wrong data |
| 05:41.36 | brlcad | which means just about *anything* can happen |
| 05:41.46 | brlcad | random crashes, unstable behavior, data corruption |
| 05:42.04 | brlcad | that's absurd |
| 05:42.11 | IriX64 | goats gotten, as i say you're free to ignore it. |
| 05:42.41 | brlcad | well, just don't waste my time later with any other issues then, because that is a deal-breaker |
| 05:42.53 | brlcad | flat out, you're on your own |
| 05:43.07 | IriX64 | sure if im going to hassle you ill recompile with that in it ok? |
| 05:43.34 | IriX64 | err yours in it. |
| 05:43.48 | IriX64 | simple #ifdef for sean ... |
| 05:44.20 | IriX64 | ill even add it to configure ;) |
| 05:44.29 | IriX64 | --for-sean |
| 05:46.31 | brlcad | the fact it even works is interesting, perhaps a side effect of the prevalence of aliasing and struct alignments |
| 05:46.44 | brlcad | but it's entirely unpredictable behavior |
| 05:47.39 | brlcad | what's bothersome is that you seem to think there's nothing wrong with the change you've made as if you understand the full implications .. I do not believe that to be the case |
| 05:48.43 | brlcad | i'm not just being pedantic about the check, there is a problem there that may or may not be benign, but it's an entirely unpredictable system and as a solid modeling system predictability and security of user data is paramount important |
| 05:51.21 | brlcad | Maloeran: brl-cad doesn't use the magic numbers just for debugging, it's fundamental to various data integrity tests and assurance that the application will shut down the instant an unexpected situation is detected so as not to corrupt data .. the user's data is vastly (several orders) more important than the application |
| 05:52.50 | brlcad | there is a compile-time switch to turn off the actual checks and run-time debugging aspects of those checks, but we don't even ship binaries with that option .. it's intended for specific jobs where you know that an error won't be encountered and want the 5-50% performance gain |
| 05:55.25 | brlcad | as for actually removing the magic variables at compile-time, it's rather bad-practice to change the size of your structs between modes of compilation -- you change alignments, can mask errors, and can introduce new problems in itself |
| 06:02.54 | *** join/#brlcad SWPadnos (n=Me@dsl245.esjtvtli.sover.net) |
| 06:58.23 | IriX64 | x works |
| 07:16.12 | ``Erik | O.o |
| 07:17.35 | ``Erik | removing struct magic isn't going to buy you anything, just bring grief... |
| 07:19.30 | ``Erik | yeah, it burns a clock in some functions, but if it ever follows the 'off' branch path, it's a serious error, so performance wise it's an "optimal" jne |
| 08:36.00 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 08:37.20 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 09:48.12 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 12:43.50 | brlcad | our application has been entered |
| 13:06.08 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 13:33.33 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 13:40.21 | Maloeran | Makes sense, brlcad. I guess the magic checks aren't too present in the critical performance loops |
| 14:08.25 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) |
| 15:48.48 | Maloeran | Mmhm, http://news.bbc.co.uk/2/hi/asia-pacific/6441631.stm |
| 16:53.03 | IriX64 | used the wrong code tree, goof that I am, there goes another hour. |
| 17:12.17 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 17:19.47 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 17:19.47 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 18:00.43 | *** join/#brlcad dtidrow_work (n=dtidrow@host169.objectsciences.com) |
| 19:05.08 | IriX64 | wikipedia knows nothing of glEnable() (cept for a java wrapper) :) |
| 19:06.17 | IriX64 | should have all ansi programming references there :) |
| 19:14.38 | ``Erik | em, it's an encyclopędia, not a programmer reference... |
| 19:22.32 | brlcad | it's also directly editable.. if you want to add something that's missing, you can directly do so |
| 19:38.44 | IriX64 | doesn't that cause a mess? |
| 19:39.37 | IriX64 | who keeps track of what i add it could be blatantly a lie. |
| 19:47.42 | ``Erik | oh neat, they're running 'the prisoner' on bbc, first episode starts in 10 minutes |
| 20:54.42 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050142.dsl.bell.ca) |
| 21:01.34 | IriX64 | mc |
| 21:08.28 | *** join/#brlcad clock_ (i=clock@84-72-90-161.dclient.hispeed.ch) |
| 21:45.39 | *** join/#brlcad docelic (n=docelic@212.15.176.65) |
| 22:39.29 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1096782634.dsl.bell.ca) |
| 22:57.03 | Maloeran | Exclusive games or ports? |
| 22:59.32 | ``Erik | software at all |
| 23:00.04 | ``Erik | http://www.lemon64.com/games/list.php?type=year&name=1999&submit.x=0&submit.y=0 |
| 23:11.19 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] |
| 23:16.38 | IriX64 | some lemon for your tequila ``Erik :) |
| 23:18.26 | Maloeran | 1999... We had 3d accelerated games and megabytes of RAM then, very surprising to see C64 games |
| 23:19.10 | Maloeran | Then again, some people in Efnet's #asm still write code for that platform, for some poorly defined reason |
| 23:19.34 | IriX64 | why is amigaos in config.sub? |
| 23:21.23 | IriX64 | likewise ibm370 ;) |
| 23:21.38 | IriX64 | mvs mmmmm |
| 23:26.15 | ``Erik | config.sub is a GNU provided file that supports an obscene # of os's |
| 23:26.35 | ``Erik | heh |
| 23:26.44 | ``Erik | I've had urges to write c64 asm in the last few months |
| 23:27.16 | ``Erik | it's good to understand the history |
| 23:27.48 | ``Erik | I also use hand-tools when I have equivelant powertools, and I cook things from scratch that I could buy pre-prepared at a restraunt or a grocers frozen section |
| 23:27.50 | ``Erik | *shrug* |
| 23:27.59 | ``Erik | c64 asm was fun... |
| 23:28.03 | ``Erik | x86 is anything but. |
| 23:28.38 | ``Erik | mips asm was fun, too... unfortunate that it didn't gain traction like that horrible intel klugefuck |
| 23:30.27 | Maloeran | amd64 & SSE is bearable |
| 23:31.33 | IriX64 | ``Erik i'm a pdp sort so I know what you speak of :) |
| 23:32.04 | ``Erik | the sse2 api is, uh, fugly? :) |
| 23:32.16 | ``Erik | I d'no what exactly the differences between amd64 and x86 are |
| 23:32.38 | IriX64 | both based on segments unfortunatly |
| 23:33.23 | Maloeran | Segments? Not quite |
| 23:33.25 | ``Erik | heh, x86 style segment addressing still boggles me... I mean, "toy" computers of the 80's had moved to paged addressing |
| 23:33.30 | bjorkBSD | a pdp sort? he's a COBOL programmer :O |
| 23:33.30 | IriX64 | SSE? elucidate ive been hiding from the industry for a while. |
| 23:33.35 | ``Erik | 70's, even |
| 23:33.42 | ``Erik | the c64 had sorta paged memory |
| 23:33.54 | IriX64 | heh picture this picture that :) |
| 23:33.56 | ``Erik | absolute wiht fixed size, but .... O.o not offset |
| 23:34.40 | Maloeran | Erik, I was wondering something. Why don't they make chips able to buffer, let's say, 4 threads per core... and whenever there's a cache miss, it switches execution to another thread until execution can continue? |
| 23:35.03 | ``Erik | uhh, I d'no? :D |
| 23:35.09 | Maloeran | I think it would be a fairly nice design, considering how cache misses are typically such a large bottleneck |
| 23:35.12 | ``Erik | feel free to patent the idea *cough* |
| 23:35.20 | Maloeran | Pft :p |
| 23:35.27 | ``Erik | just remember, silicon costs, and you're talking about doing that in silicon |
| 23:35.40 | bjorkBSD | common sand? |
| 23:35.48 | bjorkBSD | ... washed with common water? :P |
| 23:35.55 | bjorkBSD | the beach becons |
| 23:36.04 | Maloeran | Erik, it would simplify chip design on many other aspects |
| 23:36.07 | bjorkBSD | *k |
| 23:36.27 | ``Erik | mal: do you have a silicon emulator? |
| 23:36.28 | IriX64 | prefer quadruple cache 1=instructions current 2- instructions probable 3= data current 4=data probable. |
| 23:36.29 | Maloeran | They could focus on just having multiple cores processing a large buffer of threads, rather than trying desesperately to make one thread run as fast as possible |
| 23:36.39 | ``Erik | um |
| 23:36.49 | ``Erik | in school, I got a copy of "mmlogic" I think... |
| 23:36.53 | ``Erik | windows only |
| 23:37.05 | ``Erik | but building a pipelined gpu in it was ... educational |
| 23:37.09 | Maloeran | Whenever there's a resource bottleneck, such as cache misses, it could suspend the thread and move to another one |
| 23:38.09 | Maloeran | It would be an elegant way to keep all processing resources busy, while completely hiding the memory latency |
| 23:38.36 | ``Erik | but youd' be talking about building a full-up scheduler in silicon |
| 23:38.51 | Maloeran | Not a scheduler, just a small buffer of 4 threads per core |
| 23:39.13 | ``Erik | small, yes, but a scheduler... :D |
| 23:39.20 | Maloeran | Fine :p |
| 23:39.46 | ``Erik | and process scheduling is very much a non-solved aspect |
| 23:40.33 | Maloeran | Come on, this is simple. Whenever a thread hits a cache miss, or requires the FDIV unit blocked by another thread, just switch to the next one |
| 23:40.39 | ``Erik | unless you admit that the ingo O(1) scheduler jsut shoved in linux is no better than the ancient BSD 'fair use' scheduler... |
| 23:40.56 | ``Erik | WHICH next one? |
| 23:41.04 | Maloeran | Any other of its 4 threads! |
| 23:41.16 | IriX64 | and if they all block? |
| 23:41.19 | ``Erik | but which any? the one waiting for the result of the first? |
| 23:41.20 | Maloeran | The OS can do correct thread management, the chip will just try to keep its resources busy |
| 23:41.25 | ``Erik | the one waiting on the disk read? |
| 23:43.00 | IriX64 | could put in a deadman timer i guess Maloeran. |
| 23:43.01 | Maloeran | It doesn't have to be fancy at all, there's the OS to do all the careful and proper thread management |
| 23:43.38 | ``Erik | and what if it makes the kernel 1000x uglier to cope with the 2% speed boost? :D |
| 23:43.54 | ``Erik | dude, get a silicon simulator, try your idea out... if it works |
| 23:43.59 | ``Erik | fucking patent it and start a biz |
| 23:43.59 | Maloeran | The point is just to switch between multiple threads currently awaiting processing in order to nicely hide the memory latency, while keeping processing resources busy |
| 23:44.25 | Maloeran | Processing speed keeps increasing, memory is lagging behind, I think this is a solution to solve the issue |
| 23:45.33 | ``Erik | but I tend to use computers as data manipulators on large sets, not fast simple repetitive crunchers :) |
| 23:46.09 | Maloeran | Exactly, wouldn't you prefer to fully hide the horrible latency of accessing your large sets which are never in cache? :) |
| 23:46.21 | ``Erik | um |
| 23:46.32 | ``Erik | the data sets taht start to irk me are too big to fit in ram |
| 23:46.36 | ``Erik | and i have boxen with LOTS of ram |
| 23:46.37 | Maloeran | Multiple threads managed by the hardware really are the solution |
| 23:46.48 | ``Erik | I mean, my laptops have 2g a whack, they're tiny... |
| 23:46.57 | ``Erik | the boxes I "work" on are 8g and 32g |
| 23:47.03 | ``Erik | g as in gigabytes of ram |
| 23:47.13 | Maloeran | Fine, stop just loading data, and start doing some number crunching on it :) |
| 23:47.26 | ``Erik | but in grinding over 500gb of data, *shrug* |
| 23:47.53 | Maloeran | Bah. So it's not useful to you. You do see the point of the design, right? |
| 23:48.07 | ``Erik | my cpu's almost never cook up anything notable in 'user' cpu... :) |
| 23:48.36 | ``Erik | it could be useful, yeah... figure out the details, if it's really a win, patent it and make your zillion dollars |
| 23:48.50 | ``Erik | then you can 'retire' and do what you want instead of trying to make a living :) |
| 23:49.11 | ``Erik | heh |
| 23:49.18 | ``Erik | solve the problem of paying bills. |
| 23:49.19 | ``Erik | :D |
| 23:50.04 | ``Erik | I mean, if you push this 'interesting problem' and make a few million bucks, you can get away with never trying to "make money" ever again, right? |
| 23:50.30 | ``Erik | so you can focus on 'interesting' problems without worrying about rent or paying for lunch |
| 23:50.31 | ``Erik | no? |
| 23:50.43 | Maloeran | Designing a chip to take on AMD is not something I can do alone within a reasonable time frame |
| 23:51.15 | ``Erik | a defendable patent can be sold to the likes of amd *shrug* |
| 23:51.26 | Maloeran | Anyway, I think the ideas are good if anyone here likes gazillion stuff |
| 23:52.22 | dtidrow_work | got a question for you all - which linux file system is best for handling lots of files in a single directory? |
| 23:53.37 | dtidrow_work | and that's available on linux? |
| 23:54.00 | Maloeran | dtidrow_work, reading, writing, creating or deleting many files? |
| 23:54.09 | ``Erik | but my 'big' dir is only 13000 files |
| 23:54.17 | dtidrow_work | reading atm |
| 23:54.24 | ``Erik | no, ufs is a UNIX fs, default for freebsd O:-) |
| 23:54.31 | Maloeran | Then reiser4 |
| 23:54.45 | dtidrow_work | is it actually available? |
| 23:54.54 | dtidrow_work | thought it was still 'beta' |
| 23:55.26 | Maloeran | Ah yes, that's probably right... Reiser3 is in the kernel sources though, of coursee |