Re: fast bcopy...
On Fri, May 04, 2012 at 09:44:15AM +1000, Andrew Reilly wrote: > On Wed, May 02, 2012 at 08:25:57PM +0200, Luigi Rizzo wrote: > > as part of my netmap investigations, i was looking at how > > expensive are memory copies, and here are a couple of findings > > (first one is obvious, the second one less so) > > Most C compilers (well, the ones I regularly use) inline small, > constant-length memcpy operations of the sort you're describing > here. I would expect techniques like that to beat any amount of > hand-tuning in a elf-linkage bcopy subroutine. > > Sure, you want a good implementation for your variable-length > copies, and data layout and alignment is tremendously important > these days, so there's no single silver bullet here. The two things i was addressing on my message cannot be solved by a compiler: the memcpy/bcopy has variable length in the places i was looking at, and the compiler cannot infer that it is allowed to extend the copy to full words or cache lines instead of stopping at the exact boundary. I don't even dare anymore to hand-optimize code: too many times i have been beaten by the compiler. cheers luigi ___ 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: X220 and all.14.5.patch
it's russian, not greek :) and this is my posts. Try to remove /usr/src and checkout clean source before applying patch, it helped me. And check FAQ, paragraphs 7 and 8 - http://wiki.freebsd.org/Intel_GPU sorry for my bad english 2012/5/4 Erich Dollansky : > Hi, > > I just applied this patch and tried to compile getting this error: > > /usr/src/sys/dev/drm/i915_mem.c:216: warning: no previous prototype for > 'i915_mem_release' [-Wmissing-prototypes] > /usr/src/sys/dev/drm/i915_mem.c:246: warning: no previous prototype for > 'i915_mem_takedown' [-Wmissing-prototypes] > /usr/src/sys/dev/drm/i915_mem.c: In function 'get_heap': > /usr/src/sys/dev/drm/i915_mem.c:266: error: 'drm_i915_private_t' has no > member named 'agp_heap' > /usr/src/sys/dev/drm/i915_mem.c: At top level: > /usr/src/sys/dev/drm/i915_mem.c:276: warning: no previous prototype for > 'i915_mem_alloc' [-Wmissing-prototypes] > /usr/src/sys/dev/drm/i915_mem.c:314: warning: no previous prototype for > 'i915_mem_free' [-Wmissing-prototypes] > /usr/src/sys/dev/drm/i915_mem.c:342: warning: no previous prototype for > 'i915_mem_init_heap' [-Wmissing-prototypes] > /usr/src/sys/dev/drm/i915_mem.c:366: warning: no previous prototype for > 'i915_mem_destroy_heap' [-Wmissing-prototypes] > *** [i915_mem.o] Error code 1 > > I found this: > > http://pastebin.com/ySPxJNUF > > and > > http://www.linux.org.ru/news/bsd/7658822/page6 > > which is a bit like Greek for me. > > It would be easy to fix the prototype errors. Does anybody know what agp_heap > is all about? > > The machine: > > FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Wed May 2 > 06:59:48 WIT 2012 er...@x220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 > > Erich -- wBR, Tuchinsky Artem ___ 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: make installworld fails
On May 3, 2012, at 1:34 PM, AN wrote: > Thu May 3 16:25:27 EDT 2012 > > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #13 r234872: Tue May 1 > 13:09:55 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > # svn up > Updated to revision 234981 > > I did build world/kernel, after booting into single user mode and trying make > installworld I get the following error: > > /usr/src/Makefile Line:219 check date and time > > I have seen this failure before, previously I was able to open the make file > and comment out the date and time check, but this time the file seems > corrupted, I am not able to open the file in vi. > > What causes this check to fail? Is there any way to detect this possibility > before rebboting to single user? Try looking very critically at the system date and time: $ date This check is comparing the system time to the timestamps of the files on disks to try to detect whether your system clock is correct. Since the 'make' program relies on comparing timestamps, you can get very strange results if your system clock is not consistent. You can use the date utility to set the system clock to the approximately correct time (it doesn't need to be very exact). If you have networking, you can use "ntpdate pool.ntp.org" to set the clock from the network. Tim ___ 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"
X220 and all.14.5.patch
Hi, I just applied this patch and tried to compile getting this error: /usr/src/sys/dev/drm/i915_mem.c:216: warning: no previous prototype for 'i915_mem_release' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:246: warning: no previous prototype for 'i915_mem_takedown' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c: In function 'get_heap': /usr/src/sys/dev/drm/i915_mem.c:266: error: 'drm_i915_private_t' has no member named 'agp_heap' /usr/src/sys/dev/drm/i915_mem.c: At top level: /usr/src/sys/dev/drm/i915_mem.c:276: warning: no previous prototype for 'i915_mem_alloc' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:314: warning: no previous prototype for 'i915_mem_free' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:342: warning: no previous prototype for 'i915_mem_init_heap' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:366: warning: no previous prototype for 'i915_mem_destroy_heap' [-Wmissing-prototypes] *** [i915_mem.o] Error code 1 I found this: http://pastebin.com/ySPxJNUF and http://www.linux.org.ru/news/bsd/7658822/page6 which is a bit like Greek for me. It would be easy to fix the prototype errors. Does anybody know what agp_heap is all about? The machine: FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Wed May 2 06:59:48 WIT 2012 er...@x220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 Erich ___ 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: fast bcopy...
On Wed, May 02, 2012 at 08:25:57PM +0200, Luigi Rizzo wrote: > as part of my netmap investigations, i was looking at how > expensive are memory copies, and here are a couple of findings > (first one is obvious, the second one less so) Most C compilers (well, the ones I regularly use) inline small, constant-length memcpy operations of the sort you're describing here. I would expect techniques like that to beat any amount of hand-tuning in a elf-linkage bcopy subroutine. Sure, you want a good implementation for your variable-length copies, and data layout and alignment is tremendously important these days, so there's no single silver bullet here. Cheers, -- Andrew ___ 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"
make installworld fails
Thu May 3 16:25:27 EDT 2012 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #13 r234872: Tue May 1 13:09:55 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # svn up Updated to revision 234981 I did build world/kernel, after booting into single user mode and trying make installworld I get the following error: /usr/src/Makefile Line:219 check date and time I have seen this failure before, previously I was able to open the make file and comment out the date and time check, but this time the file seems corrupted, I am not able to open the file in vi. What causes this check to fail? Is there any way to detect this possibility before rebboting to single user? # cat /etc/make.conf OVERRIDE_LINUX_BASE_PORT=f10 QT4_OPTIONS= QGTKSTYLE WITH_OPENSSL_PORT=yes # added by use.perl 2012-04-04 01:11:13 PERL_VERSION=5.14.2 MALLOC_PRODUCTION=yes Using system compiler, _not_ Clang. ___ 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"
[patch]: RFC changing order for khelp modules
hello, would anyone object to the following patch? == --- sys/module_khelp.h (revision 582) +++ sys/module_khelp.h (working copy) @@ -83,7 +83,7 @@ .priv = &kmd_##hname\ }; \ DECLARE_MODULE(hname, h_##hname, SI_SUB_PROTO_IFATTACHDOMAIN, \ - SI_ORDER_ANY); \ + SI_ORDER_MIDDLE); \ MODULE_VERSION(hname, version) #defineKHELP_DECLARE_MOD_UMA(hname, hdata, hhooks, version, size, ctor, dtor) \ @@ -102,7 +102,7 @@ .priv = &kmd_##hname\ }; \ DECLARE_MODULE(hname, h_##hname, SI_SUB_PROTO_IFATTACHDOMAIN, \ - SI_ORDER_ANY); \ + SI_ORDER_MIDDLE); \ MODULE_VERSION(hname, version) == the issue i stumbled upon is that when i compile in all available tcp congestion control algorithms into the kernel (instead of using them as modules) a couple of those fail to initialize and register because they fail to find h_ertt khelp module (which is also complied in) thanks, max ___ 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: [RFC] Un-staticise the toolchain
On Thursday, May 03, 2012 5:18:15 am Erik Cederstrand wrote: > Den 02/05/2012 kl. 13.56 skrev John Baldwin: > >> > >> Static version: > >> * 0.09 ms spent execve'ing /usr/bin/make > >> * The rest is mostly sysctl calls > >> > >> Dynamic version: > >> * 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1 > >> * 0.18 ms spent loading libc.so.7 (incl. reading /etc/libmap.conf and /var/run/ld-elf.so.hints) > >> * 0.11 ms spent calling sysarch(0x81,0x7fff) (static version also does this but only uses 0.01 ms. No idea why) > >> * The rest is mostly sysctl and sigprocmask calls > > > > Keep in mind that the first time each system call is invoked, the runtime > > linker has to resolve the symbol. You can force the linker to do all > > that when the object is loaded instead by setting LD_BIND_NOW=yes in the > > environment of dynamicmake. If that makes the sysarch() call take 0.01 > > ms, then you know that the extra 0.10 ms is because of rtld doing the > > lookup of sysarch() on the first sysarch() call. > > Thanks for the suggestion. There is only a single sysarch() call in each version so I'm not sure that would help. Anyway, setting LD_BIND_NOW in the dynamic case just made the sysarch() call 0.20 ms slower without speeding up anything else. Hummm, that's odd that it was even slower. -- 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: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote:
> On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote:
> > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote:
> > > >
> > > > I also see:
> > > >
> > > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb
> > > > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
> > > > ata0: reset tp2 stat0=00 stat1=00 devices=0x1
> > >
> > > Hmmm, I don't know how to grok these lines, but does your disk work at
all now
> > > with any kernel? It may be that your disk has died (or a cable, etc.)
and it
> > > just happened to coincide with your upgrade?
> >
> > I reverted back to r231158, built world and generic
> > kernel (minus all modules, i.e. "option MODULES_OVERRIDE=").
> > This works, see the verbose boot dmesg at the end.
> >
> > I think I'll just do a binary search.
>
> I traced it to r233677.
> The only change from 233676 to 233677 is
> in /sys/dev/pci/pci.c
>
> My kernel is GENERIC with no modules
> and with various bits removed, e.g. all raid devices
> and PCI network devices, which I definitely
> haven't got on this laptop.
>
> Below is the verbose boot with r233676.
> Apparently at the beginning there's also
> the previous unsuccessful boot with r233677.
> Is this a new feature? I didn't know the
> previous dmesg is preserved after a reboot.
> Anyway, you can see clearly the error with r233677.
>
> I guess this is something to do with
> ata -> ada change?
I don't think so.
Please try just this change:
Index: pci.c
===
--- pci.c (revision 234928)
+++ pci.c (working copy)
@@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int reg, s
* from the parent.
*/
resource_list_delete(rl, type, reg);
- } else {
+ start = 0;
+ device_printf(bus,
+ "pci%d:%d:%d:%d bar %#x failed to allocate",
+ pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev),
+ pci_get_function(dev), reg);
+ } else
start = rman_get_start(res);
- pci_write_bar(dev, pm, start);
- }
+ pci_write_bar(dev, pm, start);
return (barlen);
}
--
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: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
Hi, First off, let me say "thankyou" to you, ray@ and all the people who have chipped away at this little problem. I look very forward to having rt2xxx 802.11n support, as do many users on the forums. :) I haven't yet done a pass or two to see what the state of the locking/concurrency handling is. Don't let that stop you from committing it though, I'm sure we can find/fix whatever issues creep up post-commit. Thanks again! Adrian ___ 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: fast bcopy...
> > guess this is a good time to thank the FreeBSD hackers for that FPU > > stack FILD/FISTP idea! > > I'll append the copy related notes of our doc/memperf.txt. > > Thanks, > > I made an implementation of fpu unwinding and mmx copy to see if they > were really making a difference years ago (reimplementing bcopy, > memcopy, etc.). Codecs, such as Ffdshow often contain their own functions to work with memory. ___ 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: Some performance measurements on the FreeBSD network stack
On Thu, Apr 19, 2012 at 03:30:18PM +0200, Luigi Rizzo wrote: > I have been running some performance tests on UDP sockets, > using the netsend program in tools/tools/netrate/netsend > and instrumenting the source code and the kernel do return in > various points of the path. Here are some results which > I hope you find interesting. ... I have summarized the info on this thread in the camera ready version of an upcoming Usenix paper, which you can find here: http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf cheers luigi ___ 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: fast bcopy...
Em 03-05-2012 12:28, Steven Atreju escreveu: Yes, of course. Though i was kinda, even shocked, once i've seen this first: http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2 I also experimented a bit with some trivial libc functions when testing a change for memcpy (still in queue, will send it out for review once I have some more detailed benchamrks) and I also noticed that sometimes the trivial C version performed just like the assembly code. It is definitely something that needs some cleanup and I'm interested in working on it but cannot afford too much time at the moment. Gabor ___ 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: ksh93 build failure
* Jason Hellenthal [120503 06:43]: > > > On Wed, May 02, 2012 at 06:52:21PM -0400, Derek Tattersall wrote: > > On a 10.0 Current system, cvsupped today, ksh93 fails to build. As best > > I can determine, the failure is due to a problem of conflicting > > includes. > > > > In file included from > > /home/ports/usr/ports/shells/ksh93/work/arch/freebsd.amd64/include/ast/ast_wchar.h:113, > > from > > /home/ports/usr/ports/shells/ksh93/work/arch/freebsd.amd64/include/ast/wchar.h:22, > > from > > /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/include/lexstates.h:85, > > from > > /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/include/shlex.h:32, > > from > > /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/data/keywords.c:22: > > /usr/include/../include/wchar.h:102: error: conflicting types for > > '_sfio_FILE' > > Has anyone else run into this problem, and if so, what did you do about > > it. ksh93 builds without error on 9.0 Stable. > > Do you perhaps have devel/sfio installed on that machine ? If so can you > deinstall and retry the build. > > -- > > - (2^(N-1)) Thanks for the pointer to sfio, but it's not installed on either the 10.0 Current system, nor the 9.0 Stable system. I'm still confused. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ 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: fast bcopy...
2012/5/3, Steven Atreju : > K. Macy wrote [2012-05-03 02:58+0200]: >> It's highly chipset and processor dependent what works best. > > Yes, of course. > Though i was kinda, even shocked, once i've seen this first: > > http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2 > > So we don't use our assembler version for new gccs and HAMMER or > SSE3+ (the decision for these was rather arbitrarily, except they > were yet existent for an instant implementation). > >> Intel now has non-temporal loads and stores which work much >> better in some cases but provide little benefit in others. > > Yes, our 2002 tests have shown that these were *extremely* > dependent upon alignment. (Note: 2002. o-) > Hmm, it doesn't really matter, but i guess this is a good time to > thank the FreeBSD hackers for that FPU stack FILD/FISTP idea! > I'll append the copy related notes of our doc/memperf.txt. > Thanks, I made an implementation of fpu unwinding and mmx copy to see if they were really making a difference years ago (reimplementing bcopy, memcopy, etc.). What really mattered with hw available at that time (pentium4) was the alignment and use of non-temporal operations on heavilly contended cache-lines. In few words it is more important we engineer the "buffer" layout rather than the functions themselves. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: fast bcopy...
K. Macy wrote [2012-05-03 02:58+0200]: > It's highly chipset and processor dependent what works best. Yes, of course. Though i was kinda, even shocked, once i've seen this first: http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2 So we don't use our assembler version for new gccs and HAMMER or SSE3+ (the decision for these was rather arbitrarily, except they were yet existent for an instant implementation). > Intel now has non-temporal loads and stores which work much > better in some cases but provide little benefit in others. Yes, our 2002 tests have shown that these were *extremely* dependent upon alignment. (Note: 2002. o-) Hmm, it doesn't really matter, but i guess this is a good time to thank the FreeBSD hackers for that FPU stack FILD/FISTP idea! I'll append the copy related notes of our doc/memperf.txt. Thanks, > -Kip Steven. I. x86 (AMD Athlon 1600+, 256MB DDR, 133/133 FSB) - COPY The basic idea is always the same: - Branch off to REPZ MOVSB if less than 16 bytes to go. - Align at least one pointer on a nice boundary (&3 or &7). (Done by a byte loop; one 4/8 store is more expensive here.) We always align the _from pointer due to test experience. - DEPENDENT. - Do the remaining maximally 3 bytes in an unrolled MOVSB way. DEPENDENT: - !SF_FPU && !defined(SF_X86_MMX): just a matter of REPZ MOVSL. - Otherwise we use three different loops over 64, 16 and 8 bytes, respectively. If more than 4 bytes remain after that we use one additional MOVSL. Note that the 8 byte loop is not a loop but executes once only. The big loop uses pairs of MOVNTQ/MOVQ, MOVQ/MOVQ and FILD/FISTP, if _SSE, _MMX or _FPU, respectively. The _SSE loop exists in addition and is never used if the non-aligned (the _to) pointer is not also aligned. The two smaller ones never use SSE's non-temporal moves; this way we simply can go no matter wether the to pointer is aligned or not. Tests demonstrated that non-temporal is no win for them anyway. At the end we add additional SFENCE (if _SSE) and EMMS (_MMX) or FEMMS (if _3DNOW) to serialize the non-temporal moves and clear the MMX state, respectively. The SFENCE should not be needed, however. Prefetching is not used (very bad on Athlon (or i don't understand it)). 1. !_MMX && !_FPU 2. _MMX 3. _FPU (thanks to the FreeBSD crew for this idea!) 4. _MMX+_3DNOW+_SSE implementation (all we have). ([*] times in brackets show which time has been measured if the from pointer alignment loop has a leading '.ALIGN 2' statement; note especially the value for 4096... note this value in general.) UNT: unaligned pointers, to pointer alignment goal UNF: unaligned pointers, from pointer alignment goal 1000 loops; times in (averaged) microseconds P.S.: 03-04-01: SSE stuff disabled because speed for smaller ranges considered to be more important than for large and even more largest ranges. (And small difference for non-perfect ranges and non-aligned pointers.) --- |bytes| 1./ UNT/ UNF | 2./ UNT/ UNF | 3./ UNT/ UNF | 4.[*] / UNF | |-- |16 | 34// | 19// 37 | 21// 37 | 24[ 26]/ 37 | |15 | 40// | 39// 35 | 37// 35 | 38[ 39]/ 35 | |32 | 36// | 23// 30 | 23// 30 | 27[ 30]/ 33 | |31 | 43// | 37// 28 | 36// 28 | 38[ 42]/ 31 | |64 | 45// | 17// 38 | 17// 36 | 21[ 23]/ 39 | |63 | 50// | 46// 35 | 44// 34 | 47[ 50]/ 37 | |128 | 59/ 70/ 74 | 31// 45 | 34// 47 | 34[ 36]/ 50 | |127 | 67/ 82/ 62 | 53// 45 | 51// 44 | 62[ 63]/ 50 | |256 | 89/ 111/ 108 | 52// 74 | 53// 77 | 50[ 50]/ 76 | |255 | 99/ 123/ 96 | 67// 73 | 73// 75 | 68[ 70]/ 74 | |512 | 151/ 197/ 177 | 95// 131 | 98// 137 | 84[103]/ 137 | |511 | 158/ 208/ 166 | 100// 132 | 117// 134 | 99[112]/ 135 | |1024 | 274/ 395/ 314 | 179// 255 | 211// 270 | 166[207]/ 257 | |1023 | 280/ 408/ 303 | 196// 253 | 225// 267 | 184[185]/ 253 | |2048 | 579/ 765/ 966 | 350// 485 | 394// 511 | 389[388]/ 486 | |2047 | 585/ 777/ 942 | 368// 484 | 410// 520 | 323[398]/ 484 | |4096 | 1009/1385/1140 | 704//1036 | 761//1040 | 671[583]/1038 | |4095 | 1027/1386/1130 | 721//1034 | 776//1037 | 602[604]/1035 | |-- P.S.: ooops - i've really forgotten that the SSE stuff has been completely disabled at a later time! I guess we'll have to redo some testing eventually! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd
Re: FreeBSD 10 prognostication...
Am 03.05.2012 06:31, schrieb Vance Siemens: > Can't say that I wouldn't look forward to this, but it sounds a little off: > > http://www.trollaxor.com/2012/05/freebsd-x-berkeley-unix-apple-quality.html > > What do others think? Looks like the author was just one month late with his April's fool joke. And there are real funny parts, e.g. how Wind River is spelled WinDriver (and described as a company that writing drivers for Windows, as its name says ;-) ...). I have entered an anonymous comment and I'm curious, whether they will allow it to appear below the article (it is awaiting moderator approval). Regards, STefan ___ 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: [RFC] Un-staticise the toolchain
Den 02/05/2012 kl. 13.56 skrev John Baldwin: >> >> Static version: >> * 0.09 ms spent execve'ing /usr/bin/make >> * The rest is mostly sysctl calls >> >> Dynamic version: >> * 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1 >> * 0.18 ms spent loading libc.so.7 (incl. reading /etc/libmap.conf and >> /var/run/ld-elf.so.hints) >> * 0.11 ms spent calling sysarch(0x81,0x7fff) (static version also >> does this but only uses 0.01 ms. No idea why) >> * The rest is mostly sysctl and sigprocmask calls > > Keep in mind that the first time each system call is invoked, the runtime > linker has to resolve the symbol. You can force the linker to do all > that when the object is loaded instead by setting LD_BIND_NOW=yes in the > environment of dynamicmake. If that makes the sysarch() call take 0.01 > ms, then you know that the extra 0.10 ms is because of rtld doing the > lookup of sysarch() on the first sysarch() call. Thanks for the suggestion. There is only a single sysarch() call in each version so I'm not sure that would help. Anyway, setting LD_BIND_NOW in the dynamic case just made the sysarch() call 0.20 ms slower without speeding up anything else. Kind regards, Erik___ 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: FreeBSD 10 prognostication...
On Thu, May 3, 2012 at 6:31 AM, Vance Siemens wrote: > Can't say that I wouldn't look forward to this, but it sounds a little off: > > http://www.trollaxor.com/2012/05/freebsd-x-berkeley-unix-apple-quality.html > > What do others think? ROTFL. Thank you for the laughs. That was slashdot's "Netcraft confirms: BSD is dying" meme on steroids. I didn't imagine that someone would come along and pile on it a whole blog entry so full of inaccuracies. -cpghost. > --Vance -- Cordula's Web. http://www.cordula.ws/ ___ 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: FreeBSD 10 prognostication...
On 03.05.2012 05:31, Vance Siemens wrote: Can't say that I wouldn't look forward to this, but it sounds a little off: http://www.trollaxor.com/2012/05/freebsd-x-berkeley-unix-apple-quality.html What do others think? --Vance ___ 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" I hope this is some kind of sick joke... I can't imagine anything worse. Jake. ___ 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"
