Native 68k Netsurf

[unusedunused]

@bernd_afa

This is a completely bogus/meaningless comparison.  [Read more]

I am not discussing this further.

I haver answer in netsurf ML too

> 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

[unusedunused]

Seriously, your calculation is totally wrong...

Benchmarking a distant site is already very wrong if not done on the same machine/network, but your assumption that loading times are exactly inversely proportional to CPU clock is absolutely insane.
Sure, some time will be spent in building, rendering and blitting the page, but that's only a fraction of the process.

have you read the text ?
The OS4 values and the 68040/40 values are come from same inet.the slowdown of OS4 Version is really large.

currently there are no netsurf OS4 on classic and no RISC OS values.here you can see even more how slow netsurf on OS4 is.

so the very large slowdown can at least show, that it bring no speedup in netsurf when you not use ixemul and SDL

[utri007]

xRick wich is SDL frontend of Rick Dangerus, it is also faster with 68k amigas than PPC amigas, if we compare frames per mhz

Rick Dangerous as we know, plays about 2 frames per second and it is NOT possible, that kind of program plays faster with our amigas.

Or wait a minit.... are I'm wrong, how did native Rick Dangerous performs? was it bog slow? totally unplayable??

[wawrzon]

the benchmarks should be made loading a page saved locally to a harddrive, displayed in same resolution in the same screen depth. if done like that they are meaningful.

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 dont know but it is perfectly possible that resolution of netsurf on a classic was set to 800x600x16, there is no pages on internet that you can watch comfortably in a lower resolution and every amiga gfx card is capable to display this and more. i myself was setting netsurf 68k window on my a4k to about 1000x1000 when i was using it.

besides for the end user who doesnt care about processors instruction set, compile options and the gui frontend used but if application works and how fast, the comparison between os4 implementation and 68k port is perfectly sane. you, chris, should be interested yourself to identify bottlenecks, in case the comparison was fair.

äh, edit:
in particular:

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.

might be that risc ppc processors are actually by default slower per clock than cisc 68k counterparts, as they were invented to allow them to run at for that time technology otherwise unreachable higher clocks, but then it remains an argument, because people usually count cpu speed in mhz, as in 660mhz sam440 vs amiga060/50. why argue with that?

[unusedunused]

>the benchmarks should be made loading a page saved locally to a harddrive, displayed in >same resolution in the same screen depth. if done like that they are meaningful.

thats best.but as we can see the 1 GHZ G4 with 45% more clockspeed is 2.3* faster as the SAM 667 MHZ.
so can see inet seem no bottleneck.the G4 boost netsurf a lot in performance /MHZ, so there seem no time for inet wait loss.

maybe can look how much faster blender is on G4 in compare to SAM.I dont think its more that 2.3*

I see here

http://www.eofw.org/bench/

733 MHZ SAM need 00:19:54.38

1 GHZ G4 need 00:10:50.23.

so speedup of G4 is on blender too around 2 in compare of SAM

and last not least we talk not about some few 20-30% we talk about 3* more speed of netsurf 68k

[haywirepc]

May seem like a strange idea, but due to the load times of many pages and lack of processing power of many classic amigas...
 
What if you had netbrowse run in its own screen as a background task behind workbench? If you want to browse you switch screens, type in web address, then switch back for awhile and do something else in workbench as your page loads.
 
Steven

[chris]

the benchmarks should be made loading a page saved locally to a harddrive, displayed in same resolution in the same screen depth. if done like that they are meaningful.

Only if compiled and running on the same CPU too.

i dont know but it is perfectly possible that resolution of netsurf on a classic was set to 800x600x16

To clarify, this is the reported resolution on classic in Bernd's orignal email.  I was doubting that the OS4 machines had been set to this (although 16-bit creates a bottleneck on NetSurf-OS4 anyway, so I'd rather any tests were done in 32-bit mode)

besides for the end user who doesnt care about processors instruction set, compile options and the gui frontend used but if application works and how fast, the comparison between os4 implementation and 68k port is perfectly sane. you, chris, should be interested yourself to identify bottlenecks, in case the comparison was fair.

That would be fine if it was a fair comparison, but it isn't.  It may as well have been comparing NetSurf OS4 to Lynx running on Mac OSX for the amount of useful data it generated.

See also:
http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-July/002523.html
http://wiki.answers.com/Q/What_is_a_controlled_experiment

