Apple's new leader, and RISC...

[Dave Higton]

[Posted and mailed]

In message <7d44bc0d4c.druck@druck.freeuk.net>
druck <news@druck.freeuk.com> wrote:
But lets not get in to this again. We all know good pre-emp is better and if we had it we'd like it. But we've got mainly co-op and it works well enough in the vst majority of cases.

I don't agree that good pre-emptive is necessarily better. It's different
(obviously) and is desirable sometimes and not at others.

I write programmes for use on my Risc PC at work where I single-task the
machine very simply by not Wimp_Polling. This means I get all the
computer's resources; at these times I need them, I'm entitled to them
and I have no-one to answer to but myself for doing so. Co-operative
multi-tasking gives me a choice that benefits me. It's a choice I don't
get with pre-emptive MT.

Please, don't blindly assume that pre-emptive is automatically better.
It just isn't true in all cases.

Dave

[Ian Molton]

On Sun, 06 Jul 2003 20:51:30 +0100
Dave Higton <davehigton@dsl.pipex.com> wrote:
I write programmes for use on my Risc PC at work where I single-task the machine very simply by not Wimp_Polling. This means I get all the computer's resources; at these times I need them, I'm entitled to them and I have no-one to answer to but myself for doing so. Co-operative multi-tasking gives me a choice that benefits me. It's a choice I don't get with pre-emptive MT. Please, don't blindly assume that pre-emptive is automatically better. It just isn't true in all cases.

Exactly what are you doing that needs to hog the machine like that, and
why do you assume there is any significant overhead in pre-empting?

anything that really IS that critical is likely handling hardware
anyhow, and should be a kernel module.

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with
ketchup.

[Paul Boddie]

Ian Molton <spyro@f2s.com> wrote in message news:<20030706210832.43cc3faa.spyro@f2s.com>... On Sun, 06 Jul 2003 20:51:30 +0100 Dave Higton <davehigton@dsl.pipex.com> wrote:

[Stuff that Mac users probably used to say but now deny they did
because their OS now has preemptive multitasking.]
Please, don't blindly assume that pre-emptive is automatically better. It just isn't true in all cases. Exactly what are you doing that needs to hog the machine like that, and why do you assume there is any significant overhead in pre-empting?

Actually, taking the role of "devil's advocate", I could suggest the
activity of CD burning as a reasonable example. Would you want to
start a burning run using cdrecord and then start up OpenOffice.org or
do something really disk-intensive? Although I've only ever had one
buffer underrun when burning CDs, it does make me somewhat wary.
anything that really IS that critical is likely handling hardware anyhow, and should be a kernel module.

I wonder if the various RISC OS CD burning software is single-tasking.
One might argue that it absolutely should be, if only because the use
of a single-tasking process would be the only real way of preventing
some WIMP task slapping up an error box and ruining the burning
activity.

Paul

[Dave Higton]

In message <20030706210832.43cc3faa.spyro@f2s.com>
Ian Molton <spyro@f2s.com> wrote:
On Sun, 06 Jul 2003 20:51:30 +0100 Dave Higton <davehigton@dsl.pipex.com> wrote: I write programmes for use on my Risc PC at work where I single-task the machine very simply by not Wimp_Polling. This means I get all the computer's resources; at these times I need them, I'm entitled to them and I have no-one to answer to but myself for doing so. Co-operative multi-tasking gives me a choice that benefits me. It's a choice I don't get with pre-emptive MT. Please, don't blindly assume that pre-emptive is automatically better. It just isn't true in all cases. Exactly what are you doing that needs to hog the machine like that, and why do you assume there is any significant overhead in pre-empting?

I'm collecting data from the D channel of a telephone. There would be
overhead even if I moved a window around - I know I shouldn't but if
the machine is single-tasking I can't even do it by accident.
anything that really IS that critical is likely handling hardware anyhow, and should be a kernel module.

Handling hardware, yes. Kernel module, no, that would be a ridiculous
way to do it. It only needs to be a user application and is much easier
to write as such.

Dave

[Ian Molton]

