home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11956 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  3.3 KB
  1. Xref: sparky comp.arch:11956 comp.sys.intel:2843
  2. Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  3. From: pcg@aber.ac.uk (Piercarlo Grandi)
  4. Newsgroups: comp.arch,comp.sys.intel
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <PCG.92Dec27203203@decb.aber.ac.uk>
  7. Date: 27 Dec 92 20:32:03 GMT
  8. References: <1992Dec7.012026.11482@athena.mit.edu> <PCG.92Dec11162630@aberdb.aber.ac.uk>
  9.     <1992Dec21.134531.3253@athena.mit.edu> <2121@coyote.UUCP>
  10.     <1992Dec23.025403.21926@athena.mit.edu>
  11. Sender: news@aber.ac.uk (USENET news service)
  12. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  13. Organization: Prifysgol Cymru, Aberystwyth
  14. Lines: 50
  15. In-Reply-To: solman@athena.mit.edu's message of 23 Dec 92 02: 54:03 GMT
  16. Nntp-Posting-Host: decb.aber.ac.uk
  17.  
  18. On 23 Dec 92 02:54:03 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
  19.  
  20. solman> What I am trying to say is that when a task which has been
  21. solman> non-cpu bound, is modified such that it becomes cpu-bound, the
  22. solman> modifications invloved are typically excellent candidates for
  23. solman> parallelization. Thus it still holds that "general purpose"
  24. solman> computing can support the degree of parallelization available to
  25. solman> a deep pipelined "hyperscalar" uP.
  26.  
  27. This is hopeful speculation.  Especially for the "deep pipelined" part.
  28. Deep pipelines are nasty to exploit across basic blocks, not to say
  29. across threads.
  30.  
  31. On the other hand, as you seem to argue, many current applications are
  32. under-threaded, mostly because of the cost of threading under many
  33. current OSes.
  34.  
  35. Still even many common applications can be broken in multiple threads
  36. without much restructuring, and some people do it by hand; for example
  37. recalculating a spreadsheet may be broken in as many threads are there
  38. are independent clusters in the dependency graph between cells, and so
  39. on recursively. Reformatting a document can be broken in as many threads
  40. as there are independent sections, or manually imposed page boundaries.
  41.  
  42. I even remember that people at a french University (Poitiers?) had built
  43. an Algol 68 compiler that used threads/futures to handle forward
  44. references. I must confess that seeing that paper it had come into my
  45. mind that one could just launch into a dataflow CPU a thread per each
  46. syntactic phrase being parsed, and just let the CPU sort out all the
  47. dependencies ensuring maximum parallel speedup, and I was conforted to
  48. see Hewitt's parallel actors and garbage collection of processes ideas.
  49.  
  50. But then I started thinking of the likely cost/benefit ratio, and
  51. repented.
  52.  
  53. The numbers I have seen so far seem to point out that on average
  54. (some/many spreadsheets are poorly clustered, some/many documents have
  55. no sections, in some/many compilations all statements depend critically
  56. on the previous one...) the exploitable degree of parallelism is not
  57. that great for most general purpose applications.
  58.  
  59. Of course one could claim that an as yet undiscovered architectural
  60. solution will change everything; somebody once remarked, only half
  61. jokingly, in this very newsgroup, that in twenty years time we will boot
  62. ourselves in our massively parallel neural net engines, instead of
  63. booting up our workstations, as we start our workday.
  64. --
  65. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  66.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  67.   alle orecchie del suo divino protettore, il dio della barzelletta
  68.