Chris

[wawrzon]

Only if compiled and running on the same CPU too.

if i get you right, you mean you dont want to compare two things at a time: architecture and the software implementation. otherwise the result of comparing something to itself on the same cpu should be always 1:1. the problem is sometimes architecture implies the implementation, like for instance ppc/os4>reaction. generally i think you may compare everythyng to anything as soon as you have set a single benchmark. in this case its netsurf engine. of course the benchmark becomes increasingly meaningful when narrowing test categories, but one has to start somewhere.

To clarify, this is the reported resolution on classic in Bernd's orignal email.  I was doubting that the OS4 machines had been set to this (although 16-bit creates a bottleneck on NetSurf-OS4 anyway, so I'd rather any tests were done in 32-bit mode)

wasnt then the testcase in favour of ppc/os4 anyway? i thought 32bit was choosen there.

That would be fine if it was a fair comparison, but it isn't.  It may as well have been comparing NetSurf OS4 to Lynx running on Mac OSX for the amount of useful data it generated.

i would call it a fair testcase if we were comparing different browsers on different architectures. we wonder why amiga (68k) sdl and os4 reaction netsurf ports are so slow in comparison to native risc os 68k implementation. this implementation differs as much from both as os4 differs from 68k, you dont find it a question worth examinating, do you? just being comfortable that it runs on os4 at all since the cpu is fast enough?

See also:
http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-July/002523.html
http://wiki.answers.com/Q/What_is_a_controlled_experiment

Chris

will check this out as soon i can.

[chris]

if i get you right, you mean you dont want to compare two things at a time: architecture and the software implementation. otherwise the result of comparing something to itself on the same cpu should be always 1:1. the problem is sometimes architecture implies the implementation, like for instance ppc/os4>reaction. generally i think you may compare everythyng to anything as soon as you have set a single benchmark. in this case its netsurf engine. of course the benchmark becomes increasingly meaningful when narrowing test categories, but one has to start somewhere.

If you're comparing the NetSurf engine then you need to compare it fairly.  ie. run both engines on the same computer under the same conditions.

wasnt then the testcase in favour of ppc/os4 anyway? i thought 32bit was choosen there.

No idea, wasn't mentioned.

i would call it a fair testcase if we were comparing different browsers on different architectures.

Why?  What is that proving?  That a 3GHz Core Duo runs Firefox faster than a 667MHz PPC440 can run NetSurf?  That means nothing to me.  However, if somebody was comparing Timberwolf to NetSurf on the same hardware then they might be making a valid point.

Even comparing NetSurf GTK under Linux on a SAM440 to NetSurf under OS4 on the same hardware would be more useful, but even then you don't know if any differences are due to the frontend or the OS.

we wonder why amiga (68k) sdl and os4 reaction netsurf ports are so slow in comparison to native risc os 68k implementation.

RISC OS runs on ARM.  As I'm sure you'll know, ARM chips are blazingly fast.  You can do some comparisons from the screenshots:

BBC
RISC OS: 11.1s
AmigaOS4: 12.9s

NetSurf
RISC OS: 1.6s
AmigaOS4: 2.8s

Wikipedia
RISC OS: 4.9s
AmigaOS4: 12.8s (although more of the page is displayed for some reason)

What does that tell me?  That NetSurf on some unknown RISC OS hardware configuration is faster than NetSurf on my lowly 600MHz SAM440?  If RISC OS is running on a 600MHz ARM would that mean anything more?  No, there are too many variables to say why there is a speed difference.  The Wikipedia screenshot might be slower because on that one, I used libmng instead of libpng for decoding PNGs.  Maybe I had something intensive running in the background, like a compile or TuneNet.

this implementation differs as much from both as os4 differs from 68k, you dont find it a question worth examinating, do you?

I've just examined it and came to no conclusions, except that it is as meaningless a comparison as the original one.

just being comfortable that it runs on os4 at all since the cpu is fast enough?

I think you're missing the point.  Compared to other CSS browsers on OS4 it is faster.  Therefore I don't think it is likely that there is a major slowdown issue.  I accept that some optimisations could be done (16-bit screenmodes, text size calculations), but it is unlikely that the speed difference is anywhere near what Bernd is quoting.

[gigogne]

Any news ?
 
Can we hope having a new browser with CSS support on classic amiga without graphic card.