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