On 15.07.11, you wrote:
This is a completely bogus/meaningless comparison. Firstly, a
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
3-5*.thats very large.You dont want compile netsurf SDL Version to see if your use of
Cairo slow all
when i do tests on winuae without JIT, so its very slow i notice, larger window run
800*600 lots need clip.so i find out, clipping cost more time as render complete page in
I guess every OS4 machine is run in 32 bit.But i ask the OS4 tester, if he have use
netsurf on 32
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,
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
it should at least 10 faster.
68k have lots smaller caches.A big app as netsurf like alot big caches.this is maybe the
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
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 );
Secondly, the code they are running is completely different,
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
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.