Re: Porting PathScale's EKOPath Compiler Suite
On Thu, 8 Sep 2011 18:11:45 -0400, Jung-uk Kim wrote: > I have done preliminary porting work of PathScale's open-sourced > EKOPath Compiler Suite (https://github.com/pathscale). > > http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 > > This includes experimental OpenMP support and PathDB. Unfortuntely, > PathDB builds fine but just crashes ATM. Both options are turned off > by default for now. Although it seems working fine for many > non-trivial C/C++/Fortran sources, please do not use it for any > serious project because I have seen few internal compiler errors and > crashes. Be aware of ugly hacks! ;-) > > I just wanted to share it now because it was on the WantedPorts list > on Wiki for a while. If anyone with more clues want to pick it up > from here, please feel free. Thanks a lot. I've updated the WantedPorts entry and added a link to the mail so that people find your work. -- Bernhard Fröhlich http://www.bluelife.at/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: excessive use of gettimeofday(2) and other syscalls
On 2011-Sep-07 12:41:54 -0600, Manish Vachharajani wrote: >This is great info, thanks. Is it worth having some kind of >environment variable tunable (or even compile time tunable) to have a >"fast" gettimeofday then? Maybe. rwatson@ produced a preloadable .so to do this - see http://www.watson.org/~robert/freebsd/clock/ > Is there a complimentary body of code that >assumes gettimeofday is precise? I'm not aware of any but it's not necessarily trivial to identify such code - it's unlikely to fail outright but instead may deliver results that may not be as accurate as the author intended. I think a better way of looking at the problem is that some code was designed on the assumption that certain operations were cheap and therefore uses those operations more freely than it would have had those operations been more expensive. -- Peter Jeremy pgp8RtgcBLrmz.pgp Description: PGP signature
RE: Soliciting opinions on an extension of the bootinfo structure
That's correct. This is actually part of a larger effort to open up the MIPS code to a range of new bootstraps. Some bootstraps use the bootinfo facility extensively. It's an easy way to pass some simple information to the kernel without the clutter of metadata and other such things. ... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net -Original Message- From: Peter Wemm [mailto:pe...@wemm.org] Sent: Thursday, September 08, 2011 6:48 PM To: Peter Grehan Cc: Andrew Duane; freebsd-hackers@freebsd.org; freebsd-a...@freebsd.org Subject: Re: Soliciting opinions on an extension of the bootinfo structure On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan wrote: >> I'm proposing an extension framework for the bootinfo structure used >> to pass information from the bootstrap/loader to the kernel. Although >> I'm only proposing this for the MIPS bootinfo, it's completely >> applicable to any of them. >> >> What I propose is adding an optional platform extension structure: >> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT > > Any reason not to put the vendor bits into another piece of loader metadata > ? That seems the extensible way to add additional info from the loader, > rather than extending bootinfo (as was the case pre-loader days). > > later, It sounds like they're not using loader, which is probably a reasonable thing for their environment. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Soliciting opinions on an extension of the bootinfo structure
On Thursday, September 08, 2011 6:25:23 pm Peter Grehan wrote: > > I'm proposing an extension framework for the bootinfo structure used > > to pass information from the bootstrap/loader to the kernel. Although > > I'm only proposing this for the MIPS bootinfo, it's completely > > applicable to any of them. > > > > What I propose is adding an optional platform extension structure: > > bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT > > Any reason not to put the vendor bits into another piece of loader > metadata ? That seems the extensible way to add additional info from the > loader, rather than extending bootinfo (as was the case pre-loader days). I agree. The metadata appended to the end of the kernel is a better way to manage this. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Soliciting opinions on an extension of the bootinfo structure
On Thursday, September 08, 2011 6:48:19 pm Peter Wemm wrote: > On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan wrote: > >> I'm proposing an extension framework for the bootinfo structure used > >> to pass information from the bootstrap/loader to the kernel. Although > >> I'm only proposing this for the MIPS bootinfo, it's completely > >> applicable to any of them. > >> > >> What I propose is adding an optional platform extension structure: > >> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT > > > > Any reason not to put the vendor bits into another piece of loader metadata > > ? That seems the extensible way to add additional info from the loader, > > rather than extending bootinfo (as was the case pre-loader days). > > > > later, > > It sounds like they're not using loader, which is probably a > reasonable thing for their environment. That doesn't stop you from adding metadata to the kernel. It is just an array of variable length blobs appended after 'end'. Any boot loader can support adding metadata. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: excessive use of gettimeofday(2) and other syscalls
what version of chromium are you using? I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is far less than 2 per second, about 20 per second, but I notice old version has this bug, but latest version has fixed it. Maybe you should update your chromium and try again. Firefox 5 and 6 has more gettimeofday call than 2 per second on my amd64-8.2-stable box. 2011/9/7 Alexander Best > On Wed Sep 7 11, Peter Jeremy wrote: > > On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani < > mani...@lineratesystems.com> wrote: > > >Under 7.3 (haven't checked 8 or 9) this issue crops up because the > > >time system call calls gettimeofday under the hood (see > > >lib/libc/gen/time.c). As a result, the kernel tries to get an > > >accurate subsecond resolution time that simply gets chopped to the > > >nearest second. > > > > Under 8.x and later, time(3) uses clock_gettime(CLOCK_SECOND,...) > > rather than gettimeofday(). This is intended to be much cheaper > > than gettimeofday(). > > > > On 2011-Sep-06 21:15:55 -0400, Rayson Ho wrote: > > >IMO, the time returned by gettimeofday does not need to be high > > >precision. There are higher resolution time APIs on Linux and I > > >believe the application programmers know when to use the slower but > > >more accurate clock API. > > > > There are 3 standard APIs for returning time of day: > > time(3) provides second precision > > gettimeofday(2) provides microsecond precision > > clock_gettime(2) provides nanosecond precision > > > > By default, FreeBSD attempts to provide resolution as close as > > possible to the precision - which makes the 2 system calls fairly > > expensive. In order to reduce the cost where the resolution isn't > > important, FreeBSD provides several non-standard clock types for > > clock_gettime(2). This approach differs from Linux - and it seems > > that there is a non-trivial body of code that assumes that calling > > gettimeofday() is very cheap. > > > > There is probably a good case for an API that provides a resolution > > of the order of a tick but there is no standard for this. > > chromium is triggering ~20.000 gettimeofday(2) calls per second on my > machine. > i'm running CURRENT on amd64. > > cheers. > alex > > > > > -- > > Peter Jeremy > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: excessive use of gettimeofday(2) and other syscalls
On Fri Sep 9 11, Paul Ambrose wrote: > what version of chromium are you using? > I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is > far less than 2 per second, about 20 per second, but I notice old > version has this bug, but latest version has fixed it. Maybe you should > update your chromium and try again. i'm running chromium-13.0.782.220 and sudo ktrace -di -tc -p1758; sleep 1; sudo ktrace -C; sudo kdump|grep gettimeofday|wc -l gives me 3056. so the number has decresed, yet i don't see why chromium needs to call gettimeofday(2) or any library function that triggers it more than 3000 times a second. also sudo ktrace -di -tc -p1758; sleep 1; sudo ktrace -C; sudo kdump|wc -l is returning 16695. that also seems like a pretty high syscall count in general for only 1 second. cheers. alex > > Firefox 5 and 6 has more gettimeofday call than 2 per second on my > amd64-8.2-stable box. > > 2011/9/7 Alexander Best > > > On Wed Sep 7 11, Peter Jeremy wrote: > > > On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani < > > mani...@lineratesystems.com> wrote: > > > >Under 7.3 (haven't checked 8 or 9) this issue crops up because the > > > >time system call calls gettimeofday under the hood (see > > > >lib/libc/gen/time.c). As a result, the kernel tries to get an > > > >accurate subsecond resolution time that simply gets chopped to the > > > >nearest second. > > > > > > Under 8.x and later, time(3) uses clock_gettime(CLOCK_SECOND,...) > > > rather than gettimeofday(). This is intended to be much cheaper > > > than gettimeofday(). > > > > > > On 2011-Sep-06 21:15:55 -0400, Rayson Ho wrote: > > > >IMO, the time returned by gettimeofday does not need to be high > > > >precision. There are higher resolution time APIs on Linux and I > > > >believe the application programmers know when to use the slower but > > > >more accurate clock API. > > > > > > There are 3 standard APIs for returning time of day: > > > time(3) provides second precision > > > gettimeofday(2) provides microsecond precision > > > clock_gettime(2) provides nanosecond precision > > > > > > By default, FreeBSD attempts to provide resolution as close as > > > possible to the precision - which makes the 2 system calls fairly > > > expensive. In order to reduce the cost where the resolution isn't > > > important, FreeBSD provides several non-standard clock types for > > > clock_gettime(2). This approach differs from Linux - and it seems > > > that there is a non-trivial body of code that assumes that calling > > > gettimeofday() is very cheap. > > > > > > There is probably a good case for an API that provides a resolution > > > of the order of a tick but there is no standard for this. > > > > chromium is triggering ~20.000 gettimeofday(2) calls per second on my > > machine. > > i'm running CURRENT on amd64. > > > > cheers. > > alex > > > > > > > > -- > > > Peter Jeremy > > > > > > ___ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting PathScale's EKOPath Compiler Suite
On Fri, Sep 9, 2011 at 2:11 AM, Jung-uk Kim wrote: > I have done preliminary porting work of PathScale's open-sourced > EKOPath Compiler Suite (https://github.com/pathscale). > > http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 > > This includes experimental OpenMP support and PathDB. Unfortuntely, > PathDB builds fine but just crashes ATM. Both options are turned off > by default for now. Although it seems working fine for many > non-trivial C/C++/Fortran sources, please do not use it for any > serious project because I have seen few internal compiler errors and > crashes. Be aware of ugly hacks! ;-) > > I just wanted to share it now because it was on the WantedPorts list > on Wiki for a while. If anyone with more clues want to pick it up > from here, please feel free. > > Cheers, > > Jung-uk Kim > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > I've tried to build your port on 8-STABLE and got this: [ 30%] Generating pscrt-static-x86_64/memcpy_em64t_c.o Error: Invalid target group option -TARG:processor=nocona !!! DevWarn during Reading WHIRL file: TODO: implement *skip* option !!! DevWarn during Reading WHIRL file: IPA_NODE::Skip is not yet implemented After removing CPUTYPE=nocona from /etc/make.conf i got: [ 45%] Generating openmp-static-x86_64/thread_c.o /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c: In function 'gettid': /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c:74: warning: implicit declaration of function 'thr_self' /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c: In function '__pmp_thread_create': /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c:515: error: 'MAP_ANONYMOUS' undeclared ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: excessive use of gettimeofday(2) and other syscalls
>> Firefox 5 and 6 has more gettimeofday call than 2 per second on my >> amd64-8.2-stable box. > i don't see why chromium needs > to call gettimeofday(2) or any library function that triggers it more > than 3000 times a second. What the are web browsers doing that they "need" the clock so often? I suspect the answer is the same as why firefox uses significant amounts of CPU when it should be idle, why it uses memory without bound (I actually had to add ulimit to my shell's rc file :-( ), and so on. Using "links -g", "ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l" gives a typical count of 300-400, highest count seen: 1454. What we need, is a sanely written web browser that has the features we need. Unfortunately the last time I checked, links and dillo both lacked features needed for online shopping/banking. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting PathScale's EKOPath Compiler Suite
On 09/ 9/11 10:53 PM, arrowdodger wrote: On Fri, Sep 9, 2011 at 2:11 AM, Jung-uk Kim wrote: I have done preliminary porting work of PathScale's open-sourced EKOPath Compiler Suite (https://github.com/pathscale). http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 This includes experimental OpenMP support and PathDB. Unfortuntely, PathDB builds fine but just crashes ATM. Both options are turned off by default for now. Although it seems working fine for many non-trivial C/C++/Fortran sources, please do not use it for any serious project because I have seen few internal compiler errors and crashes. Be aware of ugly hacks! ;-) I just wanted to share it now because it was on the WantedPorts list on Wiki for a while. If anyone with more clues want to pick it up from here, please feel free. Cheers, Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" I've tried to build your port on 8-STABLE and got this: [ 30%] Generating pscrt-static-x86_64/memcpy_em64t_c.o Error: Invalid target group option -TARG:processor=nocona !!! DevWarn during Reading WHIRL file: TODO: implement *skip* option !!! DevWarn during Reading WHIRL file: IPA_NODE::Skip is not yet implemented After removing CPUTYPE=nocona from /etc/make.conf i got: [ 45%] Generating openmp-static-x86_64/thread_c.o /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c: In function 'gettid': /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c:74: warning: implicit declaration of function 'thr_self' /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c: In function '__pmp_thread_create': /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compiler/src/libopenmp/thread.c:515: error: 'MAP_ANONYMOUS' undeclared Why do I feel like I'm not being heard at all? Do you people want to work with upstream and get your issues resolved or not? If so report bugs to *upstream* and please send any patches for review. http://bugs.pathscale.com # New JIRA and not 100% tested for community https://github.com/path64/compiler/issues # Github issues sucks, but there's people watching this space We also have mailing lists, irc and you can even bug me if you need help/have questions ./C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting PathScale's EKOPath Compiler Suite
On Friday 09 September 2011 11:53 am, arrowdodger wrote: > On Fri, Sep 9, 2011 at 2:11 AM, Jung-uk Kim wrote: > > I have done preliminary porting work of PathScale's open-sourced > > EKOPath Compiler Suite (https://github.com/pathscale). > > > > http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 > > > > This includes experimental OpenMP support and PathDB. > > Unfortuntely, PathDB builds fine but just crashes ATM. Both > > options are turned off by default for now. Although it seems > > working fine for many non-trivial C/C++/Fortran sources, please > > do not use it for any serious project because I have seen few > > internal compiler errors and crashes. Be aware of ugly hacks! > > ;-) > > > > I just wanted to share it now because it was on the WantedPorts > > list on Wiki for a while. If anyone with more clues want to pick > > it up from here, please feel free. > > > > Cheers, > > > > Jung-uk Kim > > ___ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscr...@freebsd.org" > > I've tried to build your port on 8-STABLE and got this: > > [ 30%] Generating > pscrt-static-x86_64/memcpy_em64t_c.o > > Error: Invalid target group option > -TARG:processor=nocona > > !!! DevWarn during Reading WHIRL file: TODO: implement *skip* > option !!! DevWarn during Reading WHIRL file: IPA_NODE::Skip is not > yet implemented > > After removing CPUTYPE=nocona from /etc/make.conf i got: > > [ 45%] Generating openmp-static-x86_64/thread_c.o > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compil >er/src/libopenmp/thread.c: In function 'gettid': > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compil >er/src/libopenmp/thread.c:74: warning: implicit declaration of > function 'thr_self' > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compil >er/src/libopenmp/thread.c: In function '__pmp_thread_create': > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/compil >er/src/libopenmp/thread.c:515: error: 'MAP_ANONYMOUS' undeclared Please try this: http://people.freebsd.org/~jkim/ekopath-devel_2.tar.bz2 Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting PathScale's EKOPath Compiler Suite
On Friday 09 September 2011 12:49 pm, "C. Bergström" wrote: > On 09/ 9/11 10:53 PM, arrowdodger wrote: > > On Fri, Sep 9, 2011 at 2:11 AM, Jung-uk Kim wrote: > >> I have done preliminary porting work of PathScale's open-sourced > >> EKOPath Compiler Suite (https://github.com/pathscale). > >> > >> http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 > >> > >> This includes experimental OpenMP support and PathDB. > >> Unfortuntely, PathDB builds fine but just crashes ATM. Both > >> options are turned off by default for now. Although it seems > >> working fine for many non-trivial C/C++/Fortran sources, please > >> do not use it for any serious project because I have seen few > >> internal compiler errors and crashes. Be aware of ugly hacks! > >> ;-) > >> > >> I just wanted to share it now because it was on the WantedPorts > >> list on Wiki for a while. If anyone with more clues want to > >> pick it up from here, please feel free. > >> > >> Cheers, > >> > >> Jung-uk Kim > >> ___ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to > >> "freebsd-hackers-unsubscr...@freebsd.org" > > > > I've tried to build your port on 8-STABLE and got this: > > > > [ 30%] Generating > > pscrt-static-x86_64/memcpy_em64t_c.o > > > > Error: Invalid target group option > > -TARG:processor=nocona > > > > !!! DevWarn during Reading WHIRL file: TODO: implement *skip* > > option !!! DevWarn during Reading WHIRL file: IPA_NODE::Skip is > > not yet implemented > > > > After removing CPUTYPE=nocona from /etc/make.conf i got: > > > > [ 45%] Generating openmp-static-x86_64/thread_c.o > > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/comp > >iler/src/libopenmp/thread.c: In function 'gettid': > > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/comp > >iler/src/libopenmp/thread.c:74: warning: implicit declaration of > > function 'thr_self' > > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/comp > >iler/src/libopenmp/thread.c: In function '__pmp_thread_create': > > /usr/home/arr/ports/ekopath-devel/work/path64-suite/compiler/comp > >iler/src/libopenmp/thread.c:515: error: 'MAP_ANONYMOUS' undeclared > > Why do I feel like I'm not being heard at all? Don't worry, I hear you. > Do you people want to work with upstream and get your issues > resolved or not? If so report bugs to *upstream* and please send > any patches for review. > > http://bugs.pathscale.com # New JIRA and not 100% tested for > community https://github.com/path64/compiler/issues # Github issues > sucks, but there's people watching this space > > We also have mailing lists, irc and you can even bug me if you need > help/have questions Please relax, it's *preliminary* work in progress. When I feel I have enough patches to submit, I will. Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: excessive use of gettimeofday(2) and other syscalls
On Fri Sep 9 11, Dieter BSD wrote: > >> Firefox 5 and 6 has more gettimeofday call than 2 per second on my > >> amd64-8.2-stable box. > > > i don't see why chromium needs > > to call gettimeofday(2) or any library function that triggers it more > > than 3000 times a second. > > What the are web browsers doing that they "need" the clock > so often? > > I suspect the answer is the same as why firefox uses significant amounts > of CPU when it should be idle, why it uses memory without bound > (I actually had to add ulimit to my shell's rc file :-( ), and > so on. > > Using "links -g", > "ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l" > gives a typical count of 300-400, highest count seen: 1454. well that measurement is probably unfair. my measurements included all opened tabs (~ 15), running plugins and extensions. if i disable all of those extra stuff and use only a single tab, chromium produces less syscalls than links: 270 cheers. alex > > What we need, is a sanely written web browser that has the > features we need. Unfortunately the last time I checked, > links and dillo both lacked features needed for online > shopping/banking. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: excessive use of gettimeofday(2) and other syscalls
On Fri Sep 9 11, Alexander Best wrote: > On Fri Sep 9 11, Dieter BSD wrote: > > >> Firefox 5 and 6 has more gettimeofday call than 2 per second on my > > >> amd64-8.2-stable box. > > > > > i don't see why chromium needs > > > to call gettimeofday(2) or any library function that triggers it more > > > than 3000 times a second. > > > > What the are web browsers doing that they "need" the clock > > so often? > > > > I suspect the answer is the same as why firefox uses significant amounts > > of CPU when it should be idle, why it uses memory without bound > > (I actually had to add ulimit to my shell's rc file :-( ), and > > so on. > > > > Using "links -g", > > "ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l" > > gives a typical count of 300-400, highest count seen: 1454. > > well that measurement is probably unfair. my measurements included all opened > tabs (~ 15), running plugins and extensions. if i disable all of those extra > stuff and use only a single tab, chromium produces less syscalls than links: > > 270 ...however sites such as facebook produce a much higher syscall peek under chromium. with only one tab opened with youtube.com in it, chromium has a typical syscall count of 700-2000. i guess this is due to stuff like js, html5 and friends. if i enable the flash plugins with only 1 single tab (youtube.com), the syscall count climbs to ~ 8000 with a peak at 19000 when youtube.com wasn't completely loaded. so the high syscall count is not only chromiums fault, but a combination of chromium, flash and the linuxulator. i believe further linuxulator improvements might reduce syscalls in this scenario. also with chromium 15, the syscall count is supposed to drop quite noticably (as mentioned in a previous message). cheers. alex > > cheers. > alex > > > > > What we need, is a sanely written web browser that has the > > features we need. Unfortunately the last time I checked, > > links and dillo both lacked features needed for online > > shopping/banking. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting PathScale's EKOPath Compiler Suite
On Thursday 08 September 2011 06:11 pm, Jung-uk Kim wrote: > I have done preliminary porting work of PathScale's open-sourced > EKOPath Compiler Suite (https://github.com/pathscale). > > http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 I just uploaded a new tarball, ekopath-devel-20110909.bz2. The above URL is now symlinked to it. This includes PATHAS option (which enables yasm-based assembler) and other minor improvements. > Unfortuntely, PathDB builds fine but just crashes ATM. When PathDB is compiled with GCC, it doesn't crash, BTW. I haven't done any investigation yet. Cheers, Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting PathScale's EKOPath Compiler Suite
On Friday 09 September 2011 06:38 pm, Jung-uk Kim wrote: > On Thursday 08 September 2011 06:11 pm, Jung-uk Kim wrote: > > I have done preliminary porting work of PathScale's open-sourced > > EKOPath Compiler Suite (https://github.com/pathscale). > > > > http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 > > I just uploaded a new tarball, ekopath-devel-20110909.bz2. The real path is http://people.freebsd.org/~jkim/ekopath-devel-20110909.tar.bz2 Sorry for the typo. Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
