Re: Implementations of sqrtl and logl
On Thursday 29 December 2005 05:46 pm, Steve Kargl wrote: I have implementations for sqrtl and logl, which can be added to libm. In limited testing on AMD64 , I find You probably will want to coordinate with Bruce Evans (bde@) as he has been doing a lot of work on libm specifically with amd64 recently. -- John Baldwin [EMAIL PROTECTED] http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Building a release
If memory serves me right, Daniel Rudy wrote: I'm having some difficulties in building a release ISO from sources. When I do a make release in /usr/src/release, everything seems to go well until is tries to access perl5.8 in the ports. I go into ports and find that there is nothing there. Here's what I have been doing: Build directory trees: mkdir /usr/cvsroot mkdir /usr/release mkdir /usr/tmp/cvs Get CVS tree: cd /usr/tmp/cvs cvs -d [EMAIL PROTECTED]:/home/ncvs co -rRELENG_6_0_0_RELEASE src cvs -d [EMAIL PROTECTED]:/home/ncvs co doc cvs -d [EMAIL PROTECTED]:/home/ncvs co ports Build local CVS repository: cd /usr/cvsroot CVSROOT=/usr/cvsroot ; export CVSROOT CVSEDITOR=vi ; export CVSEDITOR cvs init cd /usr/tmp/cvs/src cvs import src RELENG_6_0_0_RELEASE src cd /usr/tmp/cvs/doc cvs import doc RELENG_6_0_0_RELEASE doc cd /usr/tmp/cvs/ports cvs import ports RELENG_6_0_0_RELEASE ports Any particular reason that you're trying to recreate FreeBSD's CVS repository layout, rather than just grabbing a copy of the repository? I haven't thought much about this problem but it seems to me you're winding up with tags in your reconstructed repository that are not the same as the tags in the real repository, and this may be causing some problems. I could picture you wanting to do this if you were tragically low on disk space but until you get some success at actually building a release, you might be better off stucking to a more normal setup. Good luck! Bruce. signature.asc Description: OpenPGP digital signature
Re: Implementations of sqrtl and logl
On Fri, Dec 30, 2005 at 08:29:45AM -0500, John Baldwin wrote: On Thursday 29 December 2005 05:46 pm, Steve Kargl wrote: I have implementations for sqrtl and logl, which can be added to libm. In limited testing on AMD64 , I find You probably will want to coordinate with Bruce Evans (bde@) as he has been doing a lot of work on libm specifically with amd64 recently. I'm aware of bde's recent work, and he and I have exchanged several emails concerning ccosh(), logl(), and style(9). bde has been concentrating on fixing the float functions, which can be tested for all possible float values. I've taken up the crusade of implementing the missing C99 complex and long double functions. I was hoping to draw other prople into the discussion, and if possible attract others to contribute. There are numerous missing C99 complex and math functions. I also have implementations for acoshl and asinhl, which (statistically) give 1/2 ULP over their ranges with two minor exceptions. acoshl in [1,1.5] and asinhl in [-1,1] degrade to only 58 bits of precision. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Building a release
Better to just use cvsup /usr/share/examples/cvsup/cvs-supfile then all u need to do is create /home/cvs first. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Implementations of sqrtl and logl
On Thu, 2005-Dec-29 14:46:26 -0800, Steve Kargl wrote: I have implementations for sqrtl and logl, which can be added to libm. In limited testing on AMD64 , I find troutmask:kargl[208] ./test_sqrt float doublelong double MRE: 8.953800e-08 1.664855e-16 1.084202e-19 DDP: 7.05 15.78 18.96 BDP: 23.41 52.42 63.00 ... MRE = maximum relative error between a value from my routine and a value computed using GMP/MPFR with 64-bits of precision. Given that long double has 64 bits of precision, is testing it against a 64-bit test library adequate? And what is the accuracy of your test library? -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Implementations of sqrtl and logl
On Sat, Dec 31, 2005 at 05:26:12AM +1100, Peter Jeremy wrote: On Thu, 2005-Dec-29 14:46:26 -0800, Steve Kargl wrote: I have implementations for sqrtl and logl, which can be added to libm. In limited testing on AMD64 , I find troutmask:kargl[208] ./test_sqrt float doublelong double MRE: 8.953800e-08 1.664855e-16 1.084202e-19 DDP: 7.05 15.78 18.96 BDP: 23.41 52.42 63.00 ... MRE = maximum relative error between a value from my routine and a value computed using GMP/MPFR with 64-bits of precision. Given that long double has 64 bits of precision, is testing it against a 64-bit test library adequate? And what is the accuracy of your test library? MPFR uses GMP for its internals. I set MPFR to use 64-bit precision and round-to-nearest. It is claimed that mpfr will give correctly rounded FP values in the requested precision and rounding mode. I can set MPFR to any precision and one of four rounding modes; however, the runtime of the tests will go up. I've changed my test program to use 128 bit precision. Here are the results troutmask:kargl[211] ./test_sqrt 1 float doublelong double MRE: 8.953800e-08 1.664855e-16 1.084202e-19 DDP: 7.05 15.78 18.96 BDP: 23.41 52.42 63.00 MRE: 1.084202e-19 DDP: 18.96 BDP: 63.00 To gather the stats, I need to either convert my long double result into a mpfr_t value or convert the MPFR sqrt value into a long double. I've chosen the latter. Thus, the 128-bit MPFR value is correctly rounded to a 64-bit long double. I don't understand your second question. Are you referring to MPFR?. epsilon is 2**(1 - p) where p is the precision. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem about libnet on FreeBSD 6.0
Hi hackers, I find that I can't include net/ethernet.h when I programming with libnet,because $(CC) complains that struct ether_addr redefined. But I need some definitions in net/ethernet.h,struct ether_header etc. Currently,I just copy the definitions I need from net/ethernet.h,but it seems very ugly.Any one has some good ideas? Thanks. -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. -Bertrand Russell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Preserve date when cp over smbfs
Hi, the list. I have recently notice a problem when I copy a file to a SMB mount directory : My SMB client is a FreeBSD 6.0-STABLE. My SMB server is a FreeBSD 5.4-STABLE (with port samba-3.0.8,1). When I do a 'cp -p somefile /path/to/smbmountdir/anotherfolder', the access time and modification time are not preserved, even if I use the -p flag. The user doing the copy with cp is the owner of /path/to/smbmountdir. Few days later, I have finally found the problem in the src/bin/cp source code, especially the utils.c file : I have found out that utimes() does nothing on the newly created file, if its file descriptor is not closed yet, and this is only the case in a SMB destination path. Here is a small patch I have made. So pleeaaase, committers, I hope(pray) that the correction to the cp utility can be applied (with or without the patch), for the next time ;) I will be very grateful for that, as it is very important for me to preserve the modification time when I copy some photos to my file server over smbfs :) -- (hika) Gilbert Cao http://www.miaouirc.com - MiaouIRC Project 2002-2003 http://www.bsdmon.com - The BSD DMON Power to serve IRC : #miaule at IRCNET Network --- ./src/bin/cp/utils.c.orig Sat Nov 12 22:21:45 2005 +++ ./src/bin/cp/utils.cFri Dec 30 19:23:04 2005 @@ -204,8 +204,6 @@ * to remove it if we created it and its length is 0. */ - if (pflag setfile(fs, to_fd)) - rval = 1; if (pflag preserve_fd_acls(from_fd, to_fd) != 0) rval = 1; (void)close(from_fd); @@ -213,6 +211,14 @@ warn(%s, to.p_path); rval = 1; } + /* +* To preserve times in SMB to.p_path, +* setfile() should be call *AFTER* we have closed the file +* descriptors. As we have closed the descriptors, we should +* pass -1 instead of the `to_fd` value +*/ + if (pflag setfile(fs, -1)) + rval = 1; return (rval); } pgpmR6Ds1psYQ.pgp Description: PGP signature
Re: Preserve date when cp over smbfs
Gilbert Cao wrote: Hi, the list. I have recently notice a problem when I copy a file to a SMB mount directory : Thanks for the good detective work. Can you send-pr this so that it does not get lost? Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preserve date when cp over smbfs
Gilbert Cao wrote: Hi, the list. I have recently notice a problem when I copy a file to a SMB mount directory : Good detective work! Please send-pr this so it does not get lost. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Fri, 16 Dec 2005, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? This is an old thread that I'm just catching up on, but I figured I'd chime in anyway: you have to be really careful benchmarking across CPU types and configurations, as the performance characteristics of important insturctions differ a lot across hardware variations. For example, the performance of atomic operations, used to synchronize between CPUs, varies significantly by CP, bus configuration, etc. On modern opteron hardware, the performance of inter-CPU synchronization instructions is blindingly fast. On modern Xeon P4 hardware, it is incredibly slow. Software optimized for the Opteron will often perform much slower on Xeon P4 hardware as a result. P3 hardware tends to behave a lot more like Opteron in terms of speed of insturctions relating to disabling interrupts, where on P4 Xeon they are proprtionally much slower. The critical section optimizations made by John Baldwin, and the movement to critical sections in UMA and kernel malloc that I made, made a big performance difference on Xeon P4 hardware, but relatively little difference on Opteron. All this seems to suggest that when comparing UP and SMP, it's useful to do it on nice opteron hardware, but also on P4 Xeon to prevent making decisions based on platform-specific properties. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
