Re: [RFC] Un-staticise the toolchain

2012-05-01 Thread Erik Cederstrand
Den 01/05/2012 kl. 15.55 skrev Gary Palmer: > > If you want a high-level view of what goes on run > > ldd `which ls` > > check that it has libraries to load and doesn't say "not a dynamic ELF > executable", and then run: > > ktrace ls > kdump | more > > All the system calls related to resolvi

Re: more network performance info: ether_output()

2012-05-01 Thread Luigi Rizzo
it somewhere > and send a link? nope, my fault, i forgot to put the attachment. I have now put it at http://info.iet.unipi.it/~luigi/netmap/20120501-netmap_drop.diff cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org

Re: more network performance info: ether_output()

2012-05-01 Thread Bjoern A. Zeeb
On 1. May 2012, at 15:40 , Luigi Rizzo wrote: > On Tue, May 01, 2012 at 10:27:42AM -0400, George Neville-Neil wrote: >> >> On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: >> >>> Continuing my profiling on network performance, another place >>> were we waste a lot of time is if_ethersubr.c::ether

Re: RFC: jemalloc: qdbus sigsegv in malloc_init

2012-05-01 Thread Gustau Pérez i Querol
Al 30/04/2012 21:34, En/na Jason Evans ha escrit: On Apr 30, 2012, at 7:13 AM, Gustau Pérez i Querol wrote: the kde team is seeing some strange problems with the new version (4.8.1) of devel/dbus-qt4 with current. It does work with stable. I also suspect that the problem described below is a

LLVM compiler backend for AMD Radeon HD r600 - the potential solution for OpenCL in FreeBSD?

2012-05-01 Thread O. Hartmann
I read this week this article on Phoronix: http://www.phoronix.com/scan.php?page=article&item=amd_r600g_llvm&num=1 Well, it looks promising to me in terms of having also OpenCL capabilities for GPGPU, but as the report says, the code is not finished and still in a very preliminary stage. What is

Re: more network performance info: ether_output()

2012-05-01 Thread George Neville-Neil
On May 1, 2012, at 11:40 , Luigi Rizzo wrote: > On Tue, May 01, 2012 at 10:27:42AM -0400, George Neville-Neil wrote: >> >> On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: >> >>> Continuing my profiling on network performance, another place >>> were we waste a lot of time is if_ethersubr.c::ether

Re: more network performance info: ether_output()

2012-05-01 Thread Luigi Rizzo
On Tue, May 01, 2012 at 10:27:42AM -0400, George Neville-Neil wrote: > > On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: > > > Continuing my profiling on network performance, another place > > were we waste a lot of time is if_ethersubr.c::ether_output() > > > > In particular, from the beginning

Re: more network performance info: ether_output()

2012-05-01 Thread George Neville-Neil
On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: > Continuing my profiling on network performance, another place > were we waste a lot of time is if_ethersubr.c::ether_output() > > In particular, from the beginning of ether_output() to the > final call to ether_output_frame() the code takes slight

Re: [RFC] Un-staticise the toolchain

2012-05-01 Thread Gary Palmer
On Tue, May 01, 2012 at 01:53:58PM +0200, Erik Cederstrand wrote: > Den 01/05/2012 kl. 07.52 skrev Tim Kientzle: > > > > On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote: > >> > >> Can anyone explain to me why the dynamically linked version is > >> significantly slower? What are the extra ste

Re: [RFC] Un-staticise the toolchain

2012-05-01 Thread Erik Cederstrand
Den 01/05/2012 kl. 07.52 skrev Tim Kientzle: > > On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote: >> >> Can anyone explain to me why the dynamically linked version is significantly >> slower? What are the extra steps involved compared to a statically linked >> binary? > > At the risk of dr

Re: lang/gcc46: error when compiling with CLANG

2012-05-01 Thread O. Hartmann
Am 04/30/12 13:44, schrieb Jean-Sébastien Pédron: > On 30.04.2012 08:11, O. Hartmann wrote: >> Repeating the build ends up at the same "stage" as it stopped when >> building on regular basis - for my understanding. > > You say you have two boxes running 10-CURRENT: do they run the same > SVN revis