Announcement

Collapse
No announcement yet.

New Ruby Benchmarks On GCC vs. LLVM Clang Compilers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Yeah I know they work with LTO. What I mean is I want some of the benefits *without* having to use LTO. gc-sections is greatly faster than LTO, but it doesn't work currently for C++ classes with interfaces.

    If you point me to way to benchmark webkit, I can give it a try this release period.
    That is pretty simple to do with webkitfltk, at least for page (dom/svg) rendering. I've committed an app that exits as soon as the page is finished rendering, grab webkitfltk from git to try.

    Code:
    /*
    	(C) Lauri Kasanen
    	Under the GPLv3.
    
    	Sample app for webkitfltk that exits as soon as a page is fully loaded.
    	Use for timed DOM/SVG/rendering benchmarks.
    */
    
    #include "webkit.h"
    
    static bool loaded = false;
    static Fl_Window *win;
    
    class myview: public webview {
    public:
    	myview(int x, int y, int w, int h): webview(x, y, w, h) {}
    
    	void draw() override {
    		webview::draw();
    
    		// If we drew after the page was loaded, time to exit
    		if (loaded) win->hide();
    	}
    
    };
    
    static myview *v;
    
    static void progress(webview *, const float amount) {
    	if (amount > 0.999f) {
    		loaded = true;
    	}
    }
    
    int main(int argc, char **argv) {
    
    	webkitInit();
    	win = new Fl_Window(800, 600);
    	v = new myview(0, 0, 800, 600);
    	win->end();
    	win->show(argc, argv);
    
    	v->progressChangedCB(progress);
    
    	if (argc > 1)
    		v->load(argv[1]);
    	else
    		v->load("http://google.com");
    
    	Fl::run();
    
    	// Give everything the chance to cleanup
    	delete win;
    	wk_drop_caches();
    
    	return 0;
    }

    Comment


    • #12
      To benchmark JavaScriptCore. Disable JIT and then run one of the benchmark that isn't math oriented. This will give you a benchmark of most JavaScript performance, since most in the real world isn't tight loops that can be JITed only benchmarks are. Though it is not trivial to keep LLint and not JIT. For WebKit styling and layout you can archive your facebook feed after scrolling down so it is really nice and long, and run valgrind on that. That will give you a lot of elements and CSS updated dynamically by javascript. Valgrind is needed because otherwise you just measure network performance, and uptimizing webengines is either pointless benchmarks or real-world webpages already optimized to be fast enough even on weak devices, and only worth optimizing to save processing power thereby increasing battery life.

      Comment


      • #13
        LLint without JIT is trivial with WebkitFLTK, given it's the default

        (background: no matter what I could not get the webkit JIT to be stable, the CStack work keeps corrupting the stack, crashing and burning. So JIT is disabled, and not only are things stable, it saves a lot of RAM and removes microstutter. On the other hand certain pages that load a gig of JS are not usable, but meh, those pages deserve to die anyway.)

        Comment

        Working...
        X