performance of hardware dynamic scheduling
|
From: Terje Mathisen on 3 Apr 2008 14:46 David Kanter wrote: > I'm more than happy to learn about NTP, as I've never claimed to be an > expert. However, in my experience I have never heard of anyone use > the term PLL for anything in SW. Even wikipedia really mentions it Try http://www.ntp.org/ and follow the (very) exhaustive documentation links. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Bill Todd on 3 Apr 2008 23:54 Ken Hagan wrote: > On Thu, 03 Apr 2008 13:44:16 +0100, Bill Todd <billtodd(a)metrocast.net> > wrote: > >> Intel's IA64 failure had nothing whatsoever to do with not >> understanding what the market wanted: it was all about failure to >> execute technically (or perhaps more specifically failure to be >> realistic in their technical - and schedule - projections) plus the >> hubris to believe that they could foist the resulting >> multi-billion-dollar-yawner on the market anyway (rather than quietly >> letting it die when it came up so abysmally short of its grandiose hype). > > So the vendor has to guess what will be implementable just as much as they > have to guess what will be desirable. They can be wrong on either front. You offered up P4 and Itanic as "fair examples of a major vendor guessing wrong" *in the specific context of guessing wrong about market demand*. My response above simply observed that both of your cited examples had little or nothing to do with guessing wrong about future market demand - and I'll observe now that guessing wrong about technology and schedule is also pretty unrelated to ability to predict market demand. Please do try to focus on the material to which you're purportedly responding: having Nick stumbling around the rough is bad enough. > > In any case, we're not talking about a completely free market here. There's > a considerable barrier to entry and only a handful of current players. If > they are all making similarly over-cautious decisions, how would we know? It's pretty clear that no one here actually *knows* much of anything with respect to this subject. My point remains that (given this conspicuous lack of actual knowledge) one really needs to come up with solid evidence if one is going to suggest that the people and companies whose generous salaries and profits depend upon competence in this area *all* got it wrong. > >>> The markets aren't infallible either. >> >> They don't have to be: they *define* demand (though are certainly >> often able to be influenced in that definition). > > But they *define* demand only several years after the vendors have > committed > to what they will supply. At the time the supply decisions are being made, > the punter isn't putting up any money at all. The fact that the punter eventually *does* put up a great deal of cash for the products that the vendors have developed demonstrates that they got their products at least fairly close to what the punter wanted. And since quite a few companies compete very vigorously in the CPU market (IBM, Fujitsu, Sun, Intel, AMD, Via - though their C-series lower-power x86 products don't seem to have made the kind of dent in Intel/AMD sales that the enthusiasm for such products might suggest) plus within the time-frame under discussion when development of simple multi-core products *could* have been started others like SGI and DEC who were still designing new future products, the fact that *none* of them attempted to exploit this alleged golden opportunity strongly suggests that it actually wasn't a golden opportunity at all: as I implied above, it takes a rather considerable amount of ego to suggest that they *all* got it so wrong (rather than just accept that you simply have got it wrong now, even given the benefit of hindsight). > > In addition, both vendor and market are probably fairly conservative. > It makes little sense for vendors to bet billions of dollars on something > *very* different from tried and tested, and uninformed punters will almost > always ask for "more of what I have now". Almost sounds as if you're talking about Itanic there... But it wouldn't have taken anything like billions of dollars to develop the kind of simple retro technology that Nick seems to favor, nor (given a compatible ISA) would it have represented anything all that visibly different, so once again the fact that pretty much *no one* (with the possible exception of Cyrix and now Via - to no great avail) even dabbled their toes in these waters until the single-thread performance wall *forced* them to do so strongly suggests that there just wasn't any perceived market for it (and thus probably no actual market, either, for the reasons already noted). > >> I guess I must have missed the clamor, then: could you direct me to >> evidence that the market is demanding that trade-off for *existing* >> products (rather than anticipating that it will make possible some >> interesting new ones)? > > That's not a reasonable request. The fact that new products are possible > is part of the clamor. If it's only 'part' of it, then I repeat my request above: tell me about the *other* part that relates to existing products that would gladly trade off a great deal of performance for major power reductions. And just to flush it out, tell me about the clamor for those new products, too. I could imagine some interest in pushing the x86 architecture down into the single-Watt region to replace existing embedded products with similar capabilities, but not quite anything approaching a 'clamor' If you restrict your survey to those you are already > selling to, then once again you'll get the answer "more of the same". > For example, people looking for a fanless PVR probably don't even consider > themselves as part of the market for x86 chips. And why should they? It may be in *Intel's* interest to get x86 chips into that kind of market, but for the consumer ARM may do just fine. - bill
From: David Kanter on 3 Apr 2008 23:48 On Apr 2, 1:27 pm, n...(a)cus.cam.ac.uk (Nick Maclaren) wrote: > In article <iNCdnU7DtO9Ofm7anZ2dnUVZ_hSdn...(a)metrocastcablevision.com>,Bill Todd <billt...(a)metrocast.net> writes: > > |> > |> In other words (though they've already been said before) SMT is an > |> effective way to benefit parallel workloads by using the additional > |> execution resources that are *already required* to attain the good > |> single-thread ILP that you seem to agree above is preferable, thus > |> attaining close to the best of both worlds rather than optimizing one > |> (parallel throughput) at major expense to the other (single-thread > |> performance). > > Let us ignore the fact that you have not justified your assertion > that the single-thread ILP is actually required It should be obvious to anyone why this is true. If nothing else, look at Intel and AMD's product plans. > - I agree that it is > desirable, but that is not the same thing. What you are ignoring is > that it comes at a serious cost. > The Tech Report article that David Kanter mentioned said that the > extra cost was c. 18% - well, that's 18% you can't use for multiple > cores. With a 30-40% perf gain. IOW, the perf/power of that particular tweak was 2, which is very good. > While that article didn't say what alternative it was > comparing against, the usual one used for throughput comparisons by > the SMT brigade is a single, fast core. No, I am not saying that > multiple, simple cores would provide 18% more throughput - it might > be less and it might be more. > > There are also the serious consequences on system reliability (sic) > and tuning. Doubtful. If there are consequences on system reliability, then IBM wouldn't have put it into the POWER5, POWER5+, POWER6 which are used for AIX and iOS. In fact, there's also research on using SMT to increase reliability.... DK
From: Muzaffer Kal on 4 Apr 2008 02:10 On Thu, 3 Apr 2008 09:58:33 -0700 (PDT), David Kanter <dkanter(a)gmail.com> wrote: >On Apr 3, 12:21 am, n...(a)cus.cam.ac.uk (Nick Maclaren) wrote: >> In article <91142bbc-6d1d-4b9e-9d0e-e98a06ad7...(a)i36g2000prf.googlegroups.com>,David Kanter <dkan...(a)gmail.com> writes: >> >> |> >> |> Nick, do you even know what a PLL is? It's not architecturally >> |> visible... >> >> http://www.faqs.org/rfcs/rfc1305.html >> >> I don't care whether you think that RFC is abusing the term "phase-locked >> loop" or not. > >A phase locked loop typically refers to a piece of analog or mixed >signal circuitry. I think the operative word here is "typically". A PLL is a "phase locked loop" for which you need a phase detector, a loop filter and a variable frequency oscillator. If you're doing A/MS PLLs your variable frequency oscillator is a VCO ie a voltage controlled oscillator usually implemented with current starved delay elements. If you're implementing a PLL on a processor you implement the variable frequency oscillator as an NCO ie a numerically controlled oscillator. >I'm more than happy to learn about NTP, as I've never claimed to be an >expert. However, in my experience I have never heard of anyone use >the term PLL for anything in SW. Even wikipedia really mentions it >only in relation to hardware. >http://en.wikipedia.org/wiki/Phase-locked_loop In my humble opinion there are two rules: 1) Any analog system can be replaced with sampled data system. 2) The block in the middle of a sampled data system can be implemented in software if a processor fast enough is available (if one is not available but desired waiting for the next process node usually solves the problem). So once you have adequate ADC/DAC blocks there is no difference between hardware and software in fact you can get an FPGA and partition the design between "hardware" and "software" to fit your solution. Then the question becomes if you implement a processor on an FPGA and put the code on an on-chip ROM is that "software" ? What if the "processor" is not fast enough and you start replacing parts of the code with logic? At what point you go from "software" to "hardware"? But that's enough theology for now. In the wikipedia aticle read the section named "Digital phase-locked loop", and think how you can implement that on a processor with an accurate timer interrupt. Muzaffer Kal ASIC/FPGA Design Services DSPIA INC. http://www.dspia.com
From: Bill Todd on 5 Apr 2008 14:17
Ken Hagan wrote: .... >> My response above simply observed that both of your cited examples >> had little or nothing to do with guessing wrong about future market >> demand - and I'll observe now that guessing wrong about technology and >> schedule is also pretty unrelated to ability to predict market demand. > > I did say... > > "They have to guess what the market will want some years hence. ... ia64 > and the P4 strike me as fair examples of a major vendor guessing wrong." > > ...so I can see where you're coming from, Yes: immediately-associated context is generally considered relevant (else we'd have to communicate using individual words in isolation, which I suspect would be quite difficult). but ia64 wasn't just a technical > failure. And I never claimed that: I said "it was all about failure to execute technically (or perhaps more specifically failure to be realistic in their technical - and schedule - projections)". There is *always* the risk that your new chip might be only > marginally better than the old. I.e., what I just quoted above. And I'll observe once again that it has *nothing* to do with failure to recognize what the market will likely *want*. Asking people to switch ISA for a marginal > improvement in performance was a risky option when DEC tried it with the > Alpha. 1. Alpha represented a great deal more than 'a marginal improvement in performance': not only did it (unlike Itanic) provide a *significant* improvement in performance, but it paved the way for additional future increases that the VAX architecture was not perceived to be capable of (yes, Intel later proved that a CISCy ISA - though hardly one as CISCy as VAX's - could follow, or sometimes even lead, RISC up the performance curve, but that was not at all clear for years after Alpha launched, let alone years earlier when the decision to develop Alpha was made). 2. And, of course, DEC did *not* ask people to switch ISAs - just provided them the opportunity to: not only did they provide facilities for running VAX binaries on Alphas, but VAXen were actively sold for eight years after the Alpha launch. It remains risky to this day, especially in the closed source > market. > By announcing that there would not be a 64-bit x86 and ia64 was the future, > Intel assumed that they knew the market so well that there was no need for > a plan B. First, there was *always* a Plan B: they just refused to acknowledge it publicly (but IIRC explored 64-bit support with Northwood and built 64-bit facilities into Prescott from Day 1, just in case). Second, from what I've heard, many in Intel actually *believed* their own Itanic hype early on, and even after the magnitude of the short-fall must have become evident to them instead of taking the common-sense approach of cutting their losses they instead took the gamble that they had sufficient monopoly power to *control* the market (which is quite different from trying to create what the market wanted). And despite Itanic's abysmal failure to deliver on its hype they still came pretty close to doing so: HP abandoned PA-RISC for Itanic (aggressively sharing that gamble with Intel, though not having a second string for their bow as Intel did), SGI abandoned MIPS for Itanic, cHumPaq abandoned Alpha for Itanic, the Japanese embraced Itanic (though Fujitsu kept its SPARC-64 development going just in case) - only IBM and Sun, after initially being on board, dropped out and decided to slug it out with their own products (Sun hedging its bet a bit by joining the x86 vendor crowd after Opteron's worth started to become evident). Had AMD not executed extremely well with K8 and IBM not executed comparably well with POWER5 (and now apparently POWER6) Itanic, disappointing as it is (especially compared with the expectations raised), would likely now rule. - bill |