Jihad needs scientists
in [Design]
|
From: krw on 18 Feb 2007 10:10 In article <er9fag$8ss_012(a)s1005.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <MPG.20414665b9b9f85a989fac(a)news.individual.net>, > krw <krw(a)att.bizzzz> wrote: > >In article <87wt2gr3fq.fsf(a)nonospaz.fatphil.org>, > >thefatphil_demunged(a)yahoo.co.uk says... > >> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> writes: > >> > On 17 Feb 2007 15:15:20 +0200, Phil Carmody > >> > <thefatphil_demunged(a)yahoo.co.uk> Gave us: > >> > > >> > >I'm currently running a 500MB LLL reduction on my G5 with 512MB RAM. > >> > >I have 72 such reductions to perform. Care to tell me how I could run > >> > >all 72 without any of them interfering with the other? Or even 2. > >> > > >> > > >> > Run one on one CPU and one on the other. > >> > > >> > I used to with SETI at home all the time, and it most certainly DOES > >> > double the number of units a day that machine churned out. > >> > > >> > If you only have a single CPU machine, however, you will not be able > >> > to do this. > >> > > >> > I have been running dually machines (at the personal level) for over > >> > 6 years now. They are awesome! > >> > >> You can't fit 2 500MB jobs into 512MB of RAM. > >> > >> I am a big fan of the dual G5s too. > > > >Me too. The G5 program paid my mortgage for five years. ;-) > > Did it do windows? <GRIN> Of course not! (OTOH, I've never touched a Mac, so...) -- Keith
From: krw on 18 Feb 2007 10:16 In article <er9eg3$8ss_003(a)s1005.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <87mz3csv1x.fsf(a)nonospaz.fatphil.org>, > Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > >jmfbahciv(a)aol.com writes: <snip> > >> This is not a new concept; it's > >> been around since females had to cook, rear kids, and entertain > >> the males so they would stick around for a while. > > > >Females do not have to do that. > > You have a lot to learn. This is obvious by his attempt to tell a female what they don't have to do. Any male over 18 with a normal IQ would *never* make a dumbass statement. Phil, here's your sign. -- Keith
From: Ken Smith on 18 Feb 2007 12:12 In article <er9ick$8qk_008(a)s1005.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <er91e0$ji1$1(a)jasen.is-a-geek.org>, > jasen <jasen(a)free.net.nz> wrote: [..... [BP+N] addressing ....] >>> Snort. Don't you just love that "appropriate values of N"? >>> It implies you have to check it each and every time. >> >>means you have to make room on the stack (where BP offsets >>are typically used) for the counter. > >Now think. You either have to use software to check out of >range or have hardware that will cough at you when you >do go out of range. It is usually software that does it at compile time. If you are writing in assembly, you allocate the space and assign the symbols once and then use them in each place. Unless you do something veery stupid, there is no need to run time check such stuff. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 18 Feb 2007 12:29 In article <er9kr0$8qk_001(a)s1005.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <er4fl1$1ln$3(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <er48ge$8qk_001(a)s897.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <er1rfs$rie$2(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>[....] >>>>I know you can't view the web. The links point to some cute devices that >>>>are nothing like the channel controllers on the IBM360. One does wonder >>>>why MissingProng would have included them in his post. >>> >>>Hardware is not my area of expertise. Our computing biz had started >>>to manufacture "smart" controllers in the early 80s. I still have >>>mixed feeling about offloading that into the controllers. However, >>>the fad was distributed processing at the time and that was one >>>way to distribute it. >> >>The idea of moving the donkey work of file I/O onto some other processor >>is a sound one. > >That depends on how long the main frame has to wait to receive >the bits. Somehow, shoving a 36-bit-based file data through >a processor that is 12-bits doesn't seem quite the way to >improve disk I/O throughput. Think about water going from a >5" pipe into a 2" pipe; the only efefct will be to slow the >water flow drastically. But the 12 bit processor is like a 2" pipe with a billion PSI pump on it. The processors specifically designed to do I/O fast leave a general purpose machine in the dust on this one task. They really suck at doing a matrix inversion however. >> The processor needed to manage I/O can be a much simpler >>one. > >You are confusing an application with the OS. It is the >application that needs simple interfaces; No, I am not. You don't have much experience with hardware. The processor designed for doing I/O won't have a floating point unit, it may not have a normal divide instruction if any, it may have a slow multiply. These all yeld a simpler processor. On the oother hand, its I/O instructions may be able to do multiple I/Os per instruction. > it is the OS' business >to feed the apps bits at the rate those apps require. If the >OS if forced to wait for an uncontrollable channel CPU, everybody, >including the CPU, will be in I/O wait state all the time. You have this dead wrong. The channel controller prevents the CPU in a multitasker from having to wait on the I/O operations. The main CPU decides what I/O needs to be done for a given task, launches it and then can go do other tasks without interruption until the controller is done or discovers trouble. This means that there is way less overhead. > >> The data can be DMA transfered into a shared RAM area or moved to >>the main RAM when the process is complete. This means that no bus cycles >>on the main CPU's bus are wasted on managing the operation. > >Fine. Now how does the CPU "learn" about the format of those bits? This happens the same way as it does on a CPU that does I/O without help. In fact, it is the programmer that specifies the meanings of bits. All the computer does is defined operations on bits. >How does the CPU ensure that the bits of the bytes are in the >correct order? The same way as always. > It can't control the CPU that feeds it. It tells it what to do. That is all the control needed. > The OS >developer cannot have any influence if the software dveloper >of the controller is braindead. A channel controller wasn't a fixed program machine. It was a CPU that took instructions. You haven't understood the issue. >>The idea doubly makes sense when you have a multitasking OS and a >>pipelined CPU. If you can avoid the extra interrupts at the CPU, you can >>prevent disk I/O from seriously slowing other tasks. > >You are thinking like a PCer again. No, I'm thinking like someone who knows hardware and assembly language. In a pipelined machine, the less changes in code flow needed to do the job the better. An extra interrupt here and there will slow things down a lot. [....] >Until coding is less expensive than hardware, nobody will have >any incentive to turn out efficient code. At teh extreme high end, hardware becomes very costly. This is where the breakthroughs in compilers etc are likely to come from. >>We seem to differ about what a breakthrough is. I see what has been >>happening as just more of the same. Even the idea of a dual core machine >>has been around for a long time. A breakthrough would be something >>totally different. The Transputer comes to mind as an example of the sort >>of difference I'm thinking of. > >If there is a breakthrough on the hardware side, there will be no >incentive to work the performance of the software. If the new hardware introduces some totally new model like the transputer did, there will be a lot of coding needed just to be able to use the new hardware. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 18 Feb 2007 12:42
In article <er9g3l$8qk_001(a)s1005.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <er7am7$ijh$1(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [.....] >>When coding your own DOS serial handler, you usually can turn off the FIFO >>in the UART and have the software continue to work normally. The >>exception is in some laptops where for some silly reason there is code >>that turns the interrupts off while it fiddles with the LCD. > >Oh, bletcheroo. Some days you need an interrupt for the interrupt handler. >My guys struggled with hardware guys quite a bit. It was >a huge breakthrough when the hardware designers began to use >computers for their work. You could fix the problem on most laptops by taking over the timer tick interrupt. The LCD fiddling code was run from it. If you didn't let it happen nothing would break. >>>> The delay under XP >>>>appears more random. >>> >>>It's not random (from the gut feels I'm getting from your description). >> >>I is likely it is not really random. The rule isn't "every N characters" >>or "every n milliseconds" as far as I can see. It is likely based on a >>combination of numbers of milliseconds. > >Nope. I don't see it as that. It sounds a lot like a memory >spillover. No, you have misunderstood the problem. It is timing not data that you should be thinking about. Assume all the right bits get to all the right places but that they wait until the next tuesday that is a full moon to do so. >>The FIFO inside the UART is 16 bytes long. The next FIFO action is done >>by some OS code. Eventually 99,999 of every 100,000 characters do make it >>to the end application. We are not talking about a case where the bulk of >>the data is lost. The problem is that the OS is sticking a delay in the >>characters getting to the application of up to 5 seconds. > >But 5 second is a millenium in computing lifetime terms. Are you sure >it doesn't start over from the beginning? That would explain that >humungous 5 seconds. I'm am very sure that it is the right bytes in the right order just way late. Actually, about one in 100,000 bytes gets lost. This is a problem with Windows not getting to the UART before the byte gets over written by new ones. >>We don't really have any options on adjusting stuff. This is an XP system >>you have to write a bunch of windows code if you want to be able to change >>anything about how serial ports work. > >There isn't a twiggle deep in the dark ruts of menus? There has >to be. The guys who write that stuff would include those kinds >of toggles. The guys who write Windows hide everything they can lest someone change it. > >/BAH -- -- kensmith(a)rahul.net forging knowledge |