Why does Intel favor thin rectangular CPUs?
|
Prev: 128316 Computer Knowledge, Free and alwqays Up to Date 59
Next: Fwd: Different stacks for return addresses and data?
From: "Andy "Krazy" Glew" on 3 Mar 2010 02:30 Terje Mathisen wrote: > Robert Myers wrote: >> From that experience, I acquired several permanent prejudices: >> >> 1. For scientific/engineering applications, "programmers" should >> either be limited to sorting and labeling output, or (preferably) they >> should be shipped to the antarctic, where they could be sent, one at a >> time, to check the temperature gauge a quarter mile from the main >> camp. >> >> 2. No sane computational physicist should imagine that even a thorough >> knowledge of FORTRAN was adequate preparation for getting things done. >> >> 3. Computer architects are generally completely out of touch with >> reality. > > Hmmm... let's see... > > 1. I'm a programmer, but otoh I do like xc skiing and I would love to be > able to spend a season in Antarctica. > > 2. I learned programming on a Fortran 2 compiler, '27H' Hollerith text > constants and all. I've done CFC (computational fluid chemistry) > optimization, doubling the simulation speed. > > 3. Yes, my employer tend to put me in the 'Architect' role on the staff > diagrams. > > So Robert, do I satisfy your prejudices? Hey, I fill all the same criteria that Terje does. Does that mean we can both go spend a season in Antarctica? My telemarking will improve. (One of the big disappointments of my life is that it is not typical for programmers to work in isolated places, like on top of volcanoes.)
From: nmm1 on 3 Mar 2010 04:18 In article <hmkbb6$edp$1(a)news.eternal-september.org>, nedbrek <nedbrek(a)yahoo.com> wrote: >> >> All that is needed is four things: >> >> 1) Produce low-power (watts) designs for the mainstream, to >> enable the second point. >> >> 2) Put the memory back-to-back with the CPU, factory integrated, >> thus releasing all existing memory pins for I/O use. Note that this >> allows for VASTLY more memory pins/pads. > >I'm afraid I don't see what a low power core has to do with faster DRAM. A >big core likes fast DRAM too... Not faster DRAM - back-to-back chips. You can no longer have a damn great copper plate fixed directly onto the CPU chip (though there are things you can do). Without cutting the power, a CPU chip HAS to be separate, for cooling reasons. >Also, what do you mean by factory integrated? On one die? Also, ala >Mitch's suggestion, is this the only memory in the system? One package. You make two chips and fix them together (perhaps with a copper cooling grid in between) more-or-less in the fab. The pads can then be VERY small, because you can align down to the 10 micron (perhaps micron) level, so you can get a huge number of memory pins and hence a huge bandwidth (WITHOUT a huge frequency). It would be the only "memory-like" memory - there might be "disk-like" ECS elsewhere, but that would NOT have word or cache line access (only page) and would NOT be fully coherent. Yes, Mitch and I are talking about similar approaches - as are the Wheelers - this is long-established technology. Incidentally, you use ECS for file caches, in-memory paging and swapping, and so on. You could even remove I/O from the CPU proper and take it off the ECS, though that increases latency; it's a detail that the architects would decide. >> 3) Lean on the memory manufacturers to deliver that, or buy up >> one and return to that business. > >The DRAM manufacturers are very conservative. You must be very persuasive >with them. Also, their margins are razor thin (many are propped up by >government subsidies). Your suggestions must be cost neutral, and >applicable to 100% of the market. Sorry, but that's nuts. You are saying that no change is possible. Well, I am too old and experienced to believe in that. The matter is simple economics. Yes, this memory would cost extra, initially, just like FB-DIMM - but that would change if it took off. If you start with the assumption that no change is possible in one area, you often end up with the conclusion that no change is possible in another. Well, all that really means is that incremental change isn't possible, and a revolution is needed. Do you remember the days of "mainframes will rule forever", based on the same arguments? >> 4) Support a much simpler, fixed (large) block-size protocol to >> the first-level I/O interface chip. Think HiPPI, taken to extremes. > >I'm not familiar with HiPPI. The Wikipedia page has very little content, >and the FAQ off there is not responding... You don't need to be. Consider a very simple protocol, that doesn't attempt to be all things to all men, and uses a decent size block to transfer. There have been hundreds of such things in the past. The point in the above is that NONE of it is new, and all I have proposed is putting together proven effective technology. Doing so increases BOTH the memory and I/O bandwidths by factors of 10-100, for no cost in power (watts) or production costs. Yes, it costs, but not in those! I.e. it would much better parallel (aggregate) performance, but worse serial performance. Hence the problem is marketing. Regards, Nick Maclaren.
From: nmm1 on 3 Mar 2010 04:20 In article <4B8E100F.8060203(a)patten-glew.net>, Andy \"Krazy\" Glew <ag-news(a)patten-glew.net> wrote: >Terje Mathisen wrote: >> Robert Myers wrote: >>> From that experience, I acquired several permanent prejudices: >>> >>> 1. For scientific/engineering applications, "programmers" should >>> either be limited to sorting and labeling output, or (preferably) they >>> should be shipped to the antarctic, where they could be sent, one at a >>> time, to check the temperature gauge a quarter mile from the main >>> camp. >>> >>> 2. No sane computational physicist should imagine that even a thorough >>> knowledge of FORTRAN was adequate preparation for getting things done. >>> >>> 3. Computer architects are generally completely out of touch with >>> reality. >> >> Hmmm... let's see... >> >> 1. I'm a programmer, but otoh I do like xc skiing and I would love to be >> able to spend a season in Antarctica. >> >> 2. I learned programming on a Fortran 2 compiler, '27H' Hollerith text >> constants and all. I've done CFC (computational fluid chemistry) >> optimization, doubling the simulation speed. >> >> 3. Yes, my employer tend to put me in the 'Architect' role on the staff >> diagrams. >> >> So Robert, do I satisfy your prejudices? > >Hey, I fill all the same criteria that Terje does. > >Does that mean we can both go spend a season in Antarctica? My telemarking will improve. > >(One of the big disappointments of my life is that it is not typical for programmers to work in isolated places, like on >top of volcanoes.) As do I, except that I used Fortran II as my second language, and don'e have the health to handle Antarctica (or extended telemarking, though I could do a fair amount, for a Brit). And I am not, nor have I ever been, a computational physicist :-) Regards, Nick Maclaren.
From: nedbrek on 3 Mar 2010 06:30 Hello all, <nmm1(a)cam.ac.uk> wrote in message news:hml9h1$q7g$1(a)smaug.linux.pwf.cam.ac.uk... > In article <hmkbb6$edp$1(a)news.eternal-september.org>, > nedbrek <nedbrek(a)yahoo.com> wrote: [perhaps I snip too much...] > > If you start with the assumption that no change is possible in one > area, you often end up with the conclusion that no change is possible > in another. Well, all that really means is that incremental change > isn't possible, and a revolution is needed. Do you remember the > days of "mainframes will rule forever", based on the same arguments? To a large extent, you are preaching to the choir. As a design engineer, and later architect, for eight years I struggled with the "could" and "should" versus what actually was happening. When my group was fired, I think I became bitter. Perhaps my view is slanted, but look at the products that ship... > I.e. it would much better parallel (aggregate) performance, but > worse serial performance. Hence the problem is marketing. Worse serial performance is worse performance for the most populous user. They're the ones paying for everything... Atom is pretty good for a lot of stuff, but people are wanting more (and developers want bloatier software - mmm, bloatier, I like it). Did anyone see the comparison between P4 and the latest Nehalem? http://hardware.slashdot.org/article.pl?sid=10/02/16/2212220 There is an interesting note at the end: hardware performance has doubled (at the same frequency), but software performance for similar tasks has increased less (presumably due to bloatiness). Enjoy, Ned
From: Robert Myers on 3 Mar 2010 09:45
On Mar 3, 12:54 am, timcaff...(a)aol.com (Tim McCaffrey) wrote: > In article > <667e9f6b-6170-4d0e-8a68-06cdfc897...(a)g11g2000yqe.googlegroups.com>, > rbmyers...(a)gmail.com says... > > >On Mar 2, 7:18=A0pm, timcaff...(a)aol.com (Tim McCaffrey) wrote: > >> In article > > <906e8749-bc47-4d2d-9316-3a0d20a7c...(a)b7g2000yqd.googlegroups.= > > > > > > >com>, > >> rbmyers...(a)gmail.com says... > > >> >I know, you thought of it all in 1935. > > >> Actually, 1972(ish), and it was CDC/Seymore Cray (well, I assume it was > h= > >im). > >> It was even called the same thing: ECS. > > >> ECS was actually available before that (CDC 6000 series), but only the > ma= > >in > >> CPU could talk to it, and I/O was done to main memory. =A0With the 7600 > t= > >he PPs > >> could also write to the ECS (slowly), and the CPU could read from it. > =A0= > >There > >> were Fortran extensions to place *big* arrays in ECS and the compiler > too= > >k > >> care of paging in and out the part you were working on. =A0Michigan > State= > > used > >> it to swap out processes (it was much faster than disk). > > >> The ECS used a 600 bit interface to the CPU, and had an extremely long > ac= > >cess > >> time (10us IIRC), so bandwidth was about the same as main memory, but > lat= > >ency > >> sucked. > > >> ECS was also how multiple CPUs talked to each other, it had 4 ports for > 4 > >> different systems, so they could coordinate disk/file/perpherial > sharing. > > >> MSU used the ECS to connect a 6400 and a 6500 together, and later the > 650= > >0 > >> with a Cyber 170/750. =A0The slower machine was used primarily for > system= > >s > >> development work. > > >I don't know if it's related, but CDC's "large core memory" (as > >opposed "small core memory") was my very unwelcome introduction to > >computer hardware. > > >From that experience, I acquired several permanent prejudices: > > >1. For scientific/engineering applications, "programmers" should > >either be limited to sorting and labeling output, or (preferably) they > >should be shipped to the antarctic, where they could be sent, one at a > >time, to check the temperature gauge a quarter mile from the main > >camp. > > >2. No sane computational physicist should imagine that even a thorough > >knowledge of FORTRAN was adequate preparation for getting things done. > > >3. Computer architects are generally completely out of touch with > >reality. > > >Do anything you like, but please never show respect for Seymour Cray, > >including misspelling his name. > > >Robert. > > I certaintly didn't intend to misspell his name. > > Hey, I tell you what, you don't tell me who I should show respect for and I > won't bother to point out that you ended up recreating a design that you > say you despise, OK? > > And I'm also sorry that wherever you were, it didn't have competent > programmers (or, apparently, physicists). > > MSU physicists designed two different cyclotrons using the CDC machines. > To be clear, Tim, I don't think I've invented anything. There are some obvious things that you can do with memory, some of which I suggested in this forum long ago. As to Seymour, he gets dissed a lot, and I don't hear many people objecting. Well, I object. So far as I know, he never signed any consent decrees, practically invented the supercomputer brand which is now used to label warehouses full of racks, and understood the needs of computational physicists in a way that most computer architects (including, most glaringly, the ones who work at the bomb labs) just don't. Robert. Robert. |