Ed Gould wrote: > Never heard of it so I guess it, that doesn't mean it never existed > just an extremely small audience. I don't recall ever hearing > anything about VF . I would expect if it were popular that there > would be a current model, no? > > I am guessing that VF stands for vector facility (?). I don't recall > seeing PTF's for it. So either it was extremely small install base or > the code IBM didn't have bugs? > > I used the scan PTF cover letters and don't recall any mention of > it. My memory is far from perfect, but chance are I would have read > (or heard from a GUIDE/SHARE presentation of it).
a few past posts that mention 3090vf: http://www.garlic.com/~lynn/2000c.html#61 TF-1 http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC http://www.garlic.com/~lynn/2005m.html#20 simd for 390(or z990)? http://www.garlic.com/~lynn/2006m.html#4 The Power of the NORC supposedly one of the benefits of vectors is to increase the rate the floating point unit(s) is feed to keep it constantly busy ... not stalling waiting for memory fetches or other delays. claims have been that various kinds of optimization in instruction fetching and other optimization can improve scalar floating point ... such that floating point unit can be kept busy w/o requiring vectors. bugs would have tended to be related with program loading/use of the vector registers, mostly fortran ... although there may have been a performance optimization in virtual machine support about whether a virtual machine was enabled for vector facility or not ... and whether vector registers had to be saved and/or restored. from long ago and far away ... Date: 03/04/85 19:01:52 From: wheeler Regarding vector: For the past two months we have been working on (and have now completed) the Objectives for VM/XA SP Release 1. (Terminology update: VM/XA Migration Aid releases 3 and 4 have become VM/XA Systems Facility releases 1 and 2; the next thing after that is VM/XA SP Release 1.) VM/XA SP Release 1 is currently planning to support vector. XXXXXX owns the design of the vector line item and I own the design of the dispatcher. Dispatcher will be changed to: (1) Have some flavor of a true runlist to reduce overhead. (Though part of the overhead that yyyyyy sees here will tend to disappear naturally when other problems in the system are fixed... such as avoiding putting excessive users in the dispatch list.) (2) Have a "soft affinity" capability. Users should tend to get dispatched on the same processor on successive dispatches to reduce cache interference. (3) Have a "hard affinity" capability. This is so a user can be assigned to always run on the same processor or subset of processors. For example, when the user needs vector and not all processors in the system have it. The question quickly comes up, how will vector be supported? Since it could be costly to dispatch someone using vector, do you allow everyone to use it, or just authorized users? And do you allow just one vector user into the dispatch list at a time, or do you allow everyone in? We are currently leaning strongly toward letting anyone use it (no authorization), and letting everyone into the dispatch list at once. There are two reasons why it seems we will be able to get away with that: (1) With the existing VM/XA design it seems that we will be able to bill the extra dispatching overhead to the guilty user... that is, it will be stolen from his problem state time, and will not be felt by other users. (2) I am told by XXXXXX that the hardware keeps reference (and/or) change status on the various vector registers, therefore when a vector user is dispatched repeatedly (as when he is swapping in his working set) the vector overhead won't be so bad because we only have to save/restore the part that was used. At least that is the theory... I'm not knowledgeable about vector, I get all my information from XXXXXX. A while back though XXXXXXX said the hardware may initially not have all the reference/change stuff implemented... so maybe our initial support will be more limited than I've indicated. ... snip ... past posts in this thread: http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs http://www.garlic.com/~lynn/2007.html#33 Just another example of mainframe costs http://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
