Larrabee delayed: anyone know what's happening?
|
Prev: PEEEEEEP
Next: Texture units as a general function
From: Bill Todd on 24 Dec 2009 18:51 Andy "Krazy" Glew wrote: .... > At the moment my newsreader (I switched back to Thunderbird from > Seamonkey) is my only non-cloud based app. The only app that ties me to > a particular machine, which I cannot use when that machine is not > around. You do know that you can place TBird's data (it's 'profile') anywhere (e.g., somewhere in the cloud) such that you can use it from anywhere you can run a (compatible) copy of TBird, right? - bill
From: "Andy "Krazy" Glew" on 24 Dec 2009 21:15 Bill Todd wrote: > Andy "Krazy" Glew wrote: > > .... > >> At the moment my newsreader (I switched back to Thunderbird from >> Seamonkey) is my only non-cloud based app. The only app that ties me >> to a particular machine, which I cannot use when that machine is not >> around. > > You do know that you can place TBird's data (it's 'profile') anywhere > (e.g., somewhere in the cloud) such that you can use it from anywhere > you can run a (compatible) copy of TBird, right? > > - bill 1) I did not know that. Thanks, I will look into it. However 2) It doesn't help me, since I really want to read news from a machine that has nothing like Tbird installed on it. There are Javascript systems that can run tty apps in a browser window. I'm not aware of any way to run Tbird on machine 1 from a browser on machine 2. Am I missing that? Is there a non-X way of running Tbird?
From: Robert Myers on 24 Dec 2009 21:46 On Dec 24, 6:43 pm, Bill Todd <billt...(a)metrocast.net> wrote: > Andy "Krazy" Glew wrote: > > Robert Myers wrote: > >> I can't see anything about channels that you can't do with modern PC I/O. > > > AFAIK there isn't much that IBM mainframe channels could do that modern > > PC I/O controllers cannot do. Even a decade ago I saw SCSI controllers > > that were more sophisticated than IBM channels. > > I may be missing something glaringly obvious here, but my impression is > that the main thing that channels can do that PC I/O controllers can't > is accept programs that allow them to operate extensively on the data > they access. For example, one logical extension of this could be to > implement an entire database management system in the channel controller > - something which I'm reasonably sure most PC I/O controllers would have > difficulty doing (not that I'm necessarily holding this up as a good > idea...). > > PC I/O controllers have gotten very good at the basic drudge work of > data access (even RAID), and ancillary DMA engines have added > capabilities like scatter/gather - all tasks which used to be done in > the host unless you had something like a channel controller to off-load > them. But AFAIK channels they ain't. > So, let's see. I'm still just trying to get at the heart of the matter. I could (and did) hang a complete 32-bit processor off a PC/XT bus. The 32-bit processor (which was a single board computer), depended on the host OS for I/O. If I used concurrent DOS, I could do whatever I wanted on the host 8-bit computer while the 32-bit mini ground away on problems formerly done at great expense on a Cray. Which was the channel? Why should I care? The most natural way of looking at it (as you describe things) is to think of the "host" PC, which was utterly programmable, as a mainframe channel, except that it cost hundreds of thousands of dollars less and didn't come with that priceless baby-blue logo. Where's the magic? Or am I (as usual) dealing with people who have drunk someone's Kool-Aid? How did DEC do similar things? Mainframes and obscure JCL forever (not). Robert.
From: Del Cecchi on 24 Dec 2009 23:51 "Robert Myers" <rbmyersusa(a)gmail.com> wrote in message news:2ae6c5da-2d23-4a46-bdcc-87bf102f196e(a)27g2000yqr.googlegroups.com... On Dec 24, 8:33 am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > Robert Myers wrote: > > On Dec 23, 12:21 pm, Terje Mathisen<"terje.mathisen at tmsw.no"> > >> Why do a feel that this feels a lot like IBM mainframe channel > >> programs? > >> :-) > > > Could I persuade you to take time away from your first love > > (programming your own computers, of course) to > > elaborate/pontificate a > > bit? After forty years, I'm still waiting for someone to tell me > > something interesting about mainframes. Well, other than that IBM > > bet > > big and won big on them. > > > And CHANNELS. Well. That's clearly like the number 42. > > Del have already answered, but since I know far less than him about > IBM > systems, I'll try anyway: > > As Del said, an IBM mainframe has lots of dedicated slave > processors, > think of them as very generalized DMA engines where you can do stuff > like: > > seek to and read block # 48, load the word at offset 56 in that > block > and compare with NULL: If equal return the block, otherwise use the > word > at offset 52 as the new block number and repeat the process. > > I.e. you could implement most operations on most forms of diskbased > tree > structures inside the channel cpu, with no need to interrupt the > host > before everything was done. > Thanks for that detailed reply, Terje. I tend to think there is something important I am still missing. Maybe my lack of appreciation of mainframes comes from never having been involved in the slightest with the history, except briefly as a frustrated and annoyed user. I can't see anything about channels that you can't do with modern PC I/ O. You send "stuff" to a peripheral device and it does something with it. It's generally up to the peripheral to know what to do with the "stuff," whatever it is. In the case of a TCP/IP offload engine, the what to do could be quite complicated. The things you *can't* do mostly seem to have to do with not doing I/O in userland, so that the programmability of anything is never exposed to you unless you are writing a driver. Is that the point? With a mainframe channel, a user *could* program the I/O devices, at least to some extent. Sorry if I seem obtuse. Robert. And there isn't anything the wright brothers could do with their plane that you couldn't do with a cessna.
From: Mayan Moudgill on 25 Dec 2009 00:29
Bernd Paysan wrote: > > Sending chunks of code around which are automatically executed by the > receiver is called "active messages". I'm not so sure. The original Active Messages stuff from Thorsten von Eicken et.al. was more like passing a pointer to a user space interrupt handler along with an inter-processsor message, so that the message could be handled with zero-copies/low-latency (OK, it wasn't always quite that - but its close in flavor). The interrupt handler code was already resident on the processor. I've never heard of pushing code for execution on another processor being called "active messages" - citations? references? |