On Mon, 07 Jul 2003 21:21:59 +0100
Dave Higton <davehigton@dsl.pipex.com> wrote:
I'm collecting data from the D channel of a telephone. There would be overhead even if I moved a window around - I know I shouldn't but if the machine is single-tasking I can't even do it by accident.

What are you reading it into? the serial port? have you got 1 byte FIFOs or something?
anything that really IS that critical is likely handling hardware anyhow, and should be a kernel module. Handling hardware, yes. Kernel module, no, that would be a ridiculous way to do it. It only needs to be a user application and is much easier to write as such.

Whats so scary about a kernel module? it you used a kernel module it'd work AND you could multitask.

Under linux they are easy to write. They arent exactly hard under RISC OS either.

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

[Ian Molton]

On 7 Jul 2003 01:57:07 -0700
paul@boddie.net (Paul Boddie) wrote:
Exactly what are you doing that needs to hog the machine like that, and why do you assume there is any significant overhead in pre-empting? Actually, taking the role of "devil's advocate", I could suggest the activity of CD burning as a reasonable example. Would you want to start a burning run using cdrecord and then start up OpenOffice.org or do something really disk-intensive? Although I've only ever had one buffer underrun when burning CDs, it does make me somewhat wary.

I recall about 3 years ago I caused the jaw of a windows user to hit the floor...

He came round to get some linux CDs to install from.

When he got there I popped a blank in the drive and then showed him quake3 (which he hadntseen before).

7 mins later I handed him the (burnt) CD.

Quake3 does some HEAVY disc IO when loading levels (which I did a few times, showing him the game). the machine had a 400MHz K6-III and only UDMA-33

I dont use Openoffice, its shit.
anything that really IS that critical is likely handling hardware anyhow, and should be a kernel module. I wonder if the various RISC OS CD burning software is single-tasking. One might argue that it absolutely should be, if only because the use of a single-tasking process would be the only real way of preventing some WIMP task slapping up an error box and ruining the burning activity.

Wasnt the CDBurn guy (whose name escapes me) working on a multitasking (pre-emptive IIRC) version?

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

[Dave Higton]

In message <20030707213004.1b2fd5c6.spyro@f2s.com>
Ian Molton <spyro@f2s.com> wrote:
Whats so scary about a kernel module? it you used a kernel module it'd work AND you could multitask.

There's nothing scary about writing a relocatable module. I've done it.
But there is more work to be done, and nothing to be gained.

It still doesn't mean that the computer could multi-task. I can't afford
processing time for other tasks to run.

Dave

[Ian Molton]

On Mon, 07 Jul 2003 21:49:33 +0100
Dave Higton <davehigton@dsl.pipex.com> wrote:
It still doesn't mean that the computer could multi-task. I can't afford processing time for other tasks to run.

In which case why bother with an OS at all?


--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

[druck]

On 7 Jul 2003 paul@boddie.net (Paul Boddie) wrote: Ian Molton <spyro@f2s.com> wrote in message news:<20030706210832.43cc3faa.spyro@f2s.com>... On Sun, 06 Jul 2003 20:51:30 +0100 Dave Higton <davehigton@dsl.pipex.com> wrote: Please, don't blindly assume that pre-emptive is automatically better. It just isn't true in all cases. Exactly what are you doing that needs to hog the machine like that, and why do you assume there is any significant overhead in pre-empting? Actually, taking the role of "devil's advocate", I could suggest the activity of CD burning as a reasonable example. Would you want to start a burning run using cdrecord and then start up OpenOffice.org or do something really disk-intensive? Although I've only ever had one buffer underrun when burning CDs, it does make me somewhat wary.

This all comes down to the definition of a "decent" PMT system. In my eyes
this means it has the following qualities, all of which are needed in
combination:-

* Scheduler with prioritisation and quality of service guaranties
* Full threaded kernel
* Overlapped I/O

With a system offering such qualties, there is no need to single task for any
reason, or raise the priority so high to try and lock out other tasks and
system responisveness as you may find on inferior systems.

