Jihad needs scientists
in [Design]
|
From: Phil Carmody on 20 Feb 2007 07:21 kensmith(a)green.rahul.net (Ken Smith) writes: > >However, the task in hand is an LLL which basically has n^3 > >written all over it. You're always doing everything with > >everything. > > "LLL" ???????????? > > I assume the interactions are nonlinear too. This makes near imposible to > find a different attack on the data. Lenstra-Lenstra-Lovasc. It's a way of finding a very short vector that is a linear combination of the vectors in a matrix. If you've every done Gramm-Schmitt ortho-normalisation, it's like that but you have to do it over and over again. If each entry is a million digits long, and you've got a 25*25 matrix, that's a horribly large amount of data. Fortunately my footprint has just shrunk (the numbers decrease in length as you work towards a solution), I'm down to 420MB, and I'm not swapping any more. Of course, I couldn't run a second process without interfering, but we've already been there... > > You can't 'block' in the conventional matrix > >algorithm sense, but you can work on nearby vectors (you > >have to do the whole vector, and can't do much else until > >you've done it, and don't even know what you'll be doing > >next until you've done it). > > This sounds like one of those "raster to vector" conversion sorts of > tasks. In them, you need to follow the color boundary. Except every point in the grid needs to be touched eventually. It might be worth creating a simple genetic algorithm for finding the best way of performing X_i op X_j for every i,j pair such that only M out of the N total of the Xs can be held in main memory. (s/main memory/cache/ for another application.) Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: jmfbahciv on 20 Feb 2007 07:15 In article <ercptu$8qv$8(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <ercame$8qk_003(a)s942.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <era4fu$tvp$8(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <er9e30$8ss_001(a)s1005.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>[....] >>>>>"another window" won't do because the term window is used for a part of >>>>>what is on the screen. >>>> >>>>If I understand what you are talking about, on our OS, we would have >>>>used the term job. >>> >>>That doesn't cover it either. >> >>With our use of the terminology, it does. > >In that case your use of terminology is very strange and obviously wrong. Nope. You simply do not understand what I'm talking about. >On a linux box, you can have many jobs and many desk tops but there need >be no relationship between the two. I know. > On my PC at work, it is common for >there to be a job that has no screen I/O involved at all. I know. > There are may >also be several jobs outputting on one screen. I know. > > > >>> I can have many-many jobs going with their >>>outputs if any displayed on one desktop and run some others from another. >> >>Our first try at doing this on an ASR35 was with a program we called >>OPSER. Later its functionality was replaced with a program we called >>OPR and each of your tasks were run from a PTY (pseudo-TTY). >> >>Our users could also use the commands ATTACH and DETACH which >>is the equivalent of your point-clicks on the thingies you call >>desktop. > >I know about attach and detach. I can run command line things and have >the outputs from them also on a desktop. In many cases, they will have >different windows to send their results to. Sure. That is possible to do with a video device. It was not with hardcopy. /BAH
From: Eeyore on 20 Feb 2007 08:08 jmfbahciv(a)aol.com wrote: > Eeyore <rabbitsfriendsandrelations(a)hotmail.com> wrote: > >jmfbahciv(a)aol.com wrote: > >> The Ghost In The Machine <ewill(a)sirius.tg00suus7038.net> wrote: > >> > > >> >http://www.youtube.com/watch?v=xhd2lnCTWQM > >> > > >> >skipped horribly on initial load, but that looks to be > >> >more of a bandwidth problem than a CPU one. CPU utilization was > >> >slightly lower. > >> > > >> >SFW. Its main themes are apparently music, a school > >> >bus, and dancing. Replay was possible without skipping. > >> >Full screen utilized almost 90% of CPU, so that might be > >> >an issue. > >> > > >> >FWIW. > >> > > >> If this becomes a common usage, it sounds like a dedicated > >> processor will be installed. > > > >It's called the CPU. > > The C in CPU is central. This doesn't mean specialized. Today's CPUs have multimedia instructions dedicated to such tasks. A specialised processor would nee to 'know' of all the possible decompressors required. That's simply not practical. Graham
From: jmfbahciv on 20 Feb 2007 08:02 In article <ercn84$8qv$2(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <ercd8o$8qk_006(a)s942.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <era1en$tvp$2(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>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. >> >>Oh, good grief!!!! NOOOO! Never. All a compiler can >>do is range-check the static stuff. It can never range >>check the values that change as a result of execution. > >The [BP+N] construct contains the "N" part that never ever changes and the >BP part that is a known place in the stack. The entry code to a procedure >has a MOV BP,SP instruction followed perhaps bay a change to SP to make >room for the variable. From that point on there is a known relationship >between BP and the location of all parameters and variables. > > >>> 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. >> >>Son, you are not paranoid enough. > >No, I know when to be paranoid. The [BP+N] is a waste of a single noid. ROTFL. Not in my work. I used make byte pointers on the fly all the time. /BAH
From: jmfbahciv on 20 Feb 2007 08:06
In article <87abz9kp2r.fsf(a)nonospaz.fatphil.org>, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >The Ghost In The Machine <ewill(a)sirius.tg00suus7038.net> writes: >> In sci.physics, Ken Smith >> <kensmith(a)green.rahul.net> >> wrote >> on Mon, 19 Feb 2007 19:01:38 +0000 (UTC) >> <ercs6i$dg2$3(a)blue.rahul.net>: >> > In article <45D9BDD4.B68B994E(a)hotmail.com>, >> > Eeyore <rabbitsfriendsandrelations(a)hotmail.com> wrote: >> >> >> >> >> >>jmfbahciv(a)aol.com wrote: >> >> >> >>> The Ghost In The Machine <ewill(a)sirius.tg00suus7038.net> wrote: >> >>> > >> >>> >http://www.youtube.com/watch?v=xhd2lnCTWQM >> >>> > >> >>> >skipped horribly on initial load, but that looks to be >> >>> >more of a bandwidth problem than a CPU one. CPU utilization was >> >>> >slightly lower. >> >>> > >> >>> >SFW. Its main themes are apparently music, a school >> >>> >bus, and dancing. Replay was possible without skipping. >> >>> >Full screen utilized almost 90% of CPU, so that might be >> >>> >an issue. >> >>> > >> >>> >FWIW. >> >>> > >> >>> If this becomes a common usage, it sounds like a dedicated >> >>> processor will be installed. >> >> >> >>It's called the CPU. >> > >> > It could also be "a CPU". Multiprocessor systems may start to happen >> > soon. >> >> Multiprocessor systems have been around for awhile. >> My Kayak XM600 is dual-processor-capable -- this back when >> 833 MHZ Pentiums were the norm. > >I shudder to think how old my dually celeron 300 is. And that's >not just "capable", that's populated. > >The reason almost all PCs aren't dually is not because PCs >can't be dually, it's because that's what the market wants. That's not the reason. Devices aren't multi-ported. To have an effective multi-CPU general purpose system, all CPUs should have hardware access to all devices. Another limitation is no PC systems are sold that can have multiple ttys connected to it. > >Those who strive for more than mediocrity in their PC have >been able to find duallies quite easily for a decade. But are the device drivers reentrant? If they aren't, the multi-CPU systems aren't as useful as they could be. /BAH |