Talk:Preemptive multitasking

From RISC OS

(Difference between revisions)
Jump to: navigation, search
(Context Switch cost: new section)
Line 3: Line 3:
A long time ago back in the days when I had a Archimedes 410, I wrote a program that just did wimp_polls and counted them. Results were singularly unimpressive. The maximum number of wimp_polls per second was pretty dire, made one think that the cost of a context switch for a wimp application would be very high. Much higher than a context switch for a typical PMT system KeithSloan
A long time ago back in the days when I had a Archimedes 410, I wrote a program that just did wimp_polls and counted them. Results were singularly unimpressive. The maximum number of wimp_polls per second was pretty dire, made one think that the cost of a context switch for a wimp application would be very high. Much higher than a context switch for a typical PMT system KeithSloan
 +
 +
== Context Switch cost ==
 +
 +
That's probably true, but there are many substantial changes since RO2/3 ARM2/3 days.  Lazy task switching is but one, and of course substantial changes in the wimp and processor speed.  Besides, you have to do context switch in PMT or CMT, so that's not a factor either way. --[[User:Pnaulls|Pnaulls]] 19:05, 9 October 2009 (UTC)

Revision as of 19:05, 9 October 2009

A very interesting article. I have used Wimp2 on my RiscPC for quite some time now. You are right that it is not a complete solution, but I do think it works well in some cases - specifically when unzipping a large archive with sparkplug comes to mind. The patch which has been released allows you to select which applications should be used with Wimp2, so by some trial and error it is possible to get the "most" out of it. I suppose a "fix" should be transparent to the end user, but hey ROS users are used to tinkering with the system ;) Polas

  • Personally, I suspect a properly designed PMT environment running either on top of, or as part of the WIMP is the answer for now. Properly designed so that in the future, we could move to a pure PMT OS, with the CMT environment running as a process in the PMT environment, ala Windows NT's NTVDM. This would enable faster development of an improved system (for all of Windows 95's drawbacks, it was better than Windows 3.1. Now think of that much of an improvement to RISC OS,) with the ability to go back and do it right later. Oh, and patching applications ala WimpPatch is necessarily hackish, and probably isn't the best answer - I think the best answer is to properly modify applications for a PMT environment. That said, buzzwords can be thrown around all we like, that doesn't actually get the code written. Unfortunately, I don't have enough knowledge to spec out an API or the design of the system, so I can't be of much help here. --Bhtooefr 12:14, 9 October 2009 (UTC)

A long time ago back in the days when I had a Archimedes 410, I wrote a program that just did wimp_polls and counted them. Results were singularly unimpressive. The maximum number of wimp_polls per second was pretty dire, made one think that the cost of a context switch for a wimp application would be very high. Much higher than a context switch for a typical PMT system KeithSloan

Context Switch cost

That's probably true, but there are many substantial changes since RO2/3 ARM2/3 days. Lazy task switching is but one, and of course substantial changes in the wimp and processor speed. Besides, you have to do context switch in PMT or CMT, so that's not a factor either way. --Pnaulls 19:05, 9 October 2009 (UTC)

Personal tools