| 00:45.51 | *** join/#brlcad docelic (n=docelic@212.91.112.196) | |
| 06:09.53 | louipc | yeah you'd need more bandwidth than that for 8 cores definitely |
| 06:16.43 | Maloeran | It's ridiculous, I think my old Pentium ( 1995 ) has that much bandwidth to main memory |
| 06:18.52 | Maloeran | Oops it wasn't double-rate though. Okay, it has half that bandwidth |
| 06:19.40 | louipc | my current system does that anyways and it's 6 yrs old |
| 06:20.02 | louipc | I'm thinking of getting a core 2 duo |
| 06:21.42 | Maloeran | I'm thinking I'll wait AMD's Barcelone chips next, far superior memory archtiecture |
| 06:21.46 | Maloeran | architecture, rather |
| 06:29.44 | louipc | oh they're going 128-bit already? |
| 06:30.07 | Maloeran | Eh? No, there's no way we'll ever exceed a 64 bits addressing space :) |
| 06:30.36 | Maloeran | I mean it scales properly with the amount of cores, distinct memory banks and bus |
| 06:30.40 | louipc | ok I just read something in a news article hah |
| 08:28.10 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 09:53.15 | CIA-5 | BRL-CAD: 03d_rossberg * 10brlcad/src/other/libz/libz.dsp: |
| 09:53.15 | CIA-5 | BRL-CAD: needed for win32-msvc runtime libraries branch |
| 09:53.15 | CIA-5 | BRL-CAD: example.c doesn't belong in the library |
| 09:57.33 | CIA-5 | BRL-CAD: 03d_rossberg * 10brlcad/ (5 files in 5 dirs): include libtcl header files |
| 09:58.53 | CIA-5 | BRL-CAD: 03d_rossberg * 10brlcad/src/librt/librt.dsp: include libtcl and libz header files |
| 10:00.11 | CIA-5 | BRL-CAD: 03d_rossberg * 10brlcad/src/other/openNURBS/opennurbs.dsp: include libz header files |
| 11:11.32 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 15:57.48 | ``Erik | no way we'll ever exceed a 64b addressing space? hmmmm, kinda like 640k should be enough for anyone? :D |
| 15:59.02 | Maloeran | 18 million tetrabytes? There's a physical problem, we need enough atoms to contain the information |
| 15:59.34 | ``Erik | 18m? my computation says that unsigned would be 16 exabytes... |
| 16:00.21 | Maloeran | Err, not the zeroes, the digits |
| 16:00.22 | ``Erik | I typed 2^64, copied the number into units, then asked |
| 16:00.23 | ``Erik | :) |
| 16:00.49 | archivist | just wait 6 months for the ram to appear on the market and 5 months for microsoft to need more |
| 16:02.19 | ``Erik | and if ya had one molecule for every bit, you'd still have 4080 2^64 spaces in one avagadro's number |
| 16:07.19 | ``Erik | and a mole of copper is 63.55 grams |
| 16:08.20 | ``Erik | err, wait, sorry, 2^128, rather |
| 16:08.46 | ``Erik | dangit, now I went and confused myself |
| 16:10.22 | archivist | hmm is that too heavy for my laptop |
| 16:10.25 | ``Erik | hm, mebbe 68 bit instead |
| 16:48.12 | Maloeran | "[...] desire to run very fast would preclude distributed/network processing ... no?" What have you guys done for managers to think that distributed processing == slow? :) |
| 17:58.33 | ``Erik | where'd you read that? |
| 18:01.50 | Maloeran | Mark's reply about distributed processing for their fire modelling |
| 18:02.43 | ``Erik | hm, I can name two projects here that you've heard about that are distributed, extremely slow, and virtually non-scalable. |
| 18:03.13 | Maloeran | Eheh, I thought so |
| 18:03.53 | ``Erik | imho; both use tiny work quanta and poor aggregation techniques. |
| 18:04.14 | ``Erik | they're "chatty", too |
| 18:05.33 | Maloeran | I'm just amused by the assumption that distributed processing would make things slower. Why would we distribute processing if it weren't for speed? :) |
| 18:06.16 | ``Erik | distributed processing induces overhead, if you don't keep it in mind, you actually do get software that runs slower :) |
| 18:06.27 | ``Erik | which is why the production one is usually run serially |
| 18:23.46 | ``Erik | hm, my escape key is sticking :( |
| 18:34.58 | Maloeran | fell* |
| 18:39.41 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/ (4 files in 3 dirs): unmagic some numbers |
| 22:27.31 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1096781862.dsl.bell.ca) | |
| 22:47.33 | *** join/#brlcad IriX64 (n=IriX64@bas3-sudbury98-1168057882.dsl.bell.ca) | |
| 22:48.22 | *** part/#brlcad IriX64 (n=IriX64@bas3-sudbury98-1168057882.dsl.bell.ca) | |
| 23:40.10 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/libpng/Makefile.am: |
| 23:40.10 | CIA-5 | BRL-CAD: either PNG_NO_MMX_CODE or PNG_NO_ASSEMBLER_CODE are required for successful |
| 23:40.11 | CIA-5 | BRL-CAD: compilation on AMD64 Linux with gcc due to linking of 32-bit assembly with |
| 23:40.11 | CIA-5 | BRL-CAD: 64-bit object files. compiling with -m32 avoids the problem but just tack on |
| 23:40.11 | CIA-5 | BRL-CAD: PNG_NO_MMX_CODE for now since that doesn't limit compilation/features like the |
| 23:40.13 | CIA-5 | BRL-CAD: other two options. should probably test for this mix in configure and set some |
| 23:40.44 | CIA-5 | BRL-CAD: cppflags accordingly. |