A scheduler that offers a quality of Service guarantee for near real time
tasks, such as responding under interrupt or providing a contants bandwith
data stream to a perhiperal, can suspend other tasks, kernel threads and I/O
in order to give the high priority task access to time critical resources. As
long as 100% of any resource is not demanded (unlikely these days) the system
can continue to be responsive to user input and other tasks.
anything that really IS that critical is likely handling hardware anyhow, and should be a kernel module. I wonder if the various RISC OS CD burning software is single-tasking. One might argue that it absolutely should be, if only because the use of a single-tasking process would be the only real way of preventing some WIMP task slapping up an error box and ruining the burning activity.

PMT without kernel threading and overlapped I/O would lead to situations
where either the OS calls or I/O activity by a low priority task could
lock out high priority tasks.

You just are not going to get a decent PMT system in RISC OS, it would have
to be rewritten from the ground up, many of the API's would have to change
(including the entire Wimp Messaging system). Most applications are written
assuming they have control between polls, and could broken horribly by any
preemption between system calls.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

[Steffen Huber]

Paul Boddie wrote: Ian Molton <spyro@f2s.com> wrote in message news:<20030706210832.43cc3faa.spyro@f2s.com>...
[snip] anything that really IS that critical is likely handling hardware anyhow, and should be a kernel module. I wonder if the various RISC OS CD burning software is single-tasking.

It depends ;-)

CDScribe(2) was single tasking only
CDBlaze was able to do multitasking writes if the drive/SCSI controller
combination supported background operations
CDBurn is single tasking with a configuration option to allow multitasking
writes on BURN-Proof enabled drives.

CDBurn uses buffer-inspecting calls in multitasking mode to find out whether
it is sufficiently safe to do a Wimp poll. There is of course no
guarantee that the WIMP returns control early enough, but under RISC OS,
if e.g. interrupt activity from the network is kicking in, even
single tasking is not "good enough".
One might argue that it absolutely should be, if only because the use of a single-tasking process would be the only real way of preventing some WIMP task slapping up an error box and ruining the burning activity.

Since the introduction of BURN-Proof, things are less dangerous.

Anyway, I know of no desktop OS that can give an application certain
quality-of-service guarantees when it comes to I/O performance -
basically, you just throw a lot of hardware at the problem and
hope for the best. Just imagine a VM enabled OS starting to swap
during a burn operation...

Steffen

--
steffen.huber@gmx.de steffen@huber-net.de
GCC for RISC OS - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/

[John Williams (News)]

In article <3F0A8DF7.572A337A@huber-net.de>,
Steffen Huber <spam@huber-net.de> wrote:
There is of course no guarantee that the WIMP returns control early enough, but under RISC OS, if e.g. interrupt activity from the network is kicking in, even single tasking is not "good enough".

On this point, Steffen, how /do/ you kill a network card for CDBurn. Is it
sufficient to kill the module(s), and if so, which?

Will just RMKill-ing the driver do?

John

--
John Williams || Wirral, Merseyside, UK
UCEbin@tiscali.co.uk change user to johnrwilliams for speediest attention!
Who is John Williams? http://www.picindex.info/author/

[Paul Boddie]

druck <news@druck.freeuk.com> wrote in message news:<6b927a0e4c.druck@druck.freeuk.net>...

[Devil's advocacy]
This all comes down to the definition of a "decent" PMT system. In my eyes this means it has the following qualities, all of which are needed in combination:- * Scheduler with prioritisation and quality of service guaranties * Full threaded kernel * Overlapped I/O

Well the upcoming Linux 2.6 kernel is certainly going to be an
improvement, even if it doesn't fully meet these criteria as far as I
know. Certainly, I've read about improved kernel preemption and better
scheduling, but being an applications person, I don't spend much time
on the details these days; especially when those details work together
very well for me and allow me to tackle the "actual work" that needs
doing in "user space".

[...]
You just are not going to get a decent PMT system in RISC OS, it would have to be rewritten from the ground up, many of the API's would have to change (including the entire Wimp Messaging system). Most applications are written assuming they have control between polls, and could broken horribly by any preemption between system calls.

So what do you see as the technological future of RISC OS, then? Is
RISC OS good enough, in your opinion? If so, how do you reconcile the
various limitations (including those described above) with a
satisfactory/contemporary user experience? If not, where does the
future of the platform lie?

Paul

[Jess]

In message <6b927a0e4c.druck@druck.freeuk.net>
druck <news@druck.freeuk.com> wrote:

[snip]
This all comes down to the definition of a "decent" PMT system. In my eyes this means it has the following qualities, all of which are needed in combination:- * Scheduler with prioritisation and quality of service guaranties * Full threaded kernel * Overlapped I/O

[snip]
You just are not going to get a decent PMT system in RISC OS, it would have to be rewritten from the ground up, many of the API's would have to change (including the entire Wimp Messaging system). Most applications are written assuming they have control between polls, and could broken horribly by any preemption between system calls.

Would this be a good way forwars?

Write a PMT module that supports all the changed APIs required and
pre-emtively multitasks as a CMT process.

When enough software supports this (presumably a couple of years later),
a new version of the OS would be written that uses PMT. Possibly with
the option of a module to support CMT software?

Is wimp2 any good?

--
Jess icq: 91353267 msn: phantasm_39@hotmail.com http://www.kentwebnet.com
Hotmail is my spam trap - don't use for email
mailto:nospam@itworkshop.uklinux.net
RISC OS 4.36 kinetic 64+128+2M Castle Storm DMA + 17GB 586-133 I-3 ADSL


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

[druck]

On 8 Jul 2003 paul@boddie.net (Paul Boddie) wrote: So what do you see as the technological future of RISC OS, then? Is RISC OS good enough, in your opinion? If so, how do you reconcile the various limitations (including those described above) with a satisfactory/contemporary user experience? If not, where does the future of the platform lie?

Co-Op and PMT if both done correctly should be completely transparent to
the user, its not something they should ever be aware of. Where it does
make a difference is how easy it is for the programmer to maintain the
allusion of the machine doing many things at once, but dedicating most
reasources to the user interaction.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

[george]

In message <7cc3f50e4c.druck@druck.freeuk.net>
druck <news@druck.freeuk.com> wrote:
On 8 Jul 2003 paul@boddie.net (Paul Boddie) wrote: So what do you see as the technological future of RISC OS, then? Is RISC OS good enough, in your opinion? If so, how do you reconcile the various limitations (including those described above) with a satisfactory/contemporary user experience? If not, where does the future of the platform lie? Co-Op and PMT if both done correctly should be completely transparent to the user, its not something they should ever be aware of. Where it does make a difference is how easy it is for the programmer to maintain the allusion of the machine doing many things at once, but dedicating most reasources to the user interaction. ---druck

ISTR a development (successor?) to Risc OS called Galileo, which Acorn was
working on at the time of its demise. According to my recollection of a
contemporary interview with a senior Acorn programmer in RISC USER, Galileo
was to offer preemptive multitasking and assured quality of service.
Presumably the IP went to E14 along with all the other Acorn legacies - does
anyone know what happened to it?

As to the future of the platform, I don't see why, given good fortune and
sales at Castle, a fundamental modernisation of RO shouldn't be successfully
achieved. After all, it was widely thought at one time that 32-bitting and
development of a HAL were impracticable (no demand, small size of market,
etc, etc) until RO5 appeared. Since one of the major advantages of RO is its
use of very cheap (relative to power) processors, an OS supporting multiple
processors and giving developers the option of rewriting certain
applications to utilise them (Photodesk, Vantage?) is probably the only way
the platform will ever close the performance gap to Windows and Mac OS. The
alternative would be to emulate the latter and develop RO to sit on top of a
Linux kernel. I haven't tried Mac OS X, but after three years experience of
Mac OS 9, RO even in its present state handles multitasking much better and
is more stable IMHO.

George

--

[Paul Boddie]

druck <news@druck.freeuk.com> wrote in message news:<7cc3f50e4c.druck@druck.freeuk.net>... On 8 Jul 2003 paul@boddie.net (Paul Boddie) wrote:

[Various questions left unanswered. ;-)]
If not, where does the future of the platform lie? Co-Op and PMT if both done correctly should be completely transparent to the user, its not something they should ever be aware of. Where it does make a difference is how easy it is for the programmer to maintain the allusion of the machine doing many things at once, but dedicating most reasources to the user interaction.

But do you really think this is possible with CMT, given the range of
user activities? Do you think that it is reasonable for developers to
have to "jump through hoops" to preserve this illusion? (Although I
accept that a good enough toolkit can make development activities
bearable, too.)

An interesting "non-Internet age" task which exposed flaws in the RISC
OS architecture was the printing system. Having read about the
mechanisms in the PRM, I can imagine that it was a nightmare to
implement/develop/maintain, and it wasn't exactly a superb experience
for users: lots of hourglass time despite supposedly multi-tasking
spoolers. In an era where more activities have to coexist, isn't the
burden of CMT greater than the economies it supposedly offers?

Paul

P.S. I suppose you've already answered these questions by not directly
answering my other questions. A career in politics would seemingly
remain open. ;-)

[druck]

On 9 Jul 2003 paul@boddie.net (Paul Boddie) wrote: druck <news@druck.freeuk.com> wrote in message news:<7cc3f50e4c.druck@druck.freeuk.net>... On 8 Jul 2003 paul@boddie.net (Paul Boddie) wrote: [Various questions left unanswered. ;-)] If not, where does the future of the platform lie? Co-Op and PMT if both done correctly should be completely transparent to the user, its not something they should ever be aware of. Where it does make a difference is how easy it is for the programmer to maintain the allusion of the machine doing many things at once, but dedicating most reasources to the user interaction. But do you really think this is possible with CMT, given the range of user activities? Do you think that it is reasonable for developers to have to "jump through hoops" to preserve this illusion? (Although I accept that a good enough toolkit can make development activities bearable, too.)

Reasonable no. With better facilities, you might get more software developed.
But you have to make a compromise between breaking all the existing software
in order to reap quite a small long term reward, as programs are written /
modified to use it.

The main trouble is proper PMT as I described, can't be gradually introduced,
as until all the components are in place, you get something that works as
badly as Win95. The changes needed to do this, are just about a ground up
re-write, and not the largely mechanical process of the 32bit conversion -
you would be looking at a large number of man years, and not much to show
for it until the end.
An interesting "non-Internet age" task which exposed flaws in the RISC OS architecture was the printing system. Having read about the mechanisms in the PRM, I can imagine that it was a nightmare to implement/develop/maintain, and it wasn't exactly a superb experience for users: lots of hourglass time despite supposedly multi-tasking spoolers. In an era where more activities have to coexist, isn't the burden of CMT greater than the economies it supposedly offers?

There are certain classes of applications that would benefit greatly from PMT
and a proper threading model. Web browsers that simulatanously perform
multiple fetch, parse, render and display operations, and Java VM's which
assume PMT/treads are two very obvious examples.

However for the vast majority of programs, it would have very little benefit
to the programmer, only simplifying backgound processing tasks of wimp
applications, very few of which can't be easily co-op'd.
P.S. I suppose you've already answered these questions by not directly answering my other questions. A career in politics would seemingly remain open. ;-)

No, I am afraid I tell it like it is, or dont say anything. I'd rather hit
you with a hammer than lie to you, a technique even Precott hasn't mastered.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

[Liam Gretton]

On Wed, 9 Jul 2003, druck wrote:
But by then you'll be seeing 10GHz x86's on the desktop. i.e. still 5x clock differential and up to 15x faster. But what does all the additional power of each months must have faster than ever PC get you? The opportunity for Microsoft to keep adding bloat to the OS, and running the same old applications you know and hate [...]

....or for those of us who push the system, the availability of
cheap yet increasingly powerful CPUs is very welcome.

(currently my Athlon XP 1900 is chewing on some movie files before I burn
them to DVD... about 45 hours to process 4.5 hours of video...)

When I moved from a 600MHz P3 to my current system, which included moving
from Win98 to WinXP, my productivity increased by an order of magnitude,
and I can use it for things that really weren't practical before. I fully
expect the same thing to happen next time I splash out on a faster system.

--
Liam Gretton ljg@star.le.ac.uk
Space Research Centre, http://www.src.le.ac.uk/
Physics and Astronomy Dept, phone +44 (0) 116 223 1039
University of Leicester, fax +44 (0) 116 252 2464
Leicester LE1 7RH, UK

[Ian Molton]

On Wed, 9 Jul 2003 21:08:01 +0100
Liam Gretton <ljg@star.le.ac.uk> wrote:
(currently my Athlon XP 1900 is chewing on some movie files before I burn them to DVD... about 45 hours to process 4.5 hours of video...)

What are you encoding? seems a bit slow...

2 pass re-encoding of Shrek only took me 30 mins on my AthXP 1800 (linux)

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

[Ian Molton]

On Wed, 09 Jul 2003 20:03:16 +0100
druck <news@druck.freeuk.com> wrote:
The main trouble is proper PMT as I described, can't be gradually introduced, as until all the components are in place

Is there something stopping you running all the CMT tasks as a single PMT process?

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with
ketchup.

[george]

In message <5451700f4c.druck@druck.freeuk.net>
druck <news@druck.freeuk.com> wrote:
[snipped]
Just because an ARM processor costs $20 compared to an x86 which is anything up to $800, doesn't make a RISC OS computer any cheaper, without the economies of scale that the PC market can take advantage of.

Indeed, but my point was that if we wish to see ROS desktop machines with
something approaching contemporary levels of power, multiple ARM processors
(because of their low cost) could result in a powerful but still affordable
system. Suppose a multi-threading ROS existed now: would a dual-processor
Iyonix be attractive? Would it cost significantly more money?

[snipped]
XScale will never compete with the x86 range. The XScale is optimised for low power embedded use, consuming less than 1W of power. Desktop processors are optimised for marketing copy, sorry clock speed, and can put out 70W or more. The supercalar nature of the desktop processors give them 2x-3x the performance of the XScale at the same clock.

Precisely my point. Single ARMs are unlikely to compete in future with
single x86s. Multiple ARMs might, however. The logic of your position is
that ARMs on the desktop are a lost cause. That may be true, of course...

[snipped]
You will see 2GHz XScales powering PDA's in order to run Pocket PC 2005 which is rapidly approaching desktop Windows levels of inefficency. But by then you'll be seeing 10GHz x86's on the desktop. i.e. still 5x clock differential and up to 15x faster. But what does all the additional power of each months must have faster than ever PC get you? The opportunity for Microsoft to keep adding bloat to the OS, and running the same old applications you know and hate, but with stupid garish colour schemes - and just wait until they make it all 3D. ---druck

Indeed, the efficiency of ROS makes my Kinetic/VF2 still seems acceptably
responsive in general use when compared to the PC workstations with treble
the clock speed at work. No doubt the Iyonix would strike the average PC
owner as remarkably responsive, and silent! It's only when you start
performing complex operations on massive files that the lack of horsepower
(on the Kinetic at any rate) becomes problematic.

George

--

[Liam Gretton]

On Wed, 9 Jul 2003, Ian Molton wrote:
On Wed, 9 Jul 2003 21:08:01 +0100 Liam Gretton <ljg@star.le.ac.uk> wrote: (currently my Athlon XP 1900 is chewing on some movie files before I burn them to DVD... about 45 hours to process 4.5 hours of video...) What are you encoding? seems a bit slow...

Poor quality home video churned out of Premiere, and run through TMPGEnc
with a noise filter to clean the image. It's this filter that grinds the
system down, but it makes a noticeable difference to the final output.
2 pass re-encoding of Shrek only took me 30 mins on my AthXP 1800 (linux)

TMPGEnc probably isn't the fastest MPEG encoder around, but it's very very
good at what it does.

--
Liam Gretton ljg@star.le.ac.uk
Space Research Centre, http://www.src.le.ac.uk/
Physics and Astronomy Dept, phone +44 (0) 116 223 1039
University of Leicester, fax +44 (0) 116 252 2464
Leicester LE1 7RH, UK

[Liam Gretton]

On Wed, 9 Jul 2003, george wrote:
No doubt the Iyonix would strike the average PC owner as remarkably responsive, and silent! It's only when you start performing complex operations on massive files that the lack of horsepower (on the Kinetic at any rate) becomes problematic.

That's why Virtual Acorn (and let's hope one day soon, Virtual RPC) are so
attractive. Powerful hardware you can throw at the emulator and a system
that you can use for the stuff that RO apps aren't available for.

--
Liam Gretton ljg@star.le.ac.uk
Space Research Centre, http://www.src.le.ac.uk/
Physics and Astronomy Dept, phone +44 (0) 116 223 1039
University of Leicester, fax +44 (0) 116 252 2464
Leicester LE1 7RH, UK

[druck]

On 9 Jul 2003 Ian Molton <spyro@f2s.com> wrote: On Wed, 09 Jul 2003 20:03:16 +0100 druck <news@druck.freeuk.com> wrote: The main trouble is proper PMT as I described, can't be gradually introduced, as until all the components are in place Is there something stopping you running all the CMT tasks as a single PMT process?

Wimp messages sent between the realms.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

[druck]

On 9 Jul 2003 george <free080.isp@ukgateway.net> wrote: In message <5451700f4c.druck@druck.freeuk.net> druck <news@druck.freeuk.com> wrote: [snipped] Just because an ARM processor costs $20 compared to an x86 which is anything up to $800, doesn't make a RISC OS computer any cheaper, without the economies of scale that the PC market can take advantage of. Indeed, but my point was that if we wish to see ROS desktop machines with something approaching contemporary levels of power, multiple ARM processors (because of their low cost) could result in a powerful but still affordable system. Suppose a multi-threading ROS existed now: would a dual-processor Iyonix be attractive? Would it cost significantly more money?

Only two problems:-

Firstly ARM chips dont support symetric multi-processing, as there is no
ability to keep the contents of each cache coherent with each other and
memory. Any implementation would be technically difficult and/or inefficent.

Getting anything close to a linear increase in performance on desktop
applications (as opposed to server tasks) difficult with mutliple processors.
Unless you are doing specialist work 2 is the limit, and you may expect at
around 50% speed increase on average. Given that RISC OS isn't PMT or
multi-treaded, you wouldn't see any gain.
Indeed, the efficiency of ROS makes my Kinetic/VF2 still seems acceptably responsive in general use when compared to the PC workstations with treble the clock speed at work. No doubt the Iyonix would strike the average PC owner as remarkably responsive, and silent! It's only when you start performing complex operations on massive files that the lack of horsepower (on the Kinetic at any rate) becomes problematic.

Get yourself a multi-processor linux box under the desk for the grunt work.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

[Liam Gretton]

On Wed, 9 Jul 2003, Martin Dann wrote:
The mind boggles. Will we need two screens with fancy spectacles? or one screen with red and green specs? Or a 3d-laser affair? How will they do it? Probably one screen with a fast refresh (i.e. double what you normally get), and LCD specs. The screen displays the left eye picture, then the right, then the left etc, and the LCD specs filter out the wrong picture.

Some NVidia cards already support this. I played Tomb Raider about three
years ago with just such an arrangement on a friend's PC. There was a
little IR beamer attached to the top of the monitor which told the specs
which lens to switch on or off. It worked very well, but his monitor
wasn't quite up to the refresh rate required.

--
Liam Gretton ljg@star.le.ac.uk
Space Research Centre, http://www.src.le.ac.uk/
Physics and Astronomy Dept, phone +44 (0) 116 223 1039
University of Leicester, fax +44 (0) 116 252 2464
Leicester LE1 7RH, UK

[druck]

On 10 Jul 2003 Ian Molton <spyro@f2s.com> wrote: On Thu, 10 Jul 2003 00:54:05 +0100 druck <news@druck.freeuk.com> wrote: Is there something stopping you running all the CMT tasks as a single PMT process? Wimp messages sent between the realms. This is a problem why, exactly?

See the umpteen times I've explained this previously.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

[Ian Molton]

On Thu, 10 Jul 2003 17:59:59 +0100
druck <news@druck.freeuk.com> wrote:
> Is there something stopping you running all the CMT tasks as a single PMT> process? Wimp messages sent between the realms. This is a problem why, exactly? See the umpteen times I've explained this previously.

nevermind then. I cant be bothered.

Its a solution thats been tried before and works, though.


--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

[Martyn Fox]

In article <1840f90f4c.adamr@richardsons.argonet.co.uk>, Adam Richardson
<adamr@cheerful.com> wrote:
Just hold down ALT and press TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB-TAB

It reminds me of my old BBC B which was connected to the RGB input of my
Fergusson MC - 01 monitor.

If I typed something like VDU 19,0,0,0,0,0,0,0,0,0, the monitor switched to
ITV.

(It re-programmed the video generator in such a way that the syncs collapsed
and the monitor thought the video feed on its input had gone. It then
switched to its tuner.)

Martyn

--
_
|\/| _ _ -+- _ |_ _ Windsor, Berks. UK
| | (_| | | (_| | ) | (_) )( mfox@argonet.co.uk
ZFC La _| Acorn Risc Pc with StrongARM - a Wintel-free zone!

[Ian Molton]

On Thu, 10 Jul 2003 21:11:25 +0100
druck <news@druck.freeuk.com> wrote:
Its a solution thats been tried before and works, though. Not under RISC OS,

I never claimed that.
the pre-emptive WIMP hack had to suspend any time a message was sent (very frequent), entirely breaking PMT. Thats the only way to do it without a complete redisgn of the protocol and changes to every application.

Thats not what I proposed. I was suggesting that ALL the CMT tasks behaved as though they were a *SINGLE* PMT process. not one PMT process per CMT task as you seem to suggest.

It wouldnt improve old apps, but it would allow (if done right) new apps to be pre-emptive AND still run alongside old ones.

This is, I believe, similar to how some linux based RTOSes work. (run linux as a single process under an RTOS microkernel)

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

[Liam Gretton]

On Thu, 10 Jul 2003, Ian Molton wrote:

[druck wrote...]
the pre-emptive WIMP hack had to suspend any time a message was sent (very frequent), entirely breaking PMT. Thats the only way to do it without a complete redisgn of the protocol and changes to every application. Thats not what I proposed. I was suggesting that ALL the CMT tasks behaved as though they were a *SINGLE* PMT process. not one PMT process per CMT task as you seem to suggest.

Sounds reasonable. AFAIR it's what Apple has done before while they moved
from CMT to PMT, and what MS did with 16 bit apps in Win9x as app writers
migrated to Win32 - keep all the legacy apps bundled together in an
environment isolated from the new system, but usable nonetheless.

Unfortunately all completely pie-in-the-sky as far as RO is concerned, of
course, unless things really pick up in the next year or two.

--
Liam Gretton ljg@star.le.ac.uk
Space Research Centre, http://www.src.le.ac.uk/
Physics and Astronomy Dept, phone +44 (0) 116 223 1039
University of Leicester, fax +44 (0) 116 252 2464
Leicester LE1 7RH, UK

[Steffen Huber]

"John Williams (News)" wrote: In article <3F0A8DF7.572A337A@huber-net.de>, Steffen Huber <spam@huber-net.de> wrote: There is of course no guarantee that the WIMP returns control early enough, but under RISC OS, if e.g. interrupt activity from the network is kicking in, even single tasking is not "good enough". On this point, Steffen, how /do/ you kill a network card for CDBurn. Is it sufficient to kill the module(s), and if so, which?

The things that usually ruin your CD burning activities are servers running
on your machine. It is usually enough to kill ShareFS and any other server
you are running (NFSServer, any Webservers, Samba...) or just make sure
that other computers are not trying to connect.
Will just RMKill-ing the driver do?

Usually not necessary.

Steffen

--
steffen.huber@gmx.de steffen@huber-net.de
GCC for RISC OS - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/