3:21 p.m.
Hi,
may a user with RISC OS can post time values too.
this are netsurf speed values between 68k 2.7 SDL netsurf and OS4 2.7 netsurf on a SAM 667
MHZ.
newest OS4 and a Pegasos 1 GHZ OS4
more stand here in earlier posts.its german
http://www.a1k.org/forum/showthread.php?p=443367#post443367
the test site for time test was www.osnews.com
maybe a user with a risc OS machine can do the test, to see if SDL is fastest possible
speed.
a classic amiga is a very slow system, and if OS4 netsurf have no speedbrake somewhere, a
SAM or a
Peg should get at least same sec on virtual 100 MHZ.
The OS4 SAM and Pegasos values and 68040/40 netsurf values are from cha05e90.a User who
like OS4.so
its no OS4 bashing result possible.only too fast OS4 values are maybe possible ;-)
100 MHZ line mean the values is calculate to a 100 MHZ CPU, to make it more easy possible,
to
compare performance /MHZ.less time is better.you can see that on OS4 performance /100 MHZ
is more
than 3* slower as on netsurf SDL 68k.
because the 1 GHZ G4 in compare to 667 MHZ SAM is 2.3* faster with netsurf it show that
inet access
is no important speed brake.also the BPPC 060/50 mhz values are from a diffrent user,
values are
simular, so diffrent
SDL netsurf 68k
BLIZZARD 2040 68040/40 MHZ
init load 35.10 sec reload 28.1 sec
100 MHZ init load 14.04 sec reload 11.24 sec
amiga OS 3.1 A3000-PPC PHASE5 68060 50 MHZ 128MB
init load 23.8 sec reload 17.5 sec
100 MHZ init load 11.9 sec reload 8.75 sec
BPPC 060/50 mhz und Bvision mit 800x600x16 Screen
init load 24.4 sec reload 18.8 sec
100 MHZ init load 12.2 sec reload 9.4 sec
SAM 667 MHZ OS4.x
init load 8.4 sec reload 5.0 sec
100 MHZ init load 56 sec reload 33.35 sec
Pegasos 1 GHZ G4 OS4.x
init load 4.1 sec reload 2.1 sec
100 MHZ init load 41 sec reload 21 sec
Bye
4:08 p.m.
This is a completely bogus/meaningless comparison. Firstly, a 100MHz
68060 and a 100MHz PPC440 aren't going to be running at the same
speed. Even a 100MHz 68060 and a 100MHz 68040 aren't the same speed.
Secondly, the code they are running is completely different, compiled
for a different target and by a different compiler, with different
frontend code. Moreover, one of the processors is CISC and the other
is RISC - RISC processors have to execute more code by their very
nature of having a smaller instruction set. The display resolution of
the test machines is also different, the OS4 ones having to do more
rendering (unless screen res or window size was adjusted to
800x600x16, which I doubt, and would also impact the figures
negatively as there is a known slowness issue with 16-bit in the OS4
frontend)
I have no idea what this comparison is trying to prove. If you have a
PATCH to improve the speed of the OS4 frontend I would be interested
in that, otherwise if you have nothing constructive to add please keep
it to yourself.
Chris
5:32 a.m.
Hello
On 15.07.11, you wrote:
This is a completely bogus/meaningless comparison. Firstly, a
100MHz
68060 and a 100MHz PPC440 aren't going to be running at the same
speed. Even a 100MHz 68060 and a 100MHz 68040 aren't the same speed.
between diffrent CPU and compiler can maybe 20-60% diffrence but the slowdown of OS4
version is
3-5*.thats very large.You dont want compile netsurf SDL Version to see if your use of
Cairo slow all
down.
when i do tests on winuae without JIT, so its very slow i notice, larger window run
faster.on
800*600 lots need clip.so i find out, clipping cost more time as render complete page in
X.
I guess every OS4 machine is run in 32 bit.But i ask the OS4 tester, if he have use
netsurf on 32
bit.
Use netsurf on OS4 in 32 bit is maybe faster, because the routines need no byte swapping.
But on 68k there is in 16 bit alot of byteswapping need.so the compare of 16 bit is valid,
because
both systems need byteswapping then.
The transfer speed to a 68k amiga GFX Card is around 6-12 megabyte /sec and memory copy
speed of a
060/50 is around 24 megabyte /sec.So SAM and a Peg have more than 10* more memory transfer
speed.so
it should at least 10 faster.
68k have lots smaller caches.A big app as netsurf like alot big caches.this is maybe the
reason wy
the the G4 with the 256 kb secondary cache is so much faster as the SAM.
here can see the 16 bit byteswap code the 68k netsurf need do.
#if __BYTE_ORDER == __BIG_ENDIAN
static inline nsfb_colour_t nsfb_plot_ablend_be16(UNUSED nsfb_t *nsfb, nsfb_colour_t
pixel,nsfb_colour_t scrpixel)
{
int opacity = pixel & 0xFF;
int transp = 0x100 - opacity;
uint32_t rb, g;
pixel >>= 8;
scrpixel >>= 8;
rb = ((pixel & 0xFF00FF) * opacity +
(scrpixel & 0xFF00FF) * transp) >> 8;
g = ((pixel & 0x00FF00) * opacity +
(scrpixel & 0x00FF00) * transp) >> 8;
return ((rb & 0xFF00FF) | (g & 0xFF00)) << 8;
}
static inline nsfb_colour_t pixel_be_to_colour(UNUSED nsfb_t *nsfb, uint16_t pixel)
{
return ((pixel & 0x1F) << (8+3)) |
((pixel & 0x7E0) << (8+5)) |
((pixel & 0xF800) << (16));
}
static inline uint16_t colour_be_to_pixel(UNUSED nsfb_t *nsfb, nsfb_colour_t c)
{
return ((c & 0xF8000000) >> 16) | ((c & 0xFC0000) >> (16-3)) |
((c & 0xF800) >> 11 );
}
#endif
Secondly, the code they are running is completely different,
compiled
for a different target and by a different compiler, with different
frontend code. Moreover, one of the processors is CISC and the other
is RISC - RISC processors have to execute more code by their very
nature of having a smaller instruction set. The display resolution of
the test machines is also different, the OS4 ones having to do more
rendering (unless screen res or window size was adjusted to
800x600x16, which I doubt, and would also impact the figures
negatively as there is a known slowness issue with 16-bit in the OS4
frontend)
I have no idea what this comparison is trying to prove. If you have a
its to see if a port run at full possible speed.
I like to see what values a RISC PC can reach with that page
PATCH to improve the speed of the OS4 frontend I would be interested
in that, otherwise if you have nothing constructive to add please keep
it to yourself.
Chris
Regards
7:25 a.m.
On Sat, 16 Jul 2011 10:32:58 +0100, Bernd Roesch wrote:
> This is a completely bogus/meaningless comparison. Firstly, a
100MHz
> 68060 and a 100MHz PPC440 aren't going to be running at the same
> speed. Even a 100MHz 68060 and a 100MHz 68040 aren't the same speed.
between diffrent CPU and compiler can maybe 20-60% diffrence
but the slowdown of OS4 version is
3-5*.thats very large.You dont want compile netsurf SDL Version to see if your use of
Cairo slow all
down.
If that is what you are trying to achieve, then what you need to do is
compile NetSurf 2.7 Framebuffer-SDL for OS4, using the exact same
compiler with the exact same switches that I used, use a local page
for testing so there are no network variances, exact same window size
etc. If you do your tests under scientific conditions then maybe I
will take notice of the results.
I would still rather receive a PATCH that improves the speed than an
email moaning that it is slow (especially as compared to other CSS
web browsers on the same hardware/OS, it definitely isn't)
Use netsurf on OS4 in 32 bit is maybe faster, because the routines
need no byte swapping.
NetSurf does byteswapping regardless of where it is run, either in the
bitmap conversion functions or when it goes to screen. This is true
even for RISC OS AFAIK. It certainly does not contribute to any 3x
difference in speed.
Chris
9:39 a.m.
On Sat, 16 Jul 2011 14:50:34 +0100, Bernd Roesch wrote:
> If that is what you are trying to achieve, then what you need to
do is
> compile NetSurf 2.7 Framebuffer-SDL for OS4, using the exact same
> compiler with the exact same switches that I used, use a local page
> for testing so there are no network variances, exact same window size
> etc. If you do your tests under scientific conditions then maybe I
> will take notice of the results.
i dont know if you understand, we do not talk about some % speed diffrence.we talk about
3* faster
of 68k netsurf.
No we don't, and I've already explained why not.
Its really hard to find a OS4 User that show his speed results.many
OS4 users have a red sight
glass, and never show something that on OS4 look not good.
There are timings available on the public NetSurf OS4 screenshots.
I've already said that NetSurf is faster than any other CSS browser
available for OS4, so I don't see any need for a cover up (even if it
wasn't the fastest, there is no need to cover up any speed figures
which depend as much on the user's network connection as they do on
the OS and hardware)
I only want information, that there is a huge slowdown problem.its
upto you if you try to search for
it, or build a netsurf OS4 SDL version to compare.
I don't believe there is a huge slowdown problem in the rendering
phase, that's a tiny part of the overall process (much more time is
spent on processing and fetching). I could build Framebuffer-SDL for
OS4, but I suspect the speed difference will be minimal, and certainly
nowhere near the 3-5x difference you are quoting.
you can also verify the results if you get same speed values.
I don't dispute the results, just the comparison which is meaningless
at best.
It is pointless to discuss this further at this time. Either get some
SDL speeds under scientific test conditions, or do the same with an
OS4 frontend build on 68k, and then report the speed differences or
provide me with a patch to fix them.
You can also set cairo_renderer:0 in Resources/Options on the OS4
build to force it to not use Cairo, if that is your gripe. There is
no discernable speed difference between that and the default mixed
graphics.library/Cairo plotters (full Cairo *is* slower because
clipping takes an extraordinarily long time)
Chris
9:50 a.m.
Hello Chris
On 16.07.11, you wrote:
On Sat, 16 Jul 2011 10:32:58 +0100, Bernd Roesch wrote:
>> This is a completely bogus/meaningless comparison. Firstly, a 100MHz
>> 68060 and a 100MHz PPC440 aren't going to be running at the same
>> speed. Even a 100MHz 68060 and a 100MHz 68040 aren't the same speed.
>
> between diffrent CPU and compiler can maybe 20-60% diffrence but the slowdown of OS4
version is
> 3-5*.thats very large.You dont want compile netsurf SDL Version to see if your use of
Cairo slow
> all down.
If that is what you are trying to achieve, then what you need to do is
compile NetSurf 2.7 Framebuffer-SDL for OS4, using the exact same
compiler with the exact same switches that I used, use a local page
for testing so there are no network variances, exact same window size
etc. If you do your tests under scientific conditions then maybe I
will take notice of the results.
i dont know if you understand, we do not talk about some % speed diffrence.we talk about
3* faster
of 68k netsurf.
Its really hard to find a OS4 User that show his speed results.many OS4 users have a red
sight
glass, and never show something that on OS4 look not good. I never want use OS4, i dont
think
Hyperion is able to do a revival of the Amiga as they announces 1,5 years before with the
X1000
that should come before summer 2010.
better is of course when find a classic OS4 user and post his values of the 233 MHZ
system.but as i
told before, this is lots more slower.
I only want information, that there is a huge slowdown problem.its upto you if you try to
search for
it, or build a netsurf OS4 SDL version to compare.
you can also verify the results if you get same speed values.
I would still rather receive a PATCH that improves the speed than an
email moaning that it is slow (especially as compared to other CSS
web browsers on the same hardware/OS, it definitely isn't)
> Use netsurf on OS4 in 32 bit is maybe faster, because the routines
> need no byte swapping.
NetSurf does byteswapping regardless of where it is run, either in the
bitmap conversion functions or when it goes to screen. This is true
even for RISC OS AFAIK. It certainly does not contribute to any 3x
difference in speed.
Chris
Regards
4337
days inactive
4338
days old
netsurf-dev@netsurf-browser.org
5 comments
2 participants
participants (2)
-
Bernd Roesch -
Chris Young