Different Implementations of VLIW .
|
Prev: The Mark Thorson FAQ: Read all about this LIAR, BULLY, THUG, CYBERSTALKER and HARASSER
Next: The Mark Robert Thorson FAQ: Read all about this LIAR, BULLY, THUG, CYBERSTALKER and HARASSER
From: Peter Grandi on 6 May 2008 16:49 [ ... ] > Actually, I think there's a lot of inherent parallelism in the > task TeX tries to achieve (typesetting). > The way it's implemented however assures that everything is > serialized. The same is true for GCC (with less impact for the > user, because you can always make -j for more parallelism). And to merge Nick's (and mine) liking of Algol 68 and the topic of microparallelism, I will mention here a rather amazing paper by Banatre on compiling Algol 68 by starting a new thread for every syntactic construct. This was done more to avoid explicit multiple passes in a language with perverse forward references: http://DOI.ACM.org/10.1145/357121.357123 http://DOI.ACM.org/10.1145/359046.359055 On a similar, but not parallel-programming note, there was the diabolical left-to-right and right-to-left parsing technique of Bohm from the MC, which could parse Algol 68 in two passes.
From: Nick Maclaren on 5 May 2008 17:33 In article <yf3od7kmqc6.fsf(a)tree.gp.example.com>, pg_nh(a)0710.exp.sabi.co.UK (Peter Grandi) writes: |> |> > The general argument is that there is a natural correspondence |> > between data structures and control structures, which goes like |> > this, in a very simplified form: |> |> The architectural implications, especially as to optimization of |> bulk operation, should be fairly obvious. Agreed. I am not going to respond to your posting, as I agree with you in almost all of it. I was only objecting to the implication that tail recursion in itself clarifies code - i.e. that code with it is likely to be clearer than code without it, in the absence of other conditions. |> As to "Structured programming", whose chapters 2 and 3 are so |> uniquely important yet obscure even when it was a hot book, some |> years ago I listened to D. Knuth at a lecture saying that he had |> asked AP if it still was selling, and he was told that indeed it |> was still selling, *three* copies per year. O tempora, o mores :-). What is so catastrophic is the number of (now influential) professors who believe the myths and dogmas of yesterday - such as software engineering is primarily about development rituals and toolkits, or that dynamic (run-time) error handling is intrinsically undesirable (programs should be validated statically). |> But then I think this classic cartoon tragically realistic: |> |> http://www.iBiblio.org/Dave/Dr-Fun/df200002/df20000210.jpg Unfortunately :-( Regards, Nick Maclaren.
From: Eugene Miya on 5 May 2008 20:16 In article <481a50a0$1(a)news.meer.net>, Greg Lindahl <lindahl(a)pbm.com> wrote: >In article <481a30fc$1(a)darkstar>, Eugene Miya <eugene(a)cse.ucsc.edu> wrote: >>My impression is that stuff as simple as a move or op isn't enough to be >>VLIW. Forking and branching might be more challenging. X-MPs in 1982 >>could do simultaneous 2-loads, a store, and arithmetic with mere pipelining. >>No long instructions needed. > >... I thought VLIW implied something other than just a lot of >instructions in flight. Yeah, I think that, too. So we have dealt with the quantitative. That brings up the qualitative. Might, in some case, we be running an ILP architecture in a lot of vector like patterns? Maybe. pause. I don't know, I think aside from arm chair quarterbacking, I think we have to get the Trace up and running again. I would want to see empirical stuff. Not conjecture. >The X-MP vector architecture doesn't look like >any of the classic VLIW architectures. Agreed. But the comparisons were for an architecture I had no familiarity with and the 360/370. And I'm not so certain the IBM's horizontally coded machines would qualify as VLIW/ILP. --
From: Eugene Miya on 5 May 2008 20:20 In article <481a6484$1(a)news.meer.net>, Greg Lindahl <lindahl(a)pbm.com> wrote: >In article <fvdn6e$h7c$1(a)gal.iecc.com>, John Levine <johnl(a)iecc.com> wrote: >>I always understood it to be wide enough that you have to do trace >>scheduling or something similarly aggressive to find enough work >>to keep all the units busy. > >That's what I thought, too. Which is nothing like how the X-MP works. >Ordinary vectorization and strip-mining is nothing like trace >scheduling. Agreed. But the end timed results won't have qualitative differences if you don't see how things work. You want to run a variety of codes to get differences. --
From: Eugene Miya on 5 May 2008 20:27
In article <fvehdm$t88$1(a)gemini.csx.cam.ac.uk>, Nick Maclaren <nmm1(a)cus.cam.ac.uk> wrote: >|> >That isn't snide, because information of known unreliability is a >|> >damn sight better than no information - for example, it often gives >|> >pointers to things to look up. In article <481a4cb2$1(a)darkstar>, eugene(a)cse.ucsc.edu (Eugene Miya) writes: >|> No, some times half truths are more damaging than untruth. That's how >|> electronic counter measures like chalf work. It depends somewhat on >|> references and pointers but some time, the Drake plate fiasco is a good >|> one, those aren't enough. >That's why I said "KNOWN unreliability". The real danger comes from >sources that are believed (by at least some important people) to be >reliable but, in fact, aren't. > >|> Knuth would like a TeX demo (8-10x speed up). I doubt that even Josh >|> would have promised that for TeX. > >It would be a brave statement, to be sure :-) Yep. >|> I'm not certain that I would go with HPC being more civilized. Parts >|> are regular so vectors benefit, but that only attraches irregular >|> applications in the next stage. Some of the HPC guys are Neanderthals. > >True, but have you looked at the code of the X Windowing System Toolkit >and widget sets? And C++ programs that use similar paradigms? I've insufficent knowledge of X internals. C++ OOP has its on set of problems. I'd put X in the TeX class of sequential algorithms for the time being. >|> >That was the conclusion that the 1960s and 1970s research came to, and >|> >it is why it was claimed that people needed to convert to 'higher-level' >|> >and more 'structured' languages, where the ILP might be extractable. >|> >Instead, most programmers have gone the other way .... >|> >|> It may be wording, but I didn't see ILP driving CISC or structured >|> languages for instance. I don't recall most programmers even thinking >|> about parallelism. ... > >The foresighted people who were saying it failed to influence the >unthinking majority[*]. If you look up some of the papers coming out >of the Algol 68 camp, you will find such references. In the event, >Algol 68 eventually sank (though a few of its features have returned >in Fortran 90), and the "higher level language" people faded away. > >[*] So what else is new? New? Nathan is taking delivery on Doran's 2nd Babbage difference engine. I know few who worked on 68. Buzz U. maybe. Dennis maybe to a small degree. Wirth, too maybe. It's not something anyone really chews the fat about. Most people look forward. You likely have to be more specific about references. Given their own devices most people would look up the wrong references. -- |