rjek (+1.4)
31/12/06 2:38PM |
Woo! NetSurf wins! At least! Congratulations to the winners, and condolences to the not-quite-winners. It'd be interesting to see by what margins everyone one/lost - ie, how many votes are there between JC's and The Chox's home goal prize? |
leeshep  (+3.0)
31/12/06 3:53PM |
A big thankyou to all RISC OS developers, 2006 has (all in all) been a good year for our favourite platform. Let's hope 2007's even better.... Iyonix 2 anyone? |
AW
31/12/06 4:41PM |
Remind me again why an Iyonix-only port is an own-goal? Much as I'd like to see a (cut-down?) RPC version, if that's not possible then surely there are too few A9's to have made a port worthwhile for any initial releases of v2? |
tweety (+5.0)
31/12/06 4:54PM |
I would have to agree wrt Firefox it's unreasonable to expect modern (hungry) applications to work on 10 year old hardware. Be thankful for what Chox has done with Firefox and the underlying libraries. |
rjek (+0.4)
31/12/06 4:58PM |
In reply to AW:
The Chox's FF2 port was made Iyonix-only for non-technical reasons. Read into that what you will. |
AW (+1.0)
31/12/06 5:21PM |
I am thankful whether I can use it or not but I don't think it's unreasonable in theory in this case as it happens.
The article implies that he made the port Iyonix only for technical reasons. I would agree that non-technical reasons namely more Iyonixes about (presumably) would make more sense but an own-goal? :S |
bluenose (+2.0)
31/12/06 5:33PM |
Well done to all the winners and runner ups.
As to all the debate about FF2, then all I can say is well done to Peter for getting out the door in a very usable form and delivering on what he promised. The A9 issue is also now a non issue as it runs on that platform as well. I could see both sides of the arguement and as Peter had a Iyonix then perhaps that is why the initail release was aimed at an area he could check out bug reports on first.
As to RISCPC ports then isn't it time that we started to let the old machine go. Yes, they are still usable and RISCOS Adjust/6 is a good addition but modern hardware enables more things to be done and should be supported if the market is to survive.
Iyonix 2 would be great and I can't believe that my Iyonix will be 5 years old soon. |
rjek (+0.4)
31/12/06 5:35PM |
In reply to AW:
There was zero reason for The Chox to make his initial FF2 port Iyonix-only from a technical point of view. Infact, it was more work for him (if only marginally) to make it Iyonix-only. He clearly wanted, for his own reasons, to stop Omega and A9Home users using his FF2 port. It has nothing to do with there being "more" Iyonixes. Given his absolute refusal to explain himself, we are left only able to assume he did this out of spite. Given that I then managed to get it running on the A9Home, easily as fast as it appeared to run on the Iyonix, without his assistance and emulating the Iyonix's CPU to an extent, it seems very much like an own-goal - we just don't know what he was trying to achieve - only that it was stopped. |
killermike (+5.0)
31/12/06 6:09PM |
Has Peter given any official comment on the issue? Peter would be the person to ask but I would have thought that he wouldn't have manually added any A9Home unfriendly instructions by hand. I presume that he simply built it with the correct set of options and optimizations for his Iyonix.
Peter has done a lot for the platform this year and it's a shame that he has come top of one of the negative poll categories. |
TonyStill (+3.0)
31/12/06 7:11PM |
In reply to rjek:
As you say, we don't know Peter's reasons. However, I think spite is unlikely. Isn't it more likely that, since we know he was in pursuit of better performance, he just used all the optimisation switches? This would be a reasonable approach from someone intending to come back to fine tuning later (which is consistent with the latest release being A9 compatible, AIUI). |
rjek (+0.9)
31/12/06 7:35PM |
In reply to TonyStill:
The Chox highly advocates actually testing to see if things are faster or not - or at least he certainly does when somebody else tries to demonstrate something. As I had previously said, making GCC emit XScale-only instructions a) is more effort, and b) saves less than a thousandth of a second on the Iyonix. Premature optimisating is very very bad, and The Chox knows this. The more heavily you optimise, the more difficult it is to track down bugs. |
AMS (+2.0)
31/12/06 8:37PM |
In reply to rjek:
Not having the innate talent to read Peter Naulls' mind I am at somewhat a disadvatage in knowing why the initial release was XScale only. It isn't just the case of XScale only instruction optimisations being taken into account (remember GCC wasn't written specifically to compile FF2) therefore the exact effect of compiling for it might not have been known when Peter iniitially did it. Also instruction scheduling may have a part to play (having a longer pipeline it's important to cater for this on XScale, Peter may well have chosen to optimise for the best/fastest native ARM solution, not unreasonable I would have thought).
Now he's catered for A9 users too - so what's the problem - please give the guy credit he's done lots of useful work for RISC OS. |
rjek (+0.9)
1/1/07 1:47AM |
In reply to AMS:
You demonstrate your lack of talent in this respect with your suggestions. Simply reordering/tuning/scheduling instructions to optimise for XScale does not render the code unable to execute on other CPUs. The only thing that does (and is what The Chox did) is to specifically ask the compiler to use instructions that only the XScale has. Why go to extra effort to make it more likely that bugs will occur at the same time as making it more difficult to debug, and limiting the number of users who can test it? Peter knows better than this, and also knows that there was no good technical reason to do so. So we're still left guessing as to why he chose to do it. |
AMS (+1.0)
1/1/07 11:12AM |
rjek wrote>"Simply reordering/tuning/scheduling instructions to optimise for XScale does not render the code unable to execute on other CPUs."
Never said that it did, but the reordering does improve performance more for XScale, I would assume that GCC would optimise by (1). Using XScale only instructions where possible and (2). Reorder instructions for best performance on XScale. Therefore there could be merit for initially compiling in this way (it would give more performance improvement than simply using XScale only instructions alone).
Besides he's now addressed the issue so why continue complaining about it? |
GavinWraith (+2.0)
1/1/07 12:13PM |
I whisper advice in the ear of Chris, who must be as distressed as I am at some of the comments made: Confucius he say "stir the tea with your finger and scum rises to the surface". Your motto for 2007 should be "honi soit qui mal y pense". |
TonyStill (+3.0)
1/1/07 12:23PM |
In reply to rjek:
I believe we are talking here of an optimisation achieved by giving the compiler licence to use a wider set of instructions (ie including those found only on the XScale). Such an optimisation is quite different to one achieved by changes to the program logic.
Optimisation through logic or algorithm changes can indeed be unwise if done early in the development cycle. I can see no reason why using the compiler's optimisations is a problem for any release though and I think that's what Peter did. I stand by my statement that using all the speed related optimisations is a reasonable approach; indeed, the A9 incompatibility did bring a performance improvement, albeit a tiny one.
My speculation (and I'm no better informed than anyone else here) is that the gain from that particular optimisation was disappointing; the trade-off between improved performance and improved compatibility then became obvious, leading to the A9 compatible release that quickly followed. I could be completely wrong, of course, but I still think rational reasons are more likely than spite from Peter. |
NeilWB
1/1/07 1:26PM |
Sad that we don't have anything more important to talk about than Peter's motivation in porting Firefox 2  |
DaveW (+1.0)
1/1/07 2:13PM |
Firefox 2 - Great! Very, very stable and faster than 1.5. Brilliant stuff. I think that's important! |
rjek (+1.0)
1/1/07 2:32PM |
In reply to AMS:
Yes, tuning for XScale may have given a tiny advantage, possibly more than using XScale-specific instructions. The reason he was nominated for own goal is that he will have known full well that a) using XScale instructions would have made a trivial and unnoticable difference, b) that this would stop it working on other machines, c) somebody got it to work anyway, without his help. Seems completely reasonable to me.
In reply to TonyStill:
The more features of the compiler you use, the more difficult it is to discover if the bug is in your code, or in the compiler's. Which is why most software is developed with -O0 and only built with more optimisations later. Using certain optimisations and compiler features can also make it impossible to debug the software. |
fwibbler (+1.0)
1/1/07 2:36PM |
Of course it is.
I simply can't believe that spite was the reason that the first release only worked on the Iyonix.
In any event, the second release (released on time I should add) works on the A9home as well and future versions (if there are any) will probably do so as well.
I really can't see what the fuss is about. Can't people look to the future?
Cheers! |
jess (+1.0)
1/1/07 3:38PM |
I don't think producing an Iyonix only version was an own goal, but initially not saying why, which lead to speculation, could qualify.
Am I right in thinking that if the latest version were compiled to support RiscPCs, there would be a speed penalty on the currently supported machines? |
rjek
1/1/07 3:49PM |
In reply to jess:
A marginal, but possibly noticable one, yes - half-word (16 bit) loads and stores from memory are frequently of use in things like image decoders and such, and these are the instructions that do not work on RiscPC-class machines. (Less to do with the CPU, and more to do with the IOMD chipset on the motherboard.) StrongARMs can do them if the data is already in the cache, and Kinetics can do them if the data's on the on-board fast RAM.
In any case, Peter's refusal to say why he had decided to make it Iyonix-only in the first instance, when there is demonstratably no technical reason is the own-goal - and the nominations and the vast majority of the voting occured before he did release an A9 Home version. And we don't yet know if the only reason he made his second reason A9 Home-friendly is because we'd got his old one working anyway. He's been completely silent on the matter. |
jess
1/1/07 4:25PM |
In reply to rjek:
So with suitable memory management, the existing firefox 2, might be able to be made to work on a Kinetic? (Perhaps if you get bored one evening  )
It would have been best if the reasons were stated with the release. However, once you proved there was trivial advantage, there would have been little point making an update just for A9 compatibility, since you provided a path to use that version, and it appears the next version is a significant step.
|
coling (+4.1)
1/1/07 6:54PM |
I don't know what all the fuss is about. Peter is at liberty to release the program how he wants. He has no obligation to justify any of his decisions to anyone. If other people don't like what he's done all they have to do is compile it themselves - simple really |
druck (+6.0)
1/1/07 7:27PM |
Peter has said why he did it to a number of people. Its so he can get on with the port without the constant whining of users of 13 year old machines complaining that code aimed primarily at muli-GHz x86 PCs doesn,t work fast enough on thier 200MHz StrongARMs. Frankly given the perpetual moaning on csa, I fully endorse this position.
Both GCC and Norcroft can produce code optimised for XScale scheduling but not using XScale specific instructions, or 16bit load and stores if required. When Peter has finished the port all the source will be made available under the GPL and people will be able to compile it for whatever they want, and then the pointless bleating can start all over again. |
jess (+2.0)
1/1/07 7:59PM |
That would explain the current situation and is quite fair.
However, the previous version did not support the A9 which is new and produced by sponsors of the project.
At the time, not supporting it without explaination seemed odd and must have caused concern to any purchaser of an A9. |
AW
1/1/07 8:37PM |
I'm not whining - just a suggestion to involve more users.
Talking in terms of "13 years old" and "time to move on" is disingenuous and inappropriate, frankly.
For a start the SA is about 10 years old, RISC OS 4+ less, and more importantly authors /know/ that in terms of compatibility they have to go the extra distance and then some more with RISC OS. Even with special offers of £500 for an Iyonix (not including monitor) it's too expensive to justify for many people. Most people would just get a laptop I imagine.
Furthermore, Castle started manufacturing RiscPC's as the last Acorn computers in 1999, just over 7 years ago and selling them in the region (inc. monitor) for £1000 so please give it a rest with "13 years" at least for the moment.
And as for RComp selling RISCBooks for aroud £900 or more, >70% of the British population must think they're living in cloud cuckoo land! |
druck
1/1/07 9:10PM |
None of that changes that fact that the machine is a 13 year old design, with a I/O and memory speeds which stuck at the speed they were 13 years ago. The StrongARM gave a massive speed boost for the typical small RISC OS C or BASIC program, but is massively compromised by the slow memory and I/O when running applications like Firefox.
Both the Iyonix and A9 have massively faster memory and I/O, and significantly more processor power and only just run such a large and complex application at a reasonable speed, so older machines don't stand a chance, and no amount of wishing or whining is going to change that. |
AW (-0.1)
1/1/07 10:45PM |
Well in the best spirit of Acorn/ RISC OS I say never say never to anything. I/O was "changed" by Kinetic. Firefox in theory can be changed (e.g. cut down in some respect or elements utilised elsewhere) as well. |
rjek
2/1/07 12:40AM |
Strictly speaking, Peter has to already provide his patched sources to other people.
In reply to coling:
Nobody's suggesting otherwise.
Firefox is a slow piece of software. Even on fast PC's, it's a little unresponsive. Frankly, I'm surprised anybody thinks it's usable on an Iyonix, but it'd be simply too much pain to run it on a RiscPC.
In reply to AW:
No, only one small problem with the RiscPC architecture was solved by the Kinetic - all the others remained. |
| Use the forum for more comments on this article |
As 2006 finally draws to a close, it's time to reveal who was hot and who was not in the RISC OS world this year. The Best of 2006 results are in, and here are the winners and runners-up chosen by drobe.co.uk readers.