Re: nspluginwrapper (was: Re: Wow... (<-- blown away at performance))
On Saturday 23 April 2011 04:11 pm, Benjamin Kaduk wrote: > On Thu, 31 Mar 2011, Benjamin Kaduk wrote: > > On Thu, 31 Mar 2011, Jung-uk Kim wrote: > >> On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: > >>> i just noticed the WWW links in pkg-descr of boths > >>> nspluginwrapper and nspluginwrapper-devel are broken. i believe > >>> [1] is the current location. > >>> > >>> cheers. > >>> alex > >>> > >>> [1] https://github.com/davidben/nspluginwrapper > >> > >> No, this is actually a fork. The original author disappeared > >> and this guy picked it up from the last snapshot release. > >> Please note there was no official release from this tree yet. > >> If this guy actually produces something useful, > >> www/nspluginwrapper-devel may switch later, of course. > > > > Yes, this is a fork, but he is serious about cleaning up the code > > and is planning to become the new upstream. He was actually just > > in the office here this afternoon commenting how introducing a > > feature to configure that causes unknown options to be errors > > would cause most distros' packaging to break. Please do continue > > to follow it, as I expect it will come to fruition. > > Replying to this old thread, David tells me he has rolled a > release, and has gained the old maintainer's blessing: > http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-Apri >l/msg6.html > http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-Apri >l/msg3.html www/nspluginwrapper-devel is updated to 1.3.2. Cheers, Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nspluginwrapper (was: Re: Wow... (<-- blown away at performance))
On Thu, 31 Mar 2011, Benjamin Kaduk wrote: On Thu, 31 Mar 2011, Jung-uk Kim wrote: On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper No, this is actually a fork. The original author disappeared and this guy picked it up from the last snapshot release. Please note there was no official release from this tree yet. If this guy actually produces something useful, www/nspluginwrapper-devel may switch later, of course. Yes, this is a fork, but he is serious about cleaning up the code and is planning to become the new upstream. He was actually just in the office here this afternoon commenting how introducing a feature to configure that causes unknown options to be errors would cause most distros' packaging to break. Please do continue to follow it, as I expect it will come to fruition. Replying to this old thread, David tells me he has rolled a release, and has gained the old maintainer's blessing: http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-April/msg6.html http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-April/msg3.html -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Thu, 31 Mar 2011, Jung-uk Kim wrote: On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper No, this is actually a fork. The original author disappeared and this guy picked it up from the last snapshot release. Please note there was no official release from this tree yet. If this guy actually produces something useful, www/nspluginwrapper-devel may switch later, of course. Yes, this is a fork, but he is serious about cleaning up the code and is planning to become the new upstream. He was actually just in the office here this afternoon commenting how introducing a feature to configure that causes unknown options to be errors would cause most distros' packaging to break. Please do continue to follow it, as I expect it will come to fruition. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: > On Thu Mar 31 11, Jung-uk Kim wrote: > > On Thursday 31 March 2011 01:58 am, Jung-uk Kim wrote: > > > I wrote an ugly but very simple workaround. Drop the attached > > > patch in www/nspluginwrapper-devel/files and replaces old one, > > > rebuild, reinstall, redo plugin wrappers, etc., etc... > > > > I just went ahead and committed slightly improved version of this > > patch (nspluginwrapper-1.3.0_9) for the "right-click hang" > > problem. > > thanks. > > i just noticed the WWW links in pkg-descr of boths nspluginwrapper > and nspluginwrapper-devel are broken. i believe [1] is the current > location. > > cheers. > alex > > [1] https://github.com/davidben/nspluginwrapper No, this is actually a fork. The original author disappeared and this guy picked it up from the last snapshot release. Please note there was no official release from this tree yet. If this guy actually produces something useful, www/nspluginwrapper-devel may switch later, of course. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Thu Mar 31 11, Jung-uk Kim wrote: > On Thursday 31 March 2011 01:58 am, Jung-uk Kim wrote: > > I wrote an ugly but very simple workaround. Drop the attached > > patch in www/nspluginwrapper-devel/files and replaces old one, > > rebuild, reinstall, redo plugin wrappers, etc., etc... > > I just went ahead and committed slightly improved version of this > patch (nspluginwrapper-1.3.0_9) for the "right-click hang" problem. thanks. i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper > > FYI... > > Jung-uk Kim -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Thursday 31 March 2011 01:58 am, Jung-uk Kim wrote: > I wrote an ugly but very simple workaround. Drop the attached > patch in www/nspluginwrapper-devel/files and replaces old one, > rebuild, reinstall, redo plugin wrappers, etc., etc... I just went ahead and committed slightly improved version of this patch (nspluginwrapper-1.3.0_9) for the "right-click hang" problem. FYI... Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
Quoting Jung-uk Kim (from Wed, 30 Mar 2011 12:50:04 -0400): Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try "GDK_NATIVE_WINDOWS Flash" on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. If you want me to generate a FreeBSD specific linux-f10-gtk just give me a heads-up with a patch which applies to the currently used gtk version. Bye, Alexander. -- Ankh if you love Isis. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wednesday 30 March 2011 04:54 pm, Alexander Best wrote:
> On Wed Mar 30 11, Jung-uk Kim wrote:
> > On Wednesday 30 March 2011 12:50 pm, Jung-uk Kim wrote:
> > > On Wednesday 30 March 2011 12:46 am, Buganini wrote:
> > > > It seems work well now, no lockup when I went through pages.
> > > > but I still got lockup when I right-click on some flash
> > > > advertisement. for example, here: http://tw.yahoo.com/
> > >
> > > "Don't do that" is not an answer, I guess? ;-)
> > >
> > > Seriously, this problem is very well known. There were several
> > > work-arounds suggested but the most popular one is setting
> > > GDK_NATIVE_WINDOWS environment variable. Try
> > > "GDK_NATIVE_WINDOWS Flash" on Google and you will see tons of
> > > them. Actually, Fedora took that hack into nspluginwrapper
> > > later:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=542424
> > >
> > > Basically, Gnome people broke the ABI in the middle of major
> > > release branch, if my understanding is correct. Of course,
> > > that caused a lot of complaints and they had to add the
> > > variable to restore the previous behavior. Now here is the bad
> > > news for you. This environment variable does nothing for us
> > > because
> > > linux-f10-gtk2-2.14.7 does not have the compat hack. :-(
> > >
> > > One thing we can do is re-rolling linux-f10-gtk2 with the hack
> > > locally (as we did for x11-toolkits/linux-f10-pango) and using
> > > the hack from www/nspluginwrapper-devel *iff* that actually
> > > fixes the problem.
> > >
> > > There was another attempt by PC-BSD to address this issue:
> > >
> > > http://trac.pcbsd.org/changeset/3799
> > >
> > > Unfortunately, I have no idea how Pango can affect the "right
> > > click" problem in the first place. In fact, I wasn't able to
> > > reproduce the fix on FreeBSD (long ago) and I *thought* their
> > > fix is PBI-specific (kmoore added to CC list).
> >
> > I forgot one important thing. Actually, this problem only
> > started happening from Flash plugin 10.1. So, the easist
> > workaround is going back to the last 10.0 release (e.g.,
> > 10.0.45.2 does not have this issue). You can find old versions
> > from here:
>
> just wanted to report that the bug still exists in flash 11.
I wrote an ugly but very simple workaround. Drop the attached patch
in www/nspluginwrapper-devel/files and replaces old one, rebuild,
reinstall, redo plugin wrappers, etc., etc...
Cheers,
JK
> > http://kb2.adobe.com/cps/142/tn_14266.html
> >
> > FYI, the following Chromium PR has the most plausible root-cause
> > analysis of this problem I've ever seen on the Net:
> >
> > http://code.google.com/p/chromium/issues/detail?id=40157
> >
> > Just in case if anyone is capable and willing to fix it for
> > good...
> >
> > Jung-uk Kim
--- src/npw-wrapper.c.orig 2011-03-30 19:53:27.0 -0400
+++ src/npw-wrapper.c 2011-03-30 19:54:15.0 -0400
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2560,6 +2561,24 @@
return ret;
}
+#defineNPW_ADOBE_FLASH_NAME"Shockwave Flash"
+
+// Detect Adobe Flash plugin version
+static float is_adobe_flash(void)
+{
+ static float version = 0.0;
+ static bool tested = false;
+
+ if (!tested) {
+ if (strcmp(g_plugin.name, NPW_ADOBE_FLASH_NAME) == 0 &&
+ strncmp(g_plugin.description, NPW_ADOBE_FLASH_NAME,
+ strlen(NPW_ADOBE_FLASH_NAME)) == 0)
+ version = strtof(g_plugin.description +
strlen(NPW_ADOBE_FLASH_NAME), NULL);
+ tested = true;
+ }
+ return version;
+}
+
static int16 g_NPP_HandleEvent(NPP instance, void *event)
{
if (instance == NULL)
@@ -2569,6 +2588,13 @@
if (plugin == NULL)
return NPERR_INVALID_INSTANCE_ERROR;
+ if (((NPEvent *)event)->type == ButtonPress &&
+ ((XButtonEvent *)event)->button == Button3 &&
+ is_adobe_flash() >= 10.1) {
+ /* XXX: work around "right click" hang with Flash plugin 10.1 and later
*/
+ D(bug("NPP_HandleEvent instance=%p: Button3 pressed on SWF\n",
instance));
+ return true;
+ }
if (((NPEvent *)event)->type == GraphicsExpose) {
/* XXX: flush the X output buffer so that the call to
gdk_pixmap_foreign_new() in the viewer can work */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wed Mar 30 11, Jung-uk Kim wrote: > On Wednesday 30 March 2011 12:50 pm, Jung-uk Kim wrote: > > On Wednesday 30 March 2011 12:46 am, Buganini wrote: > > > It seems work well now, no lockup when I went through pages. > > > but I still got lockup when I right-click on some flash > > > advertisement. for example, here: http://tw.yahoo.com/ > > > > "Don't do that" is not an answer, I guess? ;-) > > > > Seriously, this problem is very well known. There were several > > work-arounds suggested but the most popular one is setting > > GDK_NATIVE_WINDOWS environment variable. Try "GDK_NATIVE_WINDOWS > > Flash" on Google and you will see tons of them. Actually, Fedora > > took that hack into nspluginwrapper later: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=542424 > > > > Basically, Gnome people broke the ABI in the middle of major > > release branch, if my understanding is correct. Of course, that > > caused a lot of complaints and they had to add the variable to > > restore the previous behavior. Now here is the bad news for you. > > This environment variable does nothing for us because > > linux-f10-gtk2-2.14.7 does not have the compat hack. :-( > > > > One thing we can do is re-rolling linux-f10-gtk2 with the hack > > locally (as we did for x11-toolkits/linux-f10-pango) and using the > > hack from www/nspluginwrapper-devel *iff* that actually fixes the > > problem. > > > > There was another attempt by PC-BSD to address this issue: > > > > http://trac.pcbsd.org/changeset/3799 > > > > Unfortunately, I have no idea how Pango can affect the "right > > click" problem in the first place. In fact, I wasn't able to > > reproduce the fix on FreeBSD (long ago) and I *thought* their fix > > is PBI-specific (kmoore added to CC list). > > I forgot one important thing. Actually, this problem only started > happening from Flash plugin 10.1. So, the easist workaround is going > back to the last 10.0 release (e.g., 10.0.45.2 does not have this > issue). You can find old versions from here: just wanted to report that the bug still exists in flash 11. > > http://kb2.adobe.com/cps/142/tn_14266.html > > FYI, the following Chromium PR has the most plausible root-cause > analysis of this problem I've ever seen on the Net: > > http://code.google.com/p/chromium/issues/detail?id=40157 > > Just in case if anyone is capable and willing to fix it for good... > > Jung-uk Kim -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On 03/30/2011 12:50, Jung-uk Kim wrote: On Wednesday 30 March 2011 12:46 am, Buganini wrote: It seems work well now, no lockup when I went through pages. but I still got lockup when I right-click on some flash advertisement. for example, here: http://tw.yahoo.com/ "Don't do that" is not an answer, I guess? ;-) Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try "GDK_NATIVE_WINDOWS Flash" on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. There was another attempt by PC-BSD to address this issue: http://trac.pcbsd.org/changeset/3799 Unfortunately, I have no idea how Pango can affect the "right click" problem in the first place. In fact, I wasn't able to reproduce the fix on FreeBSD (long ago) and I *thought* their fix is PBI-specific (kmoore added to CC list). Jung-uk Kim I checked the other day, and our pango fix is no longer functional, that was something we did for flash 9 back in the day and it seemed to fix the right-click functionality for our PBIs, but alas, no more. We are in the same boat as you at the moment. -- Kris Moore PC-BSD Software iXsystems ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wednesday 30 March 2011 12:50 pm, Jung-uk Kim wrote: > On Wednesday 30 March 2011 12:46 am, Buganini wrote: > > It seems work well now, no lockup when I went through pages. > > but I still got lockup when I right-click on some flash > > advertisement. for example, here: http://tw.yahoo.com/ > > "Don't do that" is not an answer, I guess? ;-) > > Seriously, this problem is very well known. There were several > work-arounds suggested but the most popular one is setting > GDK_NATIVE_WINDOWS environment variable. Try "GDK_NATIVE_WINDOWS > Flash" on Google and you will see tons of them. Actually, Fedora > took that hack into nspluginwrapper later: > > https://bugzilla.redhat.com/show_bug.cgi?id=542424 > > Basically, Gnome people broke the ABI in the middle of major > release branch, if my understanding is correct. Of course, that > caused a lot of complaints and they had to add the variable to > restore the previous behavior. Now here is the bad news for you. > This environment variable does nothing for us because > linux-f10-gtk2-2.14.7 does not have the compat hack. :-( > > One thing we can do is re-rolling linux-f10-gtk2 with the hack > locally (as we did for x11-toolkits/linux-f10-pango) and using the > hack from www/nspluginwrapper-devel *iff* that actually fixes the > problem. > > There was another attempt by PC-BSD to address this issue: > > http://trac.pcbsd.org/changeset/3799 > > Unfortunately, I have no idea how Pango can affect the "right > click" problem in the first place. In fact, I wasn't able to > reproduce the fix on FreeBSD (long ago) and I *thought* their fix > is PBI-specific (kmoore added to CC list). I forgot one important thing. Actually, this problem only started happening from Flash plugin 10.1. So, the easist workaround is going back to the last 10.0 release (e.g., 10.0.45.2 does not have this issue). You can find old versions from here: http://kb2.adobe.com/cps/142/tn_14266.html FYI, the following Chromium PR has the most plausible root-cause analysis of this problem I've ever seen on the Net: http://code.google.com/p/chromium/issues/detail?id=40157 Just in case if anyone is capable and willing to fix it for good... Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wednesday 30 March 2011 12:46 am, Buganini wrote: > It seems work well now, no lockup when I went through pages. > but I still got lockup when I right-click on some flash > advertisement. for example, here: http://tw.yahoo.com/ "Don't do that" is not an answer, I guess? ;-) Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try "GDK_NATIVE_WINDOWS Flash" on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. There was another attempt by PC-BSD to address this issue: http://trac.pcbsd.org/changeset/3799 Unfortunately, I have no idea how Pango can affect the "right click" problem in the first place. In fact, I wasn't able to reproduce the fix on FreeBSD (long ago) and I *thought* their fix is PBI-specific (kmoore added to CC list). Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
It seems work well now, no lockup when I went through pages. but I still got lockup when I right-click on some flash advertisement. for example, here: http://tw.yahoo.com/ and notice that if your browser doesn't have flashplayer installed, the website will use js instead. Regards, Buganini ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Tue, Mar 29, 2011 at 7:21 PM, Alexander Best wrote: > On Wed Mar 30 11, Alexander Best wrote: >> On Tue Mar 29 11, Jung-uk Kim wrote: >> > On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: >> > > On Wed Mar 30 11, Buganini wrote: >> > > > Could this help? >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=680279 >> > > > >> > > > On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper >> > wrote: >> > > > > ??? ???Also, it looks like npviewer.bin still hangs to resources on >> > > > > until Firefox closes (or I kill it :)..), so something still >> > > > > needs to be resolved there, but that isn't a regression (it's >> > > > > acted that way for ages), and shouldn't be too hard to do. >> > > > >> > > > the fix is included in the latest nspluginwrapper-devel update, >> > > > i'm going to try it. >> > > >> > > i was able to build the latest nspluginwrapper version via github >> > > [1]. however i cannot install any plugins due to the following >> > > error: >> > > >> > > nspluginwrapper: no appropriate viewer found for >> > > /home/arundel/.mozilla/plugins/libflashplayer.so >> > > >> > > [1] https://github.com/davidben/nspluginwrapper >> > >> > Update your ports, install www/nspluginwrapper-devel, reinstall your >> > plugins, and enjoy. ;-) >> >> whooo. thanks a bunch. :) > > getting between 25 and 30 fps on 720p youtube flicks without hw acceleration > running flash 11,0,0,60. > > also nspluginwrapper hasn't crashed since yet. looking really well. :) > >> >> > >> > Jung-uk Kim >> >> -- >> a13x > > -- > a13x I've been visiting sites which normally cause problems, sites which normally force me to run the infamous `killall npviewer.bin`. I haven't experienced a single lock-up so far (nor have I seen ANY hiccups). Also, the flash objects load rather quickly; very cool... -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wed Mar 30 11, Alexander Best wrote: > On Tue Mar 29 11, Jung-uk Kim wrote: > > On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: > > > On Wed Mar 30 11, Buganini wrote: > > > > Could this help? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=680279 > > > > > > > > On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper > > wrote: > > > > > ??? ???Also, it looks like npviewer.bin still hangs to resources on > > > > > until Firefox closes (or I kill it :)..), so something still > > > > > needs to be resolved there, but that isn't a regression (it's > > > > > acted that way for ages), and shouldn't be too hard to do. > > > > > > > > the fix is included in the latest nspluginwrapper-devel update, > > > > i'm going to try it. > > > > > > i was able to build the latest nspluginwrapper version via github > > > [1]. however i cannot install any plugins due to the following > > > error: > > > > > > nspluginwrapper: no appropriate viewer found for > > > /home/arundel/.mozilla/plugins/libflashplayer.so > > > > > > [1] https://github.com/davidben/nspluginwrapper > > > > Update your ports, install www/nspluginwrapper-devel, reinstall your > > plugins, and enjoy. ;-) > > whooo. thanks a bunch. :) getting between 25 and 30 fps on 720p youtube flicks without hw acceleration running flash 11,0,0,60. also nspluginwrapper hasn't crashed since yet. looking really well. :) > > > > > Jung-uk Kim > > -- > a13x -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Tue Mar 29 11, Jung-uk Kim wrote: > On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: > > On Wed Mar 30 11, Buganini wrote: > > > Could this help? > > > https://bugzilla.redhat.com/show_bug.cgi?id=680279 > > > > > > On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper > wrote: > > > > ??? ???Also, it looks like npviewer.bin still hangs to resources on > > > > until Firefox closes (or I kill it :)..), so something still > > > > needs to be resolved there, but that isn't a regression (it's > > > > acted that way for ages), and shouldn't be too hard to do. > > > > > > the fix is included in the latest nspluginwrapper-devel update, > > > i'm going to try it. > > > > i was able to build the latest nspluginwrapper version via github > > [1]. however i cannot install any plugins due to the following > > error: > > > > nspluginwrapper: no appropriate viewer found for > > /home/arundel/.mozilla/plugins/libflashplayer.so > > > > [1] https://github.com/davidben/nspluginwrapper > > Update your ports, install www/nspluginwrapper-devel, reinstall your > plugins, and enjoy. ;-) whooo. thanks a bunch. :) > > Jung-uk Kim -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: > On Wed Mar 30 11, Buganini wrote: > > Could this help? > > https://bugzilla.redhat.com/show_bug.cgi?id=680279 > > > > On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper wrote: > > > � �Also, it looks like npviewer.bin still hangs to resources on > > > until Firefox closes (or I kill it :)..), so something still > > > needs to be resolved there, but that isn't a regression (it's > > > acted that way for ages), and shouldn't be too hard to do. > > > > the fix is included in the latest nspluginwrapper-devel update, > > i'm going to try it. > > i was able to build the latest nspluginwrapper version via github > [1]. however i cannot install any plugins due to the following > error: > > nspluginwrapper: no appropriate viewer found for > /home/arundel/.mozilla/plugins/libflashplayer.so > > [1] https://github.com/davidben/nspluginwrapper Update your ports, install www/nspluginwrapper-devel, reinstall your plugins, and enjoy. ;-) Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wed Mar 30 11, Buganini wrote: > Could this help? > https://bugzilla.redhat.com/show_bug.cgi?id=680279 > > On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper wrote: > > Also, it looks like npviewer.bin still hangs to resources on until > > Firefox closes (or I kill it :)..), so something still needs to be > > resolved there, but that isn't a regression (it's acted that way for > > ages), and shouldn't be too hard to do. > > the fix is included in the latest nspluginwrapper-devel update, > i'm going to try it. i was able to build the latest nspluginwrapper version via github [1]. however i cannot install any plugins due to the following error: nspluginwrapper: no appropriate viewer found for /home/arundel/.mozilla/plugins/libflashplayer.so [1] https://github.com/davidben/nspluginwrapper > > > Regards, > Buganini -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
Could this help? https://bugzilla.redhat.com/show_bug.cgi?id=680279 On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper wrote: > Also, it looks like npviewer.bin still hangs to resources on until > Firefox closes (or I kill it :)..), so something still needs to be > resolved there, but that isn't a regression (it's acted that way for > ages), and shouldn't be too hard to do. the fix is included in the latest nspluginwrapper-devel update, i'm going to try it. Regards, Buganini ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On 23 February 2011 21:17, John Baldwin wrote: > On Wednesday, February 23, 2011 2:11:35 pm Ivan Voras wrote: >> On 22/02/2011 23:33, Alexander Best wrote: >> >> > Also, it looks like npviewer.bin still hangs to resources on > until >> > Firefox closes (or I kill it :)..), so something still needs to be >> > resolved there, but that isn't a regression (it's acted that way for >> > ages), and shouldn't be too hard to do. >> >> While on the subject - any ideas why npviewer.bin is present as so many >> processes? They all appear to have some identical properties, most >> curiously their memory usage, so shouldn't they be threads? > > Threads in Linux processes show up as individual processes. Ah, ok. This was "fixed" in Linux (in their nptl project cca 2005) so I assumed it was also fixed here. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wednesday, February 23, 2011 2:11:35 pm Ivan Voras wrote: > On 22/02/2011 23:33, Alexander Best wrote: > > > Also, it looks like npviewer.bin still hangs to resources on until > > Firefox closes (or I kill it :)..), so something still needs to be > > resolved there, but that isn't a regression (it's acted that way for > > ages), and shouldn't be too hard to do. > > While on the subject - any ideas why npviewer.bin is present as so many > processes? They all appear to have some identical properties, most > curiously their memory usage, so shouldn't they be threads? Threads in Linux processes show up as individual processes. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wed Feb 23 11, John Baldwin wrote: > On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >>I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >>Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > futex > > > > issue in combination with a high number of threads. this is the output > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=64 > > > >ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=128 > > > >ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments:
Re: Wow... (<-- blown away at performance)
On 22/02/2011 23:33, Alexander Best wrote: Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. While on the subject - any ideas why npviewer.bin is present as so many processes? They all appear to have some identical properties, most curiously their memory usage, so shouldn't they be threads? betelgeuse:~> ps axu | grep npv ivoras 7775 0.0 1.3 695332 55760 ?? S 8:03pm 0:11.84 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7787 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.86 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7788 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7789 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7790 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7791 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7792 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7793 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.51 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7794 0.0 1.3 695332 55760 ?? I 8:03pm 0:00.00 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7795 0.0 1.3 695332 55760 ?? S 8:03pm 0:00.01 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7796 0.0 1.3 695332 55760 ?? I 8:03pm 0:00.44 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7797 0.0 1.3 695332 55760 ?? S 8:03pm 0:03.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7798 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7799 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7800 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7801 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.38 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7802 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7803 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7804 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7805 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.38 /usr/local/lib/ns ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Wed Feb 23 11, John Baldwin wrote: > On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >>I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >>Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > futex > > > > issue in combination with a high number of threads. this is the output > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=64 > > > >ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments: iterations=1 threads=128 > > > >ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > >Arguments:
Re: Wow... (<-- blown away at performance)
On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: > On Tue Feb 22 11, Brandon Gooch wrote: > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > > On Tue Feb 22 11, Garrett Cooper wrote: > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > >> >>I don't know what to say, but r218938 screams with flash videos > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > >> >> in parallel (5 total with other miscellaneous flash animation) without > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > >> >> instances of firefox properly now. Hopefully this version fares better > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > >> >> where my system just hardlocked for no apparent reason). > > >> >>Anyhow, hope others have similar results. > > >> >> Cheers! > > >> >> -Garrett > > >> >> > > >> >> $ uname -a > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > >> >> Mon Feb 21 23:10:51 PST 2011 > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > >> > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > > >> > performance to learn more about. Youtube already use them since 10.2 > > >> > beta > > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > >> more than 200% increase (now it actually scales between multiple > > >> instances, instead of croaks with one instance, tiling up and down the > > >> screen when moving the window slider for instance or switching tabs). > > >> Besides, it seems like it needs external support from the video > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > >> Also, it looks like npviewer.bin still hangs to resources on until > > >> Firefox closes (or I kill it :)..), so something still needs to be > > >> resolved there, but that isn't a regression (it's acted that way for > > >> ages), and shouldn't be too hard to do. > > > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > > issue in combination with a high number of threads. this is the output of a > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=1 > > > Result: 18622 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=2 > > > Result: 15469 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=3 > > > Result: 12713 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=4 > > > Result: 12247 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=5 > > > Result: 11814 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=6 > > > Result: 13468 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=8 > > > Result: 12061 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=10 > > > Result: 12854 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=12 > > > Result: 12999 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=16 > > > Result: 12402 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=24 > > > Result: 9815 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=32 > > > Result: 8518 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=64 > > >ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=128 > > >ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threads=256 > > >ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > >Arguments: iterations=1 threa
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best wrote: > > On Tue Feb 22 11, Alexander Best wrote: > >> On Tue Feb 22 11, Alexander Best wrote: > >> > On Tue Feb 22 11, Brandon Gooch wrote: > >> > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > >> > > wrote: > >> > > > On Tue Feb 22 11, Garrett Cooper wrote: > >> > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > >> > > >> > On 22 February 2011 11:15, Garrett Cooper > >> > > >> > wrote: > >> > > >> >> I don't know what to say, but r218938 screams with flash > >> > > >> >> videos > >> > > >> >> (native Linux speed). Not sure if it's the new binutils or if > >> > > >> >> it's the > >> > > >> >> new linuxulator patches, but I can run multiple instances of > >> > > >> >> youtube > >> > > >> >> in parallel (5 total with other miscellaneous flash animation) > >> > > >> >> without > >> > > >> >> it totally lagging out Firefox/X11, and it appears to close the > >> > > >> >> instances of firefox properly now. Hopefully this version fares > >> > > >> >> better > >> > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks > >> > > >> >> uptime, > >> > > >> >> where my system just hardlocked for no apparent reason). > >> > > >> >> Anyhow, hope others have similar results. > >> > > >> >> Cheers! > >> > > >> >> -Garrett > >> > > >> >> > >> > > >> >> $ uname -a > >> > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > >> > > >> >> r218938M: > >> > > >> >> Mon Feb 21 23:10:51 PST 2011 > >> > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > >> > > >> > > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant > >> > > >> > performance changes in 10.2 (from 10.1). You can search for > >> > > >> > StageVideo > >> > > >> > performance to learn more about. Youtube already use them since > >> > > >> > 10.2 > >> > > >> > beta > >> > > >> > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases > >> > > >> are > >> > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > >> > > >> more than 200% increase (now it actually scales between multiple > >> > > >> instances, instead of croaks with one instance, tiling up and down > >> > > >> the > >> > > >> screen when moving the window slider for instance or switching > >> > > >> tabs). > >> > > >> Besides, it seems like it needs external support from the video > >> > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > >> > > >> Also, it looks like npviewer.bin still hangs to resources on > >> > > >> until > >> > > >> Firefox closes (or I kill it :)..), so something still needs to be > >> > > >> resolved there, but that isn't a regression (it's acted that way for > >> > > >> ages), and shouldn't be too hard to do. > >> > > > > >> > > > i think the problem with npviewer.bin having to be killed by hand is > >> > > > a futex > >> > > > issue in combination with a high number of threads. this is the > >> > > > output of a > >> > > > test from darren hart's futex test suite under freebsd 9.0: > >> > > > > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=1 > >> > > > Result: 18622 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=2 > >> > > > Result: 15469 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=3 > >> > > > Result: 12713 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=4 > >> > > > Result: 12247 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=5 > >> > > > Result: 11814 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=6 > >> > > > Result: 13468 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=8 > >> > > > Result: 12061 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=10 > >> > > > Result: 12854 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=12 > >> > > > Result: 12999 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=16 > >> > > > Result: 12402 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=24 > >> > > > Result: 9815 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=32
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best wrote: > > On Tue Feb 22 11, Alexander Best wrote: > >> On Tue Feb 22 11, Alexander Best wrote: > >> > On Tue Feb 22 11, Brandon Gooch wrote: > >> > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > >> > > wrote: > >> > > > On Tue Feb 22 11, Garrett Cooper wrote: > >> > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > >> > > >> > On 22 February 2011 11:15, Garrett Cooper > >> > > >> > wrote: > >> > > >> >> I don't know what to say, but r218938 screams with flash > >> > > >> >> videos > >> > > >> >> (native Linux speed). Not sure if it's the new binutils or if > >> > > >> >> it's the > >> > > >> >> new linuxulator patches, but I can run multiple instances of > >> > > >> >> youtube > >> > > >> >> in parallel (5 total with other miscellaneous flash animation) > >> > > >> >> without > >> > > >> >> it totally lagging out Firefox/X11, and it appears to close the > >> > > >> >> instances of firefox properly now. Hopefully this version fares > >> > > >> >> better > >> > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks > >> > > >> >> uptime, > >> > > >> >> where my system just hardlocked for no apparent reason). > >> > > >> >> Anyhow, hope others have similar results. > >> > > >> >> Cheers! > >> > > >> >> -Garrett > >> > > >> >> > >> > > >> >> $ uname -a > >> > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > >> > > >> >> r218938M: > >> > > >> >> Mon Feb 21 23:10:51 PST 2011 > >> > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > >> > > >> > > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant > >> > > >> > performance changes in 10.2 (from 10.1). You can search for > >> > > >> > StageVideo > >> > > >> > performance to learn more about. Youtube already use them since > >> > > >> > 10.2 > >> > > >> > beta > >> > > >> > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases > >> > > >> are > >> > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > >> > > >> more than 200% increase (now it actually scales between multiple > >> > > >> instances, instead of croaks with one instance, tiling up and down > >> > > >> the > >> > > >> screen when moving the window slider for instance or switching > >> > > >> tabs). > >> > > >> Besides, it seems like it needs external support from the video > >> > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > >> > > >> Also, it looks like npviewer.bin still hangs to resources on > >> > > >> until > >> > > >> Firefox closes (or I kill it :)..), so something still needs to be > >> > > >> resolved there, but that isn't a regression (it's acted that way for > >> > > >> ages), and shouldn't be too hard to do. > >> > > > > >> > > > i think the problem with npviewer.bin having to be killed by hand is > >> > > > a futex > >> > > > issue in combination with a high number of threads. this is the > >> > > > output of a > >> > > > test from darren hart's futex test suite under freebsd 9.0: > >> > > > > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=1 > >> > > > Result: 18622 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=2 > >> > > > Result: 15469 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=3 > >> > > > Result: 12713 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=4 > >> > > > Result: 12247 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=5 > >> > > > Result: 11814 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=6 > >> > > > Result: 13468 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=8 > >> > > > Result: 12061 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=10 > >> > > > Result: 12854 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=12 > >> > > > Result: 12999 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=16 > >> > > > Result: 12402 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=24 > >> > > > Result: 9815 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=1 threads=32
Re: Wow... (<-- blown away at performance)
On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: >> On Tue Feb 22 11, Alexander Best wrote: >> > On Tue Feb 22 11, Brandon Gooch wrote: >> > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best >> > > wrote: >> > > > On Tue Feb 22 11, Garrett Cooper wrote: >> > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: >> > > >> > On 22 February 2011 11:15, Garrett Cooper >> > > >> > wrote: >> > > >> >> I don't know what to say, but r218938 screams with flash videos >> > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's >> > > >> >> the >> > > >> >> new linuxulator patches, but I can run multiple instances of >> > > >> >> youtube >> > > >> >> in parallel (5 total with other miscellaneous flash animation) >> > > >> >> without >> > > >> >> it totally lagging out Firefox/X11, and it appears to close the >> > > >> >> instances of firefox properly now. Hopefully this version fares >> > > >> >> better >> > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> > > >> >> where my system just hardlocked for no apparent reason). >> > > >> >> Anyhow, hope others have similar results. >> > > >> >> Cheers! >> > > >> >> -Garrett >> > > >> >> >> > > >> >> $ uname -a >> > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 >> > > >> >> r218938M: >> > > >> >> Mon Feb 21 23:10:51 PST 2011 >> > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >> > > >> > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant >> > > >> > performance changes in 10.2 (from 10.1). You can search for >> > > >> > StageVideo >> > > >> > performance to learn more about. Youtube already use them since 10.2 >> > > >> > beta >> > > >> >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are >> > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a >> > > >> more than 200% increase (now it actually scales between multiple >> > > >> instances, instead of croaks with one instance, tiling up and down the >> > > >> screen when moving the window slider for instance or switching tabs). >> > > >> Besides, it seems like it needs external support from the video >> > > >> driver, and I'm not sure that that bridge exists in the linuxulator. >> > > >> Also, it looks like npviewer.bin still hangs to resources on until >> > > >> Firefox closes (or I kill it :)..), so something still needs to be >> > > >> resolved there, but that isn't a regression (it's acted that way for >> > > >> ages), and shouldn't be too hard to do. >> > > > >> > > > i think the problem with npviewer.bin having to be killed by hand is a >> > > > futex >> > > > issue in combination with a high number of threads. this is the output >> > > > of a >> > > > test from darren hart's futex test suite under freebsd 9.0: >> > > > >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=1 >> > > > Result: 18622 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=2 >> > > > Result: 15469 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=3 >> > > > Result: 12713 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=4 >> > > > Result: 12247 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=5 >> > > > Result: 11814 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=6 >> > > > Result: 13468 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=8 >> > > > Result: 12061 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=10 >> > > > Result: 12854 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=12 >> > > > Result: 12999 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=16 >> > > > Result: 12402 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=24 >> > > > Result: 9815 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=32 >> > > > Result: 8518 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=64 >> > > > ERROR: Resource temporarily unavailable: pthread_create >> > > > Result: ERROR >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > >
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > > > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > > > >> >> the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > > > >> >> without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > > > >> >> better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > > > >> > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > > > > futex > > > > issue in combination with a high number of threads. this is the output > > > > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations pe
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > > > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > > > >> >> the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > > > >> >> without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > > > >> >> better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > > > >> > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > > > > futex > > > > issue in combination with a high number of threads. this is the output > > > > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations pe
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Brandon Gooch wrote: > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > > On Tue Feb 22 11, Garrett Cooper wrote: > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > >> >> I don't know what to say, but r218938 screams with flash videos > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > >> >> in parallel (5 total with other miscellaneous flash animation) without > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > >> >> instances of firefox properly now. Hopefully this version fares better > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > >> >> where my system just hardlocked for no apparent reason). > > >> >> Anyhow, hope others have similar results. > > >> >> Cheers! > > >> >> -Garrett > > >> >> > > >> >> $ uname -a > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > >> >> Mon Feb 21 23:10:51 PST 2011 > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > >> > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > > >> > performance to learn more about. Youtube already use them since 10.2 > > >> > beta > > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > >> more than 200% increase (now it actually scales between multiple > > >> instances, instead of croaks with one instance, tiling up and down the > > >> screen when moving the window slider for instance or switching tabs). > > >> Besides, it seems like it needs external support from the video > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > >> Also, it looks like npviewer.bin still hangs to resources on until > > >> Firefox closes (or I kill it :)..), so something still needs to be > > >> resolved there, but that isn't a regression (it's acted that way for > > >> ages), and shouldn't be too hard to do. > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > > > futex > > > issue in combination with a high number of threads. this is the output of > > > a > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=1 > > > Result: 18622 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=2 > > > Result: 15469 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=3 > > > Result: 12713 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=4 > > > Result: 12247 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=5 > > > Result: 11814 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=6 > > > Result: 13468 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=8 > > > Result: 12061 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=10 > > > Result: 12854 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=12 > > > Result: 12999 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=16 > > > Result: 12402 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=24 > > > Result: 9815 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=32 > > > Result: 8518 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=64 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=128 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=256 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=512 > > >
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Brandon Gooch wrote: > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > On Tue Feb 22 11, Garrett Cooper wrote: > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > >> >> I don't know what to say, but r218938 screams with flash videos > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> >> new linuxulator patches, but I can run multiple instances of youtube > >> >> in parallel (5 total with other miscellaneous flash animation) without > >> >> it totally lagging out Firefox/X11, and it appears to close the > >> >> instances of firefox properly now. Hopefully this version fares better > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> >> where my system just hardlocked for no apparent reason). > >> >> Anyhow, hope others have similar results. > >> >> Cheers! > >> >> -Garrett > >> >> > >> >> $ uname -a > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> >> Mon Feb 21 23:10:51 PST 2011 > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > >> > performance to learn more about. Youtube already use them since 10.2 > >> > beta > >> > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > >> more than 200% increase (now it actually scales between multiple > >> instances, instead of croaks with one instance, tiling up and down the > >> screen when moving the window slider for instance or switching tabs). > >> Besides, it seems like it needs external support from the video > >> driver, and I'm not sure that that bridge exists in the linuxulator. > >> Also, it looks like npviewer.bin still hangs to resources on until > >> Firefox closes (or I kill it :)..), so something still needs to be > >> resolved there, but that isn't a regression (it's acted that way for > >> ages), and shouldn't be too hard to do. > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > issue in combination with a high number of threads. this is the output of a > > test from darren hart's futex test suite under freebsd 9.0: > > > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=1 > > Result: 18622 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=2 > > Result: 15469 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=3 > > Result: 12713 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=4 > > Result: 12247 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=5 > > Result: 11814 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=6 > > Result: 13468 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=8 > > Result: 12061 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=10 > > Result: 12854 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=12 > > Result: 12999 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=16 > > Result: 12402 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=24 > > Result: 9815 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=32 > > Result: 8518 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=64 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=128 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=256 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=512 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=1024 > > ERROR: Resource temporarily unavailable:
Re: Wow... (<-- blown away at performance)
On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > On Tue Feb 22 11, Garrett Cooper wrote: >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: >> > On 22 February 2011 11:15, Garrett Cooper wrote: >> >> I don't know what to say, but r218938 screams with flash videos >> >> (native Linux speed). Not sure if it's the new binutils or if it's the >> >> new linuxulator patches, but I can run multiple instances of youtube >> >> in parallel (5 total with other miscellaneous flash animation) without >> >> it totally lagging out Firefox/X11, and it appears to close the >> >> instances of firefox properly now. Hopefully this version fares better >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> >> where my system just hardlocked for no apparent reason). >> >> Anyhow, hope others have similar results. >> >> Cheers! >> >> -Garrett >> >> >> >> $ uname -a >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: >> >> Mon Feb 21 23:10:51 PST 2011 >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >> > >> > Which FlashPlayer version do you test? Adobe has made significant >> > performance changes in 10.2 (from 10.1). You can search for StageVideo >> > performance to learn more about. Youtube already use them since 10.2 >> > beta >> >> linux-f10-flashplugin-10.1r102.65 . The performance increases are >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a >> more than 200% increase (now it actually scales between multiple >> instances, instead of croaks with one instance, tiling up and down the >> screen when moving the window slider for instance or switching tabs). >> Besides, it seems like it needs external support from the video >> driver, and I'm not sure that that bridge exists in the linuxulator. >> Also, it looks like npviewer.bin still hangs to resources on until >> Firefox closes (or I kill it :)..), so something still needs to be >> resolved there, but that isn't a regression (it's acted that way for >> ages), and shouldn't be too hard to do. > > i think the problem with npviewer.bin having to be killed by hand is a futex > issue in combination with a high number of threads. this is the output of a > test from darren hart's futex test suite under freebsd 9.0: > > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=1 > Result: 18622 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=2 > Result: 15469 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=3 > Result: 12713 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=4 > Result: 12247 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=5 > Result: 11814 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=6 > Result: 13468 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=8 > Result: 12061 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=10 > Result: 12854 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=12 > Result: 12999 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=16 > Result: 12402 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=24 > Result: 9815 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=32 > Result: 8518 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=64 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=128 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=256 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=512 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=1024 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > > cheers. > alex Have you found any method or workaround to mitigate this issue? -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freeb
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > On 22 February 2011 11:15, Garrett Cooper wrote: > >> I don't know what to say, but r218938 screams with flash videos > >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> new linuxulator patches, but I can run multiple instances of youtube > >> in parallel (5 total with other miscellaneous flash animation) without > >> it totally lagging out Firefox/X11, and it appears to close the > >> instances of firefox properly now. Hopefully this version fares better > >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> where my system just hardlocked for no apparent reason). > >> Anyhow, hope others have similar results. > >> Cheers! > >> -Garrett > >> > >> $ uname -a > >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> Mon Feb 21 23:10:51 PST 2011 > >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > > Which FlashPlayer version do you test? Adobe has made significant > > performance changes in 10.2 (from 10.1). You can search for StageVideo > > performance to learn more about. Youtube already use them since 10.2 > > beta > > linux-f10-flashplugin-10.1r102.65 . The performance increases are > claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > more than 200% increase (now it actually scales between multiple > instances, instead of croaks with one instance, tiling up and down the > screen when moving the window slider for instance or switching tabs). > Besides, it seems like it needs external support from the video > driver, and I'm not sure that that bridge exists in the linuxulator. > Also, it looks like npviewer.bin still hangs to resources on until > Firefox closes (or I kill it :)..), so something still needs to be > resolved there, but that isn't a regression (it's acted that way for > ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers. alex > Thanks, > -Garrett -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > On 22 February 2011 11:15, Garrett Cooper wrote: >> I don't know what to say, but r218938 screams with flash videos >> (native Linux speed). Not sure if it's the new binutils or if it's the >> new linuxulator patches, but I can run multiple instances of youtube >> in parallel (5 total with other miscellaneous flash animation) without >> it totally lagging out Firefox/X11, and it appears to close the >> instances of firefox properly now. Hopefully this version fares better >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> where my system just hardlocked for no apparent reason). >> Anyhow, hope others have similar results. >> Cheers! >> -Garrett >> >> $ uname -a >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: >> Mon Feb 21 23:10:51 PST 2011 >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > Which FlashPlayer version do you test? Adobe has made significant > performance changes in 10.2 (from 10.1). You can search for StageVideo > performance to learn more about. Youtube already use them since 10.2 > beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be "up to 85%" on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wow... (<-- blown away at performance)
On 22 February 2011 11:15, Garrett Cooper wrote: > I don't know what to say, but r218938 screams with flash videos > (native Linux speed). Not sure if it's the new binutils or if it's the > new linuxulator patches, but I can run multiple instances of youtube > in parallel (5 total with other miscellaneous flash animation) without > it totally lagging out Firefox/X11, and it appears to close the > instances of firefox properly now. Hopefully this version fares better > than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > where my system just hardlocked for no apparent reason). > Anyhow, hope others have similar results. > Cheers! > -Garrett > > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > Mon Feb 21 23:10:51 PST 2011 > gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Wow... (<-- blown away at performance)
I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
