home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / realtime / 1565 < prev    next >
Encoding:
Text File  |  1993-01-12  |  3.3 KB  |  66 lines
  1. Newsgroups: comp.realtime
  2. Path: sparky!uunet!munnari.oz.au!sol.deakin.OZ.AU!news.cs.uow.edu.au!seagoon.newcastle.edu.au!wombat.newcastle.edu.au!eepjm
  3. From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
  4. Subject: Re: novel idea?
  5. Message-ID: <1993Jan13.121354.1@wombat.newcastle.edu.au>
  6. Lines: 54
  7. Sender: news@seagoon.newcastle.edu.au
  8. Organization: University of Newcastle, AUSTRALIA
  9. References: <erempel.726720401@sol.UVic.CA> <1993Jan11.171954.1@wombat.newcastle.edu.au> <C0onL4.2qE@newcastle.ac.uk>
  10. Date: Wed, 13 Jan 1993 01:13:54 GMT
  11.  
  12. In article <C0onL4.2qE@newcastle.ac.uk>, Adrian.Waterworth@newcastle.ac.uk (Adrian Waterworth) writes:
  13. > eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
  14. > 
  15. >>In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
  16. >>> 
  17. >>> I know that the single task on the 040 would run slower than on the
  18. >>> i860, but if the i860 was bogged down, the net result would
  19. >>> be a system speedup.
  20. > 
  21. >>You must be joking.  The machine languages of these two processors
  22. >>are totally different.  Would you plan to run an 860 simulator on
  23. >>the 68040, or recompile the source code each time you switched
  24. >>processors?  Either way, the overheads are mind-boggling.
  25. > 
  26. >>"Run slower" is a gross understatement.
  27. > 
  28. >     I'm not sure that I entirely agree. In particular, why should
  29. > it be necessary "to re-compile the source code each time you switched
  30. > processors"? Assuming that enough memory or on-line storage is
  31. > available, what's wrong with having two _pre-compiled_ versions of the
  32. > task (one for each processor)? The task switching problem then becomes
  33. > a simple case of suspending on one processor and loading/running on the
  34. > other. I can't think of any references straight off the top of my head,
  35. > but I know that this kind of technique has long been proposed (and
  36. > probably used by now) as a means of supporting load-balancing and
  37. > process migration in heterogeneous distributed systems.
  38.  
  39. The tricky part would be to keep track of where a task was up to
  40. at the time of a task switch - i.e. which bit of object code in
  41. one machine language corresponded to which bit in the other version.
  42. Preemptive task switching would be completely out of the question,
  43. because you'd have to guarantee that the machine registers were not
  44. holding anything useful at the time of the switch.  This means that
  45. the compilers could not be permitted to optimise across
  46. statement boundaries, either, which would be a bit of performance
  47. hit.  It looks to me that you'd have to have a rule that task
  48. switching happened only at pre-designated checkpoints which both
  49. compilers knew about.
  50.  
  51. This sort of solution is not impossible, but it would be a major
  52. headache to implement, and it would have some significant performance
  53. penalties.  Given that the point of the original proposal was to
  54. get a performance increase, you might be better off throwing away
  55. one of the processors and using a decent compiler and low-overhead
  56. OS on the other.
  57.  
  58. For similar reasons, I didn't mention interpreted languages in my
  59. original response.  Using an interpreter on both machines is clearly
  60. the easiest way to solve the incompatibility problem - this could
  61. be implemented with very little trouble - but why bother?  The
  62. overall speed of the two-processor system would be lower than any
  63. decent single-processor solution.
  64. -- 
  65. Peter Moylan                      eepjm@wombat.newcastle.edu.au
  66.