From owner-freebsd-toolchain@FreeBSD.ORG Sun Sep 16 05:19:20 2012 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF5B106566B; Sun, 16 Sep 2012 05:19:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 252838FC08; Sun, 16 Sep 2012 05:19:17 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q8G5JLgX045868; Sun, 16 Sep 2012 08:19:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q8G5J9Q6026220; Sun, 16 Sep 2012 08:19:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q8G5J9gZ026219; Sun, 16 Sep 2012 08:19:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Sep 2012 08:19:09 +0300 From: Konstantin Belousov To: Dimitry Andric Message-ID: <20120916051909.GI37286@deviant.kiev.zoral.com.ua> References: <50550285.4040203@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fze0sZZmuBV4A+b2" Content-Disposition: inline In-Reply-To: <50550285.4040203@andric.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Compiler performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 05:19:20 -0000 --fze0sZZmuBV4A+b2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: > Hi all, >=20 > By request, I performed a series of kernel performance tests on FreeBSD > 10.0-CURRENT, particularly comparing the runtime performance of GENERIC > kernels compiled by gcc 4.2.1 and by clang 3.2. >=20 > The attached text file[1] contains more information about the tests, > some semi-cooked performance data, and my conclusions. Any errors and > omissions are also my fault, so if you notice them, please let me know. >=20 > The executive summary: GENERIC kernels compiled with clang 3.2 are > slightly faster than those compiled by gcc 4.2.1, though the difference > will not very noticeable in practice. >=20 > Last but not least, thanks to Gavin Atkinson for providing the required > hardware. Thank you very much for doing this. I tried to map the CPUID into more human-friendly family moniker, and it seems that these are Pentium-4 class CPUs. Am I right ? If yes, could you, please, rerun the tests on anything more recent than Core2, i.e. any Core i7-whatever class of Xeons ? Thank again. --fze0sZZmuBV4A+b2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBVYU0ACgkQC3+MBN1Mb4jwPACgprGQgUxqIAh8z5ymqizGgesx VhYAmwdDn4Pzlz28GNHUq4s4o6kl5s/q =aK0L -----END PGP SIGNATURE----- --fze0sZZmuBV4A+b2-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Sep 16 05:25:52 2012 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B71261065670; Sun, 16 Sep 2012 05:25:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 65A208FC19; Sun, 16 Sep 2012 05:25:52 +0000 (UTC) Received: by obbun3 with SMTP id un3so9813461obb.13 for ; Sat, 15 Sep 2012 22:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Krm79UcjFbi46Th0F+uubmP9hadLLVQr1p7zAb51t+M=; b=0/C2Vx5xgpN+IcmWDPy6or3O3XI4GCJQQobLYOJxrE+PJeM8tHrQGTYasxyooG+dML AJsipms1SX620AfmsKLKaStywUfgRY3JseKiv/atsdE6IZPR8XT5E1WzKDp1aMTYHJsc 1scsDYP88rdSBvo6kkol6+j4Ib6zzRdwziBnZ4rUtmmLkoaxiy5Tq25C8upFEnMAyJiL cE0oO8biIdt8+VmCS7IYotWjX44tzMnfveCsvTbPjh2nHvidNpPDTBi8tNA9543cHa/s wl65rVyWZY2RIqb4c0u9jzI4EKU3Zx9I8hQpQWWxl2zsLNcdU8jB5JerbSooK2Za2F5B 4kVw== MIME-Version: 1.0 Received: by 10.60.20.69 with SMTP id l5mr8394651oee.114.1347773151643; Sat, 15 Sep 2012 22:25:51 -0700 (PDT) Received: by 10.76.142.201 with HTTP; Sat, 15 Sep 2012 22:25:51 -0700 (PDT) In-Reply-To: <20120916051909.GI37286@deviant.kiev.zoral.com.ua> References: <50550285.4040203@andric.com> <20120916051909.GI37286@deviant.kiev.zoral.com.ua> Date: Sat, 15 Sep 2012 22:25:51 -0700 Message-ID: From: Garrett Cooper To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Compiler performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 05:25:52 -0000 On Sat, Sep 15, 2012 at 10:19 PM, Konstantin Belousov wrote: > On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: >> Hi all, >> >> By request, I performed a series of kernel performance tests on FreeBSD >> 10.0-CURRENT, particularly comparing the runtime performance of GENERIC >> kernels compiled by gcc 4.2.1 and by clang 3.2. >> >> The attached text file[1] contains more information about the tests, >> some semi-cooked performance data, and my conclusions. Any errors and >> omissions are also my fault, so if you notice them, please let me know. >> >> The executive summary: GENERIC kernels compiled with clang 3.2 are >> slightly faster than those compiled by gcc 4.2.1, though the difference >> will not very noticeable in practice. >> >> Last but not least, thanks to Gavin Atkinson for providing the required >> hardware. > > Thank you very much for doing this. > > I tried to map the CPUID into more human-friendly family moniker, and it > seems that these are Pentium-4 class CPUs. Am I right ? > > If yes, could you, please, rerun the tests on anything more recent than > Core2, i.e. any Core i7-whatever class of Xeons ? If you can provide the tests, I can rerun it on some Nehalem class workstations I have access to. I unfortunately don't have access to SNB/Romley hardware yet. Thanks, -Garrett From owner-freebsd-toolchain@FreeBSD.ORG Sun Sep 16 11:03:04 2012 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF68F106566B; Sun, 16 Sep 2012 11:03:04 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6998F8FC15; Sun, 16 Sep 2012 11:03:04 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1436:c790:b277:4bac] (unknown [IPv6:2001:7b8:3a7:0:1436:c790:b277:4bac]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CF3175C37; Sun, 16 Sep 2012 13:03:02 +0200 (CEST) Message-ID: <5055B1E5.6090401@andric.com> Date: Sun, 16 Sep 2012 13:03:01 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: Konstantin Belousov References: <50550285.4040203@andric.com> <20120916051909.GI37286@deviant.kiev.zoral.com.ua> In-Reply-To: <20120916051909.GI37286@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Compiler performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 11:03:04 -0000 On 2012-09-16 07:19, Konstantin Belousov wrote: > On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: ... > I tried to map the CPUID into more human-friendly family moniker, and it > seems that these are Pentium-4 class CPUs. Am I right ? Yes, it is apparently a Nocona model, this is part of the dmesg: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.24-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Family = f Model = 4 Stepping = 1 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100800 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4097470464 (3907 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 > If yes, could you, please, rerun the tests on anything more recent than > Core2, i.e. any Core i7-whatever class of Xeons ? I would love to, especially because the tests will complete faster, but I currently do not have access to physical machines of that class. Normally I do performance tests on the FreeBSD reference machines, but since these tests require booting with a custom kernel (and preferably root access + remote console), I cannot use them. So if somebody can offer such a machine (for a limited time only, a few days most likely, 1 week maximum), it would be great. -Dimitry From owner-freebsd-toolchain@FreeBSD.ORG Sun Sep 16 11:32:27 2012 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 001A8106566B; Sun, 16 Sep 2012 11:32:26 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEB68FC08; Sun, 16 Sep 2012 11:32:26 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 06A7C5C37; Sun, 16 Sep 2012 13:32:24 +0200 (CEST) Message-ID: <5055B8C7.4030601@andric.com> Date: Sun, 16 Sep 2012 13:32:23 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: Garrett Cooper References: <50550285.4040203@andric.com> <20120916051909.GI37286@deviant.kiev.zoral.com.ua> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040306000003090409000501" Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Compiler performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 11:32:27 -0000 This is a multi-part message in MIME format. --------------040306000003090409000501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-09-16 07:25, Garrett Cooper wrote: ... > If you can provide the tests, I can rerun it on some Nehalem class > workstations I have access to. I unfortunately don't have access to > SNB/Romley hardware yet. I did these tests as follows: - Install a recent -CURRENT snapshot on the box (or rebuild world and kernel by hand and install them). - Install Subversion. - Checkout head sources into /usr/src, if not already there. - Build GENERIC kernel with gcc, using default settings, and install it into /boot/kernel.gcc. - Build GENERIC kernel with clang, using default settings, and install it into /boot/kernel.clang. - Boot machine with either kernel, then run the attached runtest.sh script, with the buildworld_{single,multi}.sh scripts in the same directory. Save the resulting run-*.txt files in a directory that indicates whether the kernel in use was built by gcc or by clang. You can tweak the 'num_runs' variable at the top of runtest.sh to do more runs, if the machine is fast. This should give more confidence in the final statistics. I did just 3 runs on Gavin's machine, since it took more than 7 hours for a single-threaded buildworld to complete. Doing 6 runs should be more than enough. The run-*.txt files contain the time(1) output of each run, and should be processed through ministat to give average, stddev and so on. Just send them to me, I will process them and summarize the statistics. Alternatively, you can give me remote access, and I'll do it. :) --------------040306000003090409000501 Content-Type: text/plain; charset=windows-1252; name="runtest.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="runtest.sh" #!/bin/sh mypath="${0%/*}" num_runs=3 set -e do_runtest() { for i in $(jot ${num_runs}); do rm -rf /usr/obj/* sync echo "Doing build $1, run $i..." /usr/bin/time -l -o run-$1-$i.txt ${mypath}/build$1.sh > run-$1-$i.log head -1 run-$1-$i.txt done } do_runtest world_single do_runtest world_multi --------------040306000003090409000501 Content-Type: text/plain; charset=windows-1252; name="buildworld_single.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="buildworld_single.sh" #!/bin/sh set -e cd /usr/src make -s buildworld --------------040306000003090409000501 Content-Type: text/plain; charset=windows-1252; name="buildworld_multi.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="buildworld_multi.sh" #!/bin/sh set -e cd /usr/src make -s -j8 buildworld --------------040306000003090409000501-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Sep 16 22:33:16 2012 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60DE8106566B; Sun, 16 Sep 2012 22:33:16 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1D88FC0A; Sun, 16 Sep 2012 22:33:15 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 1B879861A9; Mon, 17 Sep 2012 00:33:07 +0200 (CEST) Message-ID: <505653A3.8010607@bsdforen.de> Date: Mon, 17 Sep 2012 00:33:07 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <50550285.4040203@andric.com> In-Reply-To: <50550285.4040203@andric.com> Content-Type: text/plain; charset=ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: Compiler performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 22:33:16 -0000 On 16/09/2012 00:34, Dimitry Andric wrote: > ... > > The executive summary: GENERIC kernels compiled with clang 3.2 are > slightly faster than those compiled by gcc 4.2.1, though the difference > will not very noticeable in practice. It has been my impression in the past, that math heavy applications benefit from GCC whereas I/O heavy applications yield better performance when compiled with clang. I'd say a kernel has a lot more I/O than math to deal with. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 17 19:10:31 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69BD51065676 for ; Mon, 17 Sep 2012 19:10:31 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 1931B8FC16 for ; Mon, 17 Sep 2012 19:10:29 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q8HJAS2g043397 for ; Mon, 17 Sep 2012 14:10:28 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q8HJASaQ043396 for toolchain@freebsd.org; Mon, 17 Sep 2012 14:10:28 -0500 (CDT) (envelope-from brooks) Date: Mon, 17 Sep 2012 14:10:28 -0500 From: Brooks Davis To: toolchain@freebsd.org Message-ID: <20120917191028.GA42648@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:10:31 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Now that we have the COMPILER_TYPE variable I'm following up on an idea by theraven@ that we should enable libc++ by default when we are building world with a compiler that supports it. The following patch implements this: http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff One key question is, when do we want to throw this switch? Do we do it now so people using clang start using it sooner or do we wait until we've switched the default compiler and things have settled a bit? I suspect that we'll want to wait, but I'm curious what others think. -- Brooks Index: share/mk/bsd.own.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/mk/bsd.own.mk (revision 240466) +++ share/mk/bsd.own.mk (working copy) @@ -432,7 +432,6 @@ ICONV \ IDEA \ INSTALL_AS_USER \ - LIBCPLUSPLUS \ NAND \ OFED \ SHARED_TOOLCHAIN @@ -642,6 +641,33 @@ .endif .endfor =20 +# +# MK_* options that default to on if the compiler is clang. +# +.include +.for var in \ + LIBCPLUSPLUS +.if defined(WITH_${var}) && defined(WITHOUT_${var}) +.error WITH_${var} and WITHOUT_${var} can't both be set. +.endif +.if defined(MK_${var}) +.error MK_${var} can't be set by a user. +.endif +.if ${COMPILER_TYPE} =3D=3D "clang" +.if defined(WITHOUT_${var}) +MK_${var}:=3D no +.else +MK_${var}:=3D yes +.endif +.else +.if defined(WITH_${var}) +MK_${var}:=3D yes +.else +MK_${var}:=3D no +.endif +.endif +.endfor + .if ${MK_CTF} !=3D "no" CTFCONVERT_CMD=3D ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} .elif defined(MAKE_VERSION) && ${MAKE_VERSION} >=3D 5201111300 --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQV3WjXY6L6fI4GtQRApOqAKDMVpYdYwjkX3iYivS73til16fcagCgrVEa j+wOQvFMBzqdXaoyQdo/0qk= =H+Ke -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 17 19:37:00 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D541C106566B for ; Mon, 17 Sep 2012 19:37:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 94E1A8FC12 for ; Mon, 17 Sep 2012 19:37:00 +0000 (UTC) Received: by iea17 with SMTP id 17so7602164iea.13 for ; Mon, 17 Sep 2012 12:37:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FLZ6Bkk+KW9qzI/uPUTDhtrAYpePrTqMkBH6brvswCY=; b=a1v2Fkg5AoITo7RQa6FkQOUDwSjWiZYJa2AVYlX6KKZAp/hWs43p9ac63pZyrJmnvE 9Kh/Ss2riT3wr2zRKEoVr0ktb6TDavVtGpy/Pj9FFizhW9Cvfgn7W0uiwH+uIHMvoBGF 2hOyVAUJIwh0UgGhLLt9POcyddkW7EC+hJlih0j55+VWOIaajn1ggP+NnWdTmLLZmUfm RzznS80/kWdbgI5juLvdAJTi7ZhKSz5u28J+YcAZ7JEE5fBaOpmz2/vEKM956ye5vDEd aDNwqTiU1J46ocfnpKDXD8rOAJQDNFvpfUGOr8CdI1Nuh2lDkd+wWi8NdJW548B/Fjsd /jzQ== Received: by 10.43.7.132 with SMTP id oo4mr9897766icb.6.1347910619967; Mon, 17 Sep 2012 12:36:59 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id a10sm19261625igd.1.2012.09.17.12.36.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 12:36:57 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120917191028.GA42648@lor.one-eyed-alien.net> Date: Mon, 17 Sep 2012 13:36:53 -0600 Content-Transfer-Encoding: 7bit Message-Id: <0D8164DE-97A3-4870-A8DF-37E91ECFE87F@bsdimp.com> References: <20120917191028.GA42648@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmmLU4QTUlDTuKKKEZoIAJW+zODsjEI4HReewlnTuIz2grGLb7BiCgtSVwvIHAeaTM5mDQ2 Cc: toolchain@freebsd.org Subject: Re: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:37:00 -0000 On Sep 17, 2012, at 1:10 PM, Brooks Davis wrote: > Now that we have the COMPILER_TYPE variable I'm following up on an idea > by theraven@ that we should enable libc++ by default when we are > building world with a compiler that supports it. The following patch > implements this: > > http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff > > One key question is, when do we want to throw this switch? Do we do it > now so people using clang start using it sooner or do we wait until > we've switched the default compiler and things have settled a bit? > > I suspect that we'll want to wait, but I'm curious what others think. Is the compiler type set to be the host's build, or the target's? Warner > -- Brooks > > Index: share/mk/bsd.own.mk > =================================================================== > --- share/mk/bsd.own.mk (revision 240466) > +++ share/mk/bsd.own.mk (working copy) > @@ -432,7 +432,6 @@ > ICONV \ > IDEA \ > INSTALL_AS_USER \ > - LIBCPLUSPLUS \ > NAND \ > OFED \ > SHARED_TOOLCHAIN > @@ -642,6 +641,33 @@ > .endif > .endfor > > +# > +# MK_* options that default to on if the compiler is clang. > +# > +.include > +.for var in \ > + LIBCPLUSPLUS > +.if defined(WITH_${var}) && defined(WITHOUT_${var}) > +.error WITH_${var} and WITHOUT_${var} can't both be set. > +.endif > +.if defined(MK_${var}) > +.error MK_${var} can't be set by a user. > +.endif > +.if ${COMPILER_TYPE} == "clang" > +.if defined(WITHOUT_${var}) > +MK_${var}:= no > +.else > +MK_${var}:= yes > +.endif > +.else > +.if defined(WITH_${var}) > +MK_${var}:= yes > +.else > +MK_${var}:= no > +.endif > +.endif > +.endfor > + > .if ${MK_CTF} != "no" > CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > .elif defined(MAKE_VERSION) && ${MAKE_VERSION} >= 5201111300 From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 17 19:51:42 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D92C1065692; Mon, 17 Sep 2012 19:51:42 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id E44DA8FC20; Mon, 17 Sep 2012 19:51:40 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q8HJpcvH043607; Mon, 17 Sep 2012 14:51:38 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q8HJpba9043606; Mon, 17 Sep 2012 14:51:38 -0500 (CDT) (envelope-from brooks) Date: Mon, 17 Sep 2012 14:51:37 -0500 From: Brooks Davis To: Warner Losh Message-ID: <20120917195137.GA43564@lor.one-eyed-alien.net> References: <20120917191028.GA42648@lor.one-eyed-alien.net> <0D8164DE-97A3-4870-A8DF-37E91ECFE87F@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <0D8164DE-97A3-4870-A8DF-37E91ECFE87F@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: toolchain@freebsd.org Subject: Re: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:51:42 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2012 at 01:36:53PM -0600, Warner Losh wrote: >=20 > On Sep 17, 2012, at 1:10 PM, Brooks Davis wrote: > > Now that we have the COMPILER_TYPE variable I'm following up on an idea > > by theraven@ that we should enable libc++ by default when we are > > building world with a compiler that supports it. The following patch > > implements this: > >=20 > > http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff > >=20 > > One key question is, when do we want to throw this switch? Do we do it > > now so people using clang start using it sooner or do we wait until > > we've switched the default compiler and things have settled a bit? > >=20 > > I suspect that we'll want to wait, but I'm curious what others think. >=20 > Is the compiler type set to be the host's build, or the target's? It's the target's compiler unless you do a make manually in a portion of the tree. This means that if you do "make -DWITH_CLANG_IS_CC buildworld" with this patch that you get libc++ even on a 9-STABLE system. An alternative approach here would to enhance bsd.compiler.mk to have a COMPILER_FEATURES variable and key off of a feature named something like "c++11". We'll certainly want to do something like that in the future to support external compilers with varying features. -- Brooks >=20 > Warner >=20 > > -- Brooks > >=20 > > Index: share/mk/bsd.own.mk > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- share/mk/bsd.own.mk (revision 240466) > > +++ share/mk/bsd.own.mk (working copy) > > @@ -432,7 +432,6 @@ > > ICONV \ > > IDEA \ > > INSTALL_AS_USER \ > > - LIBCPLUSPLUS \ > > NAND \ > > OFED \ > > SHARED_TOOLCHAIN > > @@ -642,6 +641,33 @@ > > .endif > > .endfor > >=20 > > +# > > +# MK_* options that default to on if the compiler is clang. > > +# > > +.include > > +.for var in \ > > + LIBCPLUSPLUS > > +.if defined(WITH_${var}) && defined(WITHOUT_${var}) > > +.error WITH_${var} and WITHOUT_${var} can't both be set. > > +.endif > > +.if defined(MK_${var}) > > +.error MK_${var} can't be set by a user. > > +.endif > > +.if ${COMPILER_TYPE} =3D=3D "clang" > > +.if defined(WITHOUT_${var}) > > +MK_${var}:=3D no > > +.else > > +MK_${var}:=3D yes > > +.endif > > +.else > > +.if defined(WITH_${var}) > > +MK_${var}:=3D yes > > +.else > > +MK_${var}:=3D no > > +.endif > > +.endif > > +.endfor > > + > > .if ${MK_CTF} !=3D "no" > > CTFCONVERT_CMD=3D ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > > .elif defined(MAKE_VERSION) && ${MAKE_VERSION} >=3D 5201111300 >=20 --DocE+STaALJfprDB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQV39JXY6L6fI4GtQRAjOoAKCexVUiSKRscPtkrig0Ml8hTFQW8QCgkyaH UErYwygjgOt315ai927/Mnk= =zNQn -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 17 20:06:54 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 946C1106566C; Mon, 17 Sep 2012 20:06:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6968FC12; Mon, 17 Sep 2012 20:06:54 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:59a6:c010:f3bf:87fa] (unknown [IPv6:2001:7b8:3a7:0:59a6:c010:f3bf:87fa]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E9CC55C59; Mon, 17 Sep 2012 22:06:46 +0200 (CEST) Message-ID: <505782D2.2030103@FreeBSD.org> Date: Mon, 17 Sep 2012 22:06:42 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: Brooks Davis References: <20120917191028.GA42648@lor.one-eyed-alien.net> In-Reply-To: <20120917191028.GA42648@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@freebsd.org Subject: Re: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:06:54 -0000 On 2012-09-17 21:10, Brooks Davis wrote: > Now that we have the COMPILER_TYPE variable I'm following up on an idea > by theraven@ that we should enable libc++ by default when we are > building world with a compiler that supports it. The following patch > implements this: > > http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff > > One key question is, when do we want to throw this switch? Do we do it > now so people using clang start using it sooner or do we wait until > we've switched the default compiler and things have settled a bit? Well, building libc++ does not mean automatically using it. What is the use case for only building (and installing) libc++, but not linking it to anything? Just so people could build something with it later on? In any case, I have been building libc++ for a long time now, and also did some commits left and right to be able to actually use it for the base system, e.g. all C++ programs in my installations are already linked to libc++ (dynamically or statically). I have seen no problems at all, and I am even working on a WITHOUT_LIBSTDCPLUSPLUS option. :) I think the end goal should be to enable building and using libc++ with one switch. And sooner or later, to make that the default. Then FreeBSD will finally be able to use C++0x and C++11 features natively. From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 17 20:37:19 2012 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37AE8106566B; Mon, 17 Sep 2012 20:37:19 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id CFD078FC1C; Mon, 17 Sep 2012 20:37:17 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q8HKbHVh043927; Mon, 17 Sep 2012 15:37:17 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q8HKbH6u043926; Mon, 17 Sep 2012 15:37:17 -0500 (CDT) (envelope-from brooks) Date: Mon, 17 Sep 2012 15:37:17 -0500 From: Brooks Davis To: Dimitry Andric Message-ID: <20120917203717.GB43626@lor.one-eyed-alien.net> References: <20120917191028.GA42648@lor.one-eyed-alien.net> <505782D2.2030103@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: <505782D2.2030103@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: toolchain@FreeBSD.org Subject: Re: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:37:19 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2012 at 10:06:42PM +0200, Dimitry Andric wrote: > On 2012-09-17 21:10, Brooks Davis wrote: > > Now that we have the COMPILER_TYPE variable I'm following up on an idea > > by theraven@ that we should enable libc++ by default when we are > > building world with a compiler that supports it. The following patch > > implements this: > > > > http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff > > > > One key question is, when do we want to throw this switch? Do we do it > > now so people using clang start using it sooner or do we wait until > > we've switched the default compiler and things have settled a bit? >=20 > Well, building libc++ does not mean automatically using it. What is the > use case for only building (and installing) libc++, but not linking it > to anything? Just so people could build something with it later on? For now it's really so that people can start testing it without having to tweak more switches. From that perspective it probably makes sense to throw the switch sooner so it's readily available for people who want to start testing it. > In any case, I have been building libc++ for a long time now, and also > did some commits left and right to be able to actually use it for the > base system, e.g. all C++ programs in my installations are already > linked to libc++ (dynamically or statically). I have seen no problems > at all, and I am even working on a WITHOUT_LIBSTDCPLUSPLUS option. :) >=20 > I think the end goal should be to enable building and using libc++ with > one switch. And sooner or later, to make that the default. Then > FreeBSD will finally be able to use C++0x and C++11 features natively. It seems to me that installed, but not used by default is a useful transition state since it reduces the number of knobs required to try it out. If it turns out that other people's experiences match yours then we'll be a in a good position to flip the default linkage switch as well. -- Brooks --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQV4n8XY6L6fI4GtQRAqpOAKDl+HUUTzuN7Er0/aPRFty/TCQwZgCeM/d0 vt0/zybBdajdVZffxvJ66wM= =Ft9j -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 17 21:29:56 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7531065674 for ; Mon, 17 Sep 2012 21:29:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 38A3A8FC1B for ; Mon, 17 Sep 2012 21:29:56 +0000 (UTC) Received: by iayy25 with SMTP id y25so7158586iay.13 for ; Mon, 17 Sep 2012 14:29:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LCwirfIQ3M5bg5F8yt50IjujD6rfCBCAR5E5WmIv2kE=; b=iD6b+Nue+1P5kVBQyUvEeKS8OEieKjYYGLHzDYBxBXyhrMckEI/mfmEr6nCz9GAQyE ofcRYdWbswsCO0nL775wwZ4AQ9iZhigRj34jYZ3ar5DUDdNDp9sRgmpib8LrgdxadVdO m/axMPn6M58wLwaj6R5wMgMighJhJsYxqK4UUI2DTERcuXG6OYebLuPwxq1UcLPIgNU5 l3lRq03SQ/B3Y5cFIFNN8eeaoOKBkmW5P2nhSXettsBN/Tdnlb1dfg2xePc4AkKkXPrJ vEXNxdZuRAkC8EkvQPhkPmWCunYn8tRr8ux88KMzdSOoR5++1ue8/6/Hg5cwEVQZDElt kZHw== Received: by 10.50.154.164 with SMTP id vp4mr8283775igb.66.1347917395473; Mon, 17 Sep 2012 14:29:55 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nh1sm8433198igc.11.2012.09.17.14.29.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 14:29:53 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120917195137.GA43564@lor.one-eyed-alien.net> Date: Mon, 17 Sep 2012 15:29:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <52BDD0E3-318A-4CD4-9BE8-0C9CBF1096A8@bsdimp.com> References: <20120917191028.GA42648@lor.one-eyed-alien.net> <0D8164DE-97A3-4870-A8DF-37E91ECFE87F@bsdimp.com> <20120917195137.GA43564@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkyzb1e37V03nu02EB/M2kpQ4tQUI+2AlQA2Oi6JMlPB3vNNWlnDgNxAlCECaT2aNQZWOii Cc: toolchain@freebsd.org Subject: Re: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:29:56 -0000 On Sep 17, 2012, at 1:51 PM, Brooks Davis wrote: > On Mon, Sep 17, 2012 at 01:36:53PM -0600, Warner Losh wrote: >>=20 >> On Sep 17, 2012, at 1:10 PM, Brooks Davis wrote: >>> Now that we have the COMPILER_TYPE variable I'm following up on an = idea >>> by theraven@ that we should enable libc++ by default when we are >>> building world with a compiler that supports it. The following = patch >>> implements this: >>>=20 >>> http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff >>>=20 >>> One key question is, when do we want to throw this switch? Do we do = it >>> now so people using clang start using it sooner or do we wait until >>> we've switched the default compiler and things have settled a bit? >>>=20 >>> I suspect that we'll want to wait, but I'm curious what others = think. >>=20 >> Is the compiler type set to be the host's build, or the target's? >=20 > It's the target's compiler unless you do a make manually in a portion > of the tree. This means that if you do "make -DWITH_CLANG_IS_CC > buildworld" with this patch that you get libc++ even on a 9-STABLE > system. I think that's good. I'm mostly worried about cases where the host = system is say gcc, but the target is clang or vice versa. We've had = lots of cross threading issues with the cross build and I was hoping = this wouldn't introduce a new one. > An alternative approach here would to enhance bsd.compiler.mk to have = a > COMPILER_FEATURES variable and key off of a feature named something = like > "c++11". We'll certainly want to do something like that in the future > to support external compilers with varying features. I like this idea. For user facing features, we should have = COMPILER_VERSION keyed values of COMPILER_FEATURES so the tree can use = COMPILER_FEATURES without the user having to know that gcc 4.3 needs = what may be a longish list. Warner > -- Brooks >=20 >>=20 >> Warner >>=20 >>> -- Brooks >>>=20 >>> Index: share/mk/bsd.own.mk >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- share/mk/bsd.own.mk (revision 240466) >>> +++ share/mk/bsd.own.mk (working copy) >>> @@ -432,7 +432,6 @@ >>> ICONV \ >>> IDEA \ >>> INSTALL_AS_USER \ >>> - LIBCPLUSPLUS \ >>> NAND \ >>> OFED \ >>> SHARED_TOOLCHAIN >>> @@ -642,6 +641,33 @@ >>> .endif >>> .endfor >>>=20 >>> +# >>> +# MK_* options that default to on if the compiler is clang. >>> +# >>> +.include >>> +.for var in \ >>> + LIBCPLUSPLUS >>> +.if defined(WITH_${var}) && defined(WITHOUT_${var}) >>> +.error WITH_${var} and WITHOUT_${var} can't both be set. >>> +.endif >>> +.if defined(MK_${var}) >>> +.error MK_${var} can't be set by a user. >>> +.endif >>> +.if ${COMPILER_TYPE} =3D=3D "clang" >>> +.if defined(WITHOUT_${var}) >>> +MK_${var}:=3D no >>> +.else >>> +MK_${var}:=3D yes >>> +.endif >>> +.else >>> +.if defined(WITH_${var}) >>> +MK_${var}:=3D yes >>> +.else >>> +MK_${var}:=3D no >>> +.endif >>> +.endif >>> +.endfor >>> + >>> .if ${MK_CTF} !=3D "no" >>> CTFCONVERT_CMD=3D ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>> .elif defined(MAKE_VERSION) && ${MAKE_VERSION} >=3D 5201111300 >>=20 From owner-freebsd-toolchain@FreeBSD.ORG Tue Sep 18 08:32:11 2012 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16841106566C; Tue, 18 Sep 2012 08:32:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id D51B48FC14; Tue, 18 Sep 2012 08:32:10 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q8I8W2PU077207 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 18 Sep 2012 08:32:03 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120917191028.GA42648@lor.one-eyed-alien.net> Date: Tue, 18 Sep 2012 09:31:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B405D52-65B8-44A2-B350-0973A8B254CB@FreeBSD.org> References: <20120917191028.GA42648@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org Subject: Re: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 08:32:11 -0000 On 17 Sep 2012, at 20:10, Brooks Davis wrote: > One key question is, when do we want to throw this switch? Do we do = it > now so people using clang start using it sooner or do we wait until > we've switched the default compiler and things have settled a bit? As dim says, enabling it does not mean requiring things to use it. I = would like to flip this switch as soon as possible so that it's easy for = ports people maintaining C++ ports to see if their stuff breaks with = -stdlib=3Dlibc++. A few have already tested this, but I'd like to see = much wider testing. =20 The more important switches to worry about are: - Changing the default for -stdlib=3D to libc++ (it's currently = libstdc++. I think I'll probably make it libc++ when std=3D{c,gnu}++11 = soon) - Removing libstdc++ from base and putting it in the compat9 port. These have the potential to impact users significantly. Simply having = libc++.{so,a} on their system does not unless they explicitly choose to = test it. David= From owner-freebsd-toolchain@FreeBSD.ORG Tue Sep 18 14:24:46 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27ABF106564A; Tue, 18 Sep 2012 14:24:46 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id 7137F8FC0A; Tue, 18 Sep 2012 14:24:45 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADyDWFBbsUA+/2dsb2JhbABFhgm2MoEJgiABAQQBIzMiAQULCxgJFgsCAgkDAgECASceBg0BBQIBAYd2CqcjkxuLG4VegRIDjmmBIJV7gmg Received: from 62.64-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.64.62]) by relay.skynet.be with ESMTP; 18 Sep 2012 16:23:36 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.5/8.14.5) with ESMTP id q8IENZWe003077; Tue, 18 Sep 2012 16:23:35 +0200 (CEST) (envelope-from tijl@coosemans.org) Message-ID: <505883E3.3050103@coosemans.org> Date: Tue, 18 Sep 2012 16:23:31 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120804 Thunderbird/14.0 MIME-Version: 1.0 To: Mehmet Erol Sanliturk References: <504F5101.8090906@FreeBSD.org> <505101C3.70203@freebsd.org> <20120913020833.GA8255@troutmask.apl.washington.edu> <1347550332.1110.108.camel@revolution.hippie.lan> <20120913161024.GA13846@troutmask.apl.washington.edu> <20120914202319.GB5244@lor.one-eyed-alien.net> <20120915001808.GA70215@troutmask.apl.washington.edu> <20120915010600.GA70426@troutmask.apl.washington.edu> <20120915124809.GA10939@freebsd.org> <50548736.9030203@coosemans.org> <20120915140933.GA17801@freebsd.org> <505490FB.2000807@coosemans.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1DF7D13A799809AA81AB7E12" Cc: toolchain@freebsd.org, current@freebsd.org Subject: Re: Clang as default compiler November 4th X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 14:24:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1DF7D13A799809AA81AB7E12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15-09-2012 17:39, Mehmet Erol Sanliturk wrote: > On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans wr= ote:=20 >> On 15-09-2012 16:09, Roman Divacky wrote: >>> Is this correct? >>> >>> lev ~$ ./cos 1.23456789e20 >>> 6.031937e-01 >>> -9.629173e-02 >>> 2.814722e-01 >> >> Yes, that's what the libm call returns.=20 >=20 > Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64 > x86_64 x86_64 GNU/Linux >=20 > clang version 3.0 (tags/RELEASE_30/final) > Target: x86_64-redhat-linux-gnu > Thread model: posix >=20 >=20 > Output of the initial program is the following : >=20 > #include > #include > #include >=20 > int > main( int argc, char **argv ) { > double d =3D strtod( argv[ 1 ], NULL ); >=20 > printf( " cos : %e\n", ( double ) cos( d )); > printf( "cosf : %e\n", ( double ) cosf( d )); > printf( "cosl : %e\n", ( double ) cosl( d )); > return( 0 ); > } >=20 >=20 > cos : 2.814722e-01 > cosf : -9.629173e-02 > cosl : 7.738403e-01 This is probably because SSE instructions are used on amd64. > Output of the following program is different : The reason is that... > #include > #include > #include >=20 > int > main( int argc, char **argv ) { > double d ; > double two_pi ; > double f ; > double v ; >=20 > two_pi =3D 2 * 3.14159265358979323846 ; > d =3D strtod( argv[ 1 ], NULL ); >=20 > f =3D floor ( d / two_pi ) ; > v =3D d - f * two_pi ; =2E..this is a poor way to compute a remainder. Try to use fmod() or remainder() instead. > printf( " given : %e\n", ( double ) d ); > printf( " multiplier : %e\n", ( double ) f ); > printf( "reduced : %e\n", ( double ) v ); >=20 >=20 > printf( " cos ( %e ) : %e\n", d , ( double ) cos( d )); > printf( "cosf ( %e ) : %e\n", d , ( double ) cosf( d )); > printf( "cosl ( %e ) : %e\n", d , ( double ) cosl( d )); >=20 >=20 > printf( " cos ( %e ) : %e\n", v , ( double ) cos( v )); > printf( "cosf ( %e ) : %e\n", v , ( double ) cosf( v )); > printf( "cosl ( %e ) : %e\n", v , ( double ) cosl( v )); >=20 >=20 > return( 0 ); > } >=20 >=20 > given : 1.234568e+20 > multiplier : 1.964876e+19 > reduced : 1.638400e+04 >=20 >=20 > cos ( 1.234568e+20 ) : 2.814722e-01 > cosf ( 1.234568e+20 ) : -9.629173e-02 > cosl ( 1.234568e+20 ) : 7.738403e-01 >=20 > cos ( 1.638400e+04 ) : -8.285342e-01 > cosf ( 1.638400e+04 ) : -8.285342e-01 > cosl ( 1.638400e+04 ) : -8.285342e-01 --------------enig1DF7D13A799809AA81AB7E12 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iF4EAREIAAYFAlBYg+cACgkQfoCS2CCgtitqygD/V7Qv07Ni2tZG6xJZx4zSwVuq SmtXliYN5IKZAlUnuaUA/jbZ4TqcvzdfLR059dZUqMMaS8udmcs10xtFVcIWmlRV =+OaS -----END PGP SIGNATURE----- --------------enig1DF7D13A799809AA81AB7E12-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Sep 18 16:20:07 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B0591065670; Tue, 18 Sep 2012 16:20:07 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id C32118FC0A; Tue, 18 Sep 2012 16:20:06 +0000 (UTC) Received: by oagm1 with SMTP id m1so36283oag.13 for ; Tue, 18 Sep 2012 09:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yZk9stUaLD5+yCydm0aAMzZAdlMbOE6Kou/SDIcV1JQ=; b=bdtsAQ1ku08Jvuz9F8gRCIwexigECk46ujuVe4WK3v/4ht6hDwrEyKakj2Lbs9RUjH FkCG9ZSzjzjcQUuglF2FwGT9SPTnRJ/oaVQivNUhLrQOxslSm6rnV1ekm1VzlLVWoxEv KYmKtUDIikDvfP4uQzCWhPW4R0e1YWsYTI93uQAiGY/HKBxzNxq6Kg1nD/UbGKihF8Y3 XNrFYEfbwIIz/TDeppgArnYHWefc4hR3p/E+8F1kIiLrV99OD5DuKOzuZUcho/HH0Hza 4jFQKHG2yKA85c0nDKh74FxS1+bj4qKraQGwvd7CYezNdg/dEgZk1D5qpOcv+QzuWST2 /9kA== MIME-Version: 1.0 Received: by 10.182.53.103 with SMTP id a7mr675172obp.3.1347985206014; Tue, 18 Sep 2012 09:20:06 -0700 (PDT) Received: by 10.182.141.66 with HTTP; Tue, 18 Sep 2012 09:20:05 -0700 (PDT) In-Reply-To: <505883E3.3050103@coosemans.org> References: <504F5101.8090906@FreeBSD.org> <505101C3.70203@freebsd.org> <20120913020833.GA8255@troutmask.apl.washington.edu> <1347550332.1110.108.camel@revolution.hippie.lan> <20120913161024.GA13846@troutmask.apl.washington.edu> <20120914202319.GB5244@lor.one-eyed-alien.net> <20120915001808.GA70215@troutmask.apl.washington.edu> <20120915010600.GA70426@troutmask.apl.washington.edu> <20120915124809.GA10939@freebsd.org> <50548736.9030203@coosemans.org> <20120915140933.GA17801@freebsd.org> <505490FB.2000807@coosemans.org> <505883E3.3050103@coosemans.org> Date: Tue, 18 Sep 2012 09:20:05 -0700 Message-ID: From: Mehmet Erol Sanliturk To: Tijl Coosemans Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: toolchain@freebsd.org, current@freebsd.org Subject: Re: Clang as default compiler November 4th X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:20:07 -0000 On Tue, Sep 18, 2012 at 7:23 AM, Tijl Coosemans wrote: > On 15-09-2012 17:39, Mehmet Erol Sanliturk wrote: > > On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans > wrote: > >> On 15-09-2012 16:09, Roman Divacky wrote: > >>> Is this correct? > >>> > >>> lev ~$ ./cos 1.23456789e20 > >>> 6.031937e-01 > >>> -9.629173e-02 > >>> 2.814722e-01 > >> > >> Yes, that's what the libm call returns. > > > > Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64 > > x86_64 x86_64 GNU/Linux > > > > clang version 3.0 (tags/RELEASE_30/final) > > Target: x86_64-redhat-linux-gnu > > Thread model: posix > > > > > > Output of the initial program is the following : > > > > #include > > #include > > #include > > > > int > > main( int argc, char **argv ) { > > double d = strtod( argv[ 1 ], NULL ); > > > > printf( " cos : %e\n", ( double ) cos( d )); > > printf( "cosf : %e\n", ( double ) cosf( d )); > > printf( "cosl : %e\n", ( double ) cosl( d )); > > return( 0 ); > > } > > > > > > cos : 2.814722e-01 > > cosf : -9.629173e-02 > > cosl : 7.738403e-01 > > This is probably because SSE instructions are used on amd64. > > > Output of the following program is different : > > The reason is that... > > > #include > > #include > > #include > > > > int > > main( int argc, char **argv ) { > > double d ; > > double two_pi ; > > double f ; > > double v ; > > > > two_pi = 2 * 3.14159265358979323846 ; > > d = strtod( argv[ 1 ], NULL ); > > > > f = floor ( d / two_pi ) ; > > v = d - f * two_pi ; > > ...this is a poor way to compute a remainder. Try to use fmod() or > remainder() instead. > My C knowledge is NOT very well . Thanks . > > > printf( " given : %e\n", ( double ) d ); > > printf( " multiplier : %e\n", ( double ) f ); > > printf( "reduced : %e\n", ( double ) v ); > > > > > > printf( " cos ( %e ) : %e\n", d , ( double ) cos( d )); > > printf( "cosf ( %e ) : %e\n", d , ( double ) cosf( d )); > > printf( "cosl ( %e ) : %e\n", d , ( double ) cosl( d )); > > > > > > printf( " cos ( %e ) : %e\n", v , ( double ) cos( v )); > > printf( "cosf ( %e ) : %e\n", v , ( double ) cosf( v )); > > printf( "cosl ( %e ) : %e\n", v , ( double ) cosl( v )); > > > > > > return( 0 ); > > } > > > > > > given : 1.234568e+20 > > multiplier : 1.964876e+19 > > reduced : 1.638400e+04 > > > > > > cos ( 1.234568e+20 ) : 2.814722e-01 > > cosf ( 1.234568e+20 ) : -9.629173e-02 > > cosl ( 1.234568e+20 ) : 7.738403e-01 > > > > cos ( 1.638400e+04 ) : -8.285342e-01 > > cosf ( 1.638400e+04 ) : -8.285342e-01 > > cosl ( 1.638400e+04 ) : -8.285342e-01 > > My intention was to check whether there is a difference between Clang compiled programs in different operating systems . The GCC output is as follows : Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux cc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. given : 1.234568e+20 cos ( 1.234568e+20 ) : 2.814722e-01 cosf ( 1.234568e+20 ) : -9.629173e-02 cosl ( 1.234568e+20 ) : 7.738403e-01 multiplier : 1.964876e+19 reduced : 1.638400e+04 cos ( 1.638400e+04 ) : -8.285342e-01 cosf ( 1.638400e+04 ) : -8.285342e-01 cosl ( 1.638400e+04 ) : -8.285342e-01 multiplier : 2.607000e+03 reduced : 3.735904e+00 cos ( 3.735904e+00 ) : -8.285342e-01 cosf ( 3.735904e+00 ) : -8.285342e-01 cosl ( 3.735904e+00 ) : -8.285342e-01 This shows that GCC is NOT better than Clang . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-toolchain@FreeBSD.ORG Tue Sep 18 16:25:28 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537BC106566B; Tue, 18 Sep 2012 16:25:28 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 11A7F8FC12; Tue, 18 Sep 2012 16:25:28 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 1DF507F3876; Tue, 18 Sep 2012 18:25:18 +0200 (CEST) Date: Tue, 18 Sep 2012 18:25:18 +0200 From: Roman Divacky To: Lev Serebryakov Message-ID: <20120918162518.GA3146@freebsd.org> References: <20120910211207.GC64920@lor.one-eyed-alien.net> <20120911232244.1cadc5b5@davenulle.org> <192201737.20120912191907@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <192201737.20120912191907@serebryakov.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: toolchain@freebsd.org, Patrick Lamaiziere , current@freebsd.org Subject: Re: Clang as default compiler November 4th X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:25:28 -0000 Fwiw, I commited the "dont use long nops on amd geode" thing into llvm a few minutes ago. So this issue doesnt exist anymore. On Wed, Sep 12, 2012 at 07:19:07PM +0400, Lev Serebryakov wrote: > Hello, Patrick. > You wrote 12 ???????? 2012 ?., 1:22:44: > > PL> Well, I will not be able to run FreeBSD from scratch on my soekris :-) > Thank you for warning, I've missed this. > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 21 21:39:41 2012 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A11106566B; Fri, 21 Sep 2012 21:39:41 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6D38FC0C; Fri, 21 Sep 2012 21:39:40 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4ED435C59; Fri, 21 Sep 2012 23:39:38 +0200 (CEST) Message-ID: <505CDE9C.3060504@andric.com> Date: Fri, 21 Sep 2012 23:39:40 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Content-Type: multipart/mixed; boundary="------------070108000503090709030807" Cc: Subject: More kernel performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 21:39:41 -0000 This is a multi-part message in MIME format. --------------070108000503090709030807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, As a followup to my previous post about the performance of FreeBSD 10.0 kernels compiled with different compilers (clang and gcc), I did another series of tests, now on a more modern machine (Core i5-based). I also tested the performance with different compiler optimization settings. The attached text file[1] contains more information about these tests, performance data, and my conclusions. Any errors and omissions are also my fault, so if you notice them, please let me know. The executive summary: GENERIC kernels compiled with clang 3.2 are again a little faster than those compiled with gcc 4.2.1. For gcc, compiling with -O2 also gives a slightly faster kernel than with -O1, but for clang there is no measurable difference between those flags. Again, many thanks to Gavin Atkinson for providing the required hardware. -Dimitry [1]: Also available at: --------------070108000503090709030807 Content-Type: text/plain; charset=windows-1252; name="perftest-kernel-2012-09-21a.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="perftest-kernel-2012-09-21a.txt" KERNEL PERFORMANCE TESTS ON FREEBSD 10.0-CURRENT, SEPTEMBER 2012, PART 2 ======================================================================== INTRODUCTION ------------ These tests aim to give an indication of the runtime performance of FreeBSD kernels compiled with different compilers, at various optimization levels. The compilers tested were: - gcc 4.2.1, the system compiler in FreeBSD. - clang 3.2 (trunk 162107), which is the default version of clang in FreeBSD 10.0-CURRENT, after r239462. All tests were run on a machine gracefully provided by Gavin Atkinson, which is based on an Intel DQ57TM desktop board, with a quad-core 3.20 GHz Intel Core i5 CPU (id=0x20652), and 4 GB RAM. It runs FreeBSD/amd64 10.0-CURRENT as of Tue Sep 11 19:11:00 UTC 2012. An excerpt of dmesg follows: CPU: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz (3192.08-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20652 Family = 6 Model = 25 Stepping = 2 Features=0xbfebfbff Features2=0x298e3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3882647552 (3702 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 With each compiler, stock GENERIC kernels for amd64 were built from head as of r240384, for each of the following optimization flags: -O2 -frename-registers -pipe -fno-strict-aliasing -O1 -pipe -O0 -pipe Note that clang does not support -frename-registers, so it was omitted for the corresponding kernel builds. No CPU-specific optimization flags (-march=) were used. Each kernel was installed into a separate kernel installation directory under /boot. The system was then booted with each of these kernels, without modifying anything else, and multiple runs of "make -j8 buildworld" were done. Between each run, the /usr/obj directory was fully cleaned out, and filesystems were synced. The timing results, processed with ministat(1), are below. Building world, multi-threaded, on a GENERIC kernel compiled by clang 3.2 -O0 ----------------------------------------------------------------------------- N Min Max Median Avg Stddev real 6 6503.62 6527.84 6520.49 6517.2817 8.3845558 user 6 12534.49 12576.55 12555.29 12555.547 14.079771 sys 6 9655.1 9733.92 9716.1 9709.9533 28.981809 maxrss 6 758208 758248 758224 758222.67 13.779213 ixrss 6 4396 4401 4397 4397.1667 1.9407902 idrss 6 523 523 523 523 0 isrss 6 126 126 126 126 0 minflt 6 6.6264519e+08 6.6337812e+08 6.6297908e+08 6.6299306e+08 249092.49 majflt 6 4354 10457 5722 6207.8333 2208.4725 nswap 6 40 56 42 44.333333 6.1210021 inblock 6 25167 44267 29212 31042.667 6677.3727 oublock 6 32801 34666 33500 33635.167 692.27897 msgsnd 6 0 0 0 0 0 msgrcv 6 0 0 0 0 0 nsignals 6 60495 60504 60502 60500 3.5213634 nvcsw 6 1750409 1759010 1754971 1754668.8 3641.3163 nivcsw 6 1867335 1943885 1924258 1909641.2 30495.366 Building world, multi-threaded, on a GENERIC kernel compiled by clang 3.2 -O1 ----------------------------------------------------------------------------- N Min Max Median Avg Stddev real 6 4788.59 4831.96 4798.01 4802.305 15.48322 user 6 12239.94 12285.9 12268.91 12263.5 17.190572 sys 6 4041.05 4100.4 4083.92 4076.235 21.374684 maxrss 6 758212 758256 758256 758242.67 18.532855 ixrss 6 4963 4971 4964 4964.6667 3.1411251 idrss 6 589 590 589 589.16667 0.40824829 isrss 6 132 132 132 132 0 minflt 6 6.617985e+08 6.6339562e+08 6.629315e+08 6.6272587e+08 574835.78 majflt 6 7935 23481 17450 16901.667 5324.564 nswap 6 40 52 48 47.333333 3.9327683 inblock 6 25121 44292 29173 30980.667 6715.0864 oublock 6 24867 28037 26579 26667.167 1162.513 msgsnd 6 0 0 0 0 0 msgrcv 6 0 0 0 0 0 nsignals 6 60492 60500 60498 60496.667 3.4448028 nvcsw 6 1559857 1576788 1562507 1565002.8 6454.8513 nivcsw 6 1632143 1721204 1688209 1682830 35836.46 Building world, multi-threaded, on a GENERIC kernel compiled by clang 3.2 -O2 ----------------------------------------------------------------------------- N Min Max Median Avg Stddev real 6 4780.24 4819.77 4801.98 4798.5867 14.236627 user 6 12242.91 12275.04 12256.37 12255.905 11.676621 sys 6 4052.75 4118.65 4104.76 4096.2217 22.874298 maxrss 6 758220 758256 758256 758244.67 17.603031 ixrss 6 4960 4970 4964 4963.8333 3.4880749 idrss 6 589 590 589 589.16667 0.40824829 isrss 6 132 132 132 132 0 minflt 6 6.6248246e+08 6.6340936e+08 6.6300404e+08 6.6293496e+08 324940.82 majflt 6 4300 22493 14128 12176.833 6396.7734 nswap 6 40 52 48 46 4.8989795 inblock 6 29120 44375 29277 31760 6180.4181 oublock 6 24915 28157 25984 26315.333 1251.164 msgsnd 6 0 0 0 0 0 msgrcv 6 0 0 0 0 0 nsignals 6 60490 60499 60497 60495.667 3.2041639 nvcsw 6 1559291 1575794 1570626 1569117.3 5467.274 nivcsw 6 1593865 1678135 1654604 1640246 31701.067 Building world, multi-threaded, on a GENERIC kernel compiled by gcc 4.2.1 -O0 ----------------------------------------------------------------------------- N Min Max Median Avg Stddev real 6 6083.69 6101.08 6096.85 6094.4383 6.5165003 user 6 12424.93 12462.24 12438.63 12441.97 12.975073 sys 6 8305.66 8394.45 8377.26 8366.4767 32.469675 maxrss 6 758208 758256 758224 758225.33 16.52473 ixrss 6 4481 4491 4484 4484.6667 3.3862467 idrss 6 533 534 533 533.16667 0.40824829 isrss 6 127 127 127 127 0 minflt 6 6.6241224e+08 6.6339646e+08 6.6301629e+08 6.6292507e+08 336924.37 majflt 6 4357 9603 6231 6667.8333 1812.2422 nswap 6 40 48 40 41.666667 3.204164 inblock 6 29162 44302 29272 31759.333 6145.0026 oublock 6 30081 32816 31538 31281.5 1163.8237 msgsnd 6 0 0 0 0 0 msgrcv 6 0 0 0 0 0 nsignals 6 60500 60501 60500 60500.333 0.51639753 nvcsw 6 1701009 1713077 1709140 1707903 3975.4753 nivcsw 6 1854572 1936195 1896858 1894873.2 26725.543 Building world, multi-threaded, on a GENERIC kernel compiled by gcc 4.2.1 -O1 ----------------------------------------------------------------------------- N Min Max Median Avg Stddev real 6 4943.74 4965.28 4955.62 4953.78 7.2888627 user 6 12274.46 12334.13 12322.13 12314.472 21.858036 sys 6 4576.99 4621.09 4617.21 4609.75 16.658918 maxrss 6 758208 758256 758224 758232 19.595918 ixrss 6 4897 4902 4898 4898.6667 1.9663842 idrss 6 581 582 581 581.33333 0.51639778 isrss 6 131 131 131 131 0 minflt 6 6.626435e+08 6.634147e+08 6.6301953e+08 6.629835e+08 279004.88 majflt 6 6092 11215 9188 8755.1667 1849.3565 nswap 6 40 62 48 49.333333 7.1180522 inblock 6 29076 44462 29163 31697 6253.6444 oublock 6 25415 28495 28175 27508.167 1179.5914 msgsnd 6 0 0 0 0 0 msgrcv 6 0 0 0 0 0 nsignals 6 60488 60499 60495 60494.333 3.9832984 nvcsw 6 1575048 1588567 1584504 1582316.7 5705.6913 nivcsw 6 1682902 1745827 1730506 1722802.3 24060.717 Building world, multi-threaded, on a GENERIC kernel compiled by gcc 4.2.1 -O2 ----------------------------------------------------------------------------- N Min Max Median Avg Stddev real 6 4876.16 4901.55 4895.24 4888.7583 10.598318 user 6 12241.35 12306.04 12283.94 12278.767 23.922356 sys 6 4400.43 4452.62 4446.22 4438.0117 19.231095 maxrss 6 758212 758256 758224 758229.33 17.095809 ixrss 6 4899 4905 4900 4900.6667 2.2509257 idrss 6 581 582 582 581.83333 0.40824829 isrss 6 131 131 131 131 0 minflt 6 6.6214332e+08 6.6334997e+08 6.6298766e+08 6.6278723e+08 436172.22 majflt 6 6055 12473 9169 8895.5 2381.6063 nswap 6 40 54 48 48 4.5607017 inblock 6 29193 44443 29313 31804 6192.0071 oublock 6 25113 28152 26770 26490.167 1254.3383 msgsnd 6 0 0 0 0 0 msgrcv 6 0 0 0 0 0 nsignals 6 60496 60501 60499 60498.667 2.2509257 nvcsw 6 1566521 1592140 1579251 1578889.5 9354.883 nivcsw 6 1686675 1809406 1785290 1756283.7 50719.325 Summary: -------- On a kernel compiled with clang 3.2 -O2, building world in multi-threaded mode is ~1.9% faster in real time than on a kernel compiled with gcc 4.2.1 -O2, and ~8.3% faster in system time. On a kernel compiled with clang 3.2 -O1, building world in multi-threaded mode is ~3.2% faster in real time than on a kernel compiled with gcc 4.2.1 -O1, and ~13.1% faster in system time. On a kernel compiled with gcc 4.2.1 -O2, building world in multi-threaded mode is ~1.3% faster in real time than on a kernel compiled with gcc 4.2.1 -O1, and ~3.9% faster in system time. The difference between building world in multi-threaded mode on kernels compiled with clang 3.2 -O2 and -O1 is not significant (to within 1 standard deviation). Conclusion: ----------- Kernels compiled with clang are a little faster in real time for building world, and in system time the difference is even larger, roughly 10%. For clang, the difference between -O1 and -O2 is not measurable, but for gcc, -O2 is slightly faster than -O1. ================================================================================ Copyright (c) 2012 Dimitry Andric Verbatim copying and redistribution of this entire text are permitted, provided this notice is preserved. ================================================================================ --------------070108000503090709030807-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 22 11:20:30 2012 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3527F106566B; Sat, 22 Sep 2012 11:20:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A60988FC12; Sat, 22 Sep 2012 11:20:27 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q8MBKQJL084821; Sat, 22 Sep 2012 14:20:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q8MBKEYG072729; Sat, 22 Sep 2012 14:20:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q8MBKEpk072728; Sat, 22 Sep 2012 14:20:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Sep 2012 14:20:14 +0300 From: Konstantin Belousov To: Dimitry Andric Message-ID: <20120922112014.GH37286@deviant.kiev.zoral.com.ua> References: <505CDE9C.3060504@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="inJ2Z4oiSrNaWWYu" Content-Disposition: inline In-Reply-To: <505CDE9C.3060504@andric.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: More kernel performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 11:20:30 -0000 --inJ2Z4oiSrNaWWYu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 11:39:40PM +0200, Dimitry Andric wrote: > Hi all, >=20 > As a followup to my previous post about the performance of FreeBSD 10.0 > kernels compiled with different compilers (clang and gcc), I did another > series of tests, now on a more modern machine (Core i5-based). I also > tested the performance with different compiler optimization settings. >=20 > The attached text file[1] contains more information about these tests, > performance data, and my conclusions. Any errors and omissions are also > my fault, so if you notice them, please let me know. >=20 > The executive summary: GENERIC kernels compiled with clang 3.2 are again > a little faster than those compiled with gcc 4.2.1. For gcc, compiling > with -O2 also gives a slightly faster kernel than with -O1, but for > clang there is no measurable difference between those flags. >=20 > Again, many thanks to Gavin Atkinson for providing the required > hardware. =2E.. > Conclusion: > ----------- > Kernels compiled with clang are a little faster in real time for building= world, > and in system time the difference is even larger, roughly 10%. For clang= , the > difference between -O1 and -O2 is not measurable, but for gcc, -O2 is sli= ghtly > faster than -O1. >=20 Thank you very much for finishing the initial assessment. In my opinion, this positively closes the issue of the uncertainicity of the performance impact of the proposed clang use by default for the base system. Now, if only ports were handled. --inJ2Z4oiSrNaWWYu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBdnu4ACgkQC3+MBN1Mb4iCMgCgmdqw2MEIuQsM0v0HE9aoCKg6 /lkAoJhA1D5iqf3kTQ4+cLKdal+ARYtW =qZBX -----END PGP SIGNATURE----- --inJ2Z4oiSrNaWWYu-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 22 11:42:59 2012 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0DBE106566C; Sat, 22 Sep 2012 11:42:59 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB8C8FC14; Sat, 22 Sep 2012 11:42:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:dd8:3802:af98:bd60] (unknown [IPv6:2001:7b8:3a7:0:dd8:3802:af98:bd60]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DCC155C59; Sat, 22 Sep 2012 13:42:57 +0200 (CEST) Message-ID: <505DA447.40601@andric.com> Date: Sat, 22 Sep 2012 13:43:03 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: "O. Hartmann" References: <505CDE9C.3060504@andric.com> <505D6A51.7090808@zedat.fu-berlin.de> In-Reply-To: <505D6A51.7090808@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: More kernel performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 11:42:59 -0000 On 2012-09-22 09:35, O. Hartmann wrote: > Am 09/21/12 23:39, schrieb Dimitry Andric: ... > At least one can say FreeBSD does not suffer from performance drain > using the cutting edge clang 3.2 compared with a gcc 4.2.1 compiler, the > echo from the past. Well, the main idea of these tests is to prove that we will have no regression, or even an improvement in performance, if we make clang 3.2 the default compiler for FreeBSD 10.0, instead of gcc 4.2.1. And that seems to be the case, at least for the kernel. That said, for one of the earlier tests, it seemed that for runtime performance, gcc 4.7.1-compiled programs (in this case clang 3.2 executables) were slightly faster than clang 3.2-compiled ones. In my opinion that result is not bad for such a relatively new compiler, against such a well-established one. :) > Dimirty, are you planning also to benchmark clang 3.2 versus gcc 4.8.0? > From the development point of view, such a benchmark would be more > natural, but I do not know whether the kernel sources are gcc > 4.8-friendly and would allow such a test. The kernel sources are currentely not very friendly to anything but our in-tree gcc and clang. We hacked our version of gcc to recognize several non-standard flags, such as -fformat-extensions, and a few others. We also implemented the -fformat-extensions flag for clang, since our custom printf format specifiers are used throughout the kernel. Ideally, we would remove all these non-standard flags and format specifiers, which would make it possible to compile the kernel with any version of gcc or clang, even external ones installed from ports, or by hand. This is not a trivial task... But maybe I'll take a shot, it would be nice to have at least one comparison against more modern gcc. I can't give any serious ETA, though. :) > What is about optimization level "-O3" and architectural recognition via > "-march=native"? There are only so many things you can test, the possibilities are literally endless! I have already done a few preliminary tests for -march=native, but at least for clang, there seems to be no measureable difference in performance. The tests for gcc are still running. And indeed, -O3 is also a possibility, but again I think the difference will be very marginal, if measurable at all. -Dimitry From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 22 12:52:50 2012 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98E8110657CF; Sat, 22 Sep 2012 12:52:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 427878FC12; Sat, 22 Sep 2012 12:52:50 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TFPCS-002HEQ-Ut>; Sat, 22 Sep 2012 14:52:49 +0200 Received: from e178012211.adsl.alicedsl.de ([85.178.12.211] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TFPCS-001sr9-Pw>; Sat, 22 Sep 2012 14:52:48 +0200 Message-ID: <505DB49B.1090304@zedat.fu-berlin.de> Date: Sat, 22 Sep 2012 14:52:43 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <505CDE9C.3060504@andric.com> <505D6A51.7090808@zedat.fu-berlin.de> <505DA447.40601@andric.com> In-Reply-To: <505DA447.40601@andric.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig07897D17442F9B3244FF88FB" X-Originating-IP: 85.178.12.211 Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: More kernel performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 12:52:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig07897D17442F9B3244FF88FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Dimitry. Am 09/22/12 13:43, schrieb Dimitry Andric: > On 2012-09-22 09:35, O. Hartmann wrote: >> Am 09/21/12 23:39, schrieb Dimitry Andric: > ... >> At least one can say FreeBSD does not suffer from performance drain >> using the cutting edge clang 3.2 compared with a gcc 4.2.1 compiler, t= he >> echo from the past. >=20 > Well, the main idea of these tests is to prove that we will have no > regression, or even an improvement in performance, if we make clang > 3.2 the default compiler for FreeBSD 10.0, instead of gcc 4.2.1. And > that seems to be the case, at least for the kernel. >=20 > That said, for one of the earlier tests, it seemed that for runtime > performance, gcc 4.7.1-compiled programs (in this case clang 3.2 > executables) were slightly faster than clang 3.2-compiled ones. >=20 > In my opinion that result is not bad for such a relatively new > compiler, against such a well-established one. :) Aggreed. You're completely right and said so, there is then, except serious bugs or miscompilations, no reason to stay with the dinosaur gcc 4.2.1 ;-) >=20 >=20 >> Dimirty, are you planning also to benchmark clang 3.2 versus gcc 4.8.0= ? >> From the development point of view, such a benchmark would be more >> natural, but I do not know whether the kernel sources are gcc >> 4.8-friendly and would allow such a test. >=20 > The kernel sources are currentely not very friendly to anything but > our in-tree gcc and clang. We hacked our version of gcc to recognize > several non-standard flags, such as -fformat-extensions, and a few > others. We also implemented the -fformat-extensions flag for clang, > since our custom printf format specifiers are used throughout the > kernel. >=20 > Ideally, we would remove all these non-standard flags and format > specifiers, which would make it possible to compile the kernel with > any version of gcc or clang, even external ones installed from ports, > or by hand. This is not a trivial task... >=20 > But maybe I'll take a shot, it would be nice to have at least one > comparison against more modern gcc. I can't give any serious ETA, > though. :) When we used FreeBSD for scientific work, that was around 1998 - 2002, there were some attempts made to use Intel's icc compiler suite on FreeBSD in the 32Bit Linuxulator. That time I used that compiler only for compiling my modelling software, but there where reports of people made it possible to use the icc compiler also for compiling the FreeBSD system - with success as far as I know. What happened since then and more recent days that the sources got "polluted" by those hacks? No offense to you, but somehow this sounds that the efford has been placed in the wrong way since people revert with energy that what has been hacked with energy ;-) Neverthelesse, something is happeneing ... and this sounds good to me. >=20 >=20 >> What is about optimization level "-O3" and architectural recognition v= ia >> "-march=3Dnative"? >=20 > There are only so many things you can test, the possibilities are > literally endless! >=20 > I have already done a few preliminary tests for -march=3Dnative, but at= > least for clang, there seems to be no measureable difference in > performance. The tests for gcc are still running. I was wondering if the organisation and amount of cache present in a modern CPU is not taken into account when optimising code. Our Core2Duo CPUs still in use do have different architectural features than the more recent Core-i7 systems. Latter ones have level 3 caches. How does a compiler take advantage of those features by not given an explicit hint? >=20 > And indeed, -O3 is also a possibility, but again I think the difference= > will be very marginal, if measurable at all. Well, speaking of marginality: some of our models rund for a week, some other long term models run for 4 weeks. Consider now a performce gain of 10% average. I'd like to have it ... it saves me time ;-) >=20 > -Dimitry Oliver --------------enig07897D17442F9B3244FF88FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEbBAEBAgAGBQJQXbSgAAoJEOgBcD7A/5N8vlgH93GukRrmw0n+zBapKx0706Io Lb16BI64iUagseIuy94zQKPdEDPqWSJTt5JMTRBqXNi2LR8G8ntpJ1LAmhtdYNK+ xED+uesHYf3CITur085RHWfoMB5v95PMSkHPDtIaALpa+VZqFEfF2B2pG4W2ybkw CYELcUTMtz7C71hiPvFI6oQG2sDj3Zm479C2JMxW4JLCHPtx6H6gIGvEV6TjsGQ/ 3LI4CrgIovLBkoBRfUAi6qA1GPZ1l8aPRVDVvXrkV30jDU2pQD5708kNrcpK3XG7 NP0Bz7No6N1E7QuLrQ5EXqbN6XFcKYPBVheQXBNExNlc8efu9R8R+uA9+KFuLw== =lvvv -----END PGP SIGNATURE----- --------------enig07897D17442F9B3244FF88FB-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 22 13:52:27 2012 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98012106566C; Sat, 22 Sep 2012 13:52:27 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0118FC14; Sat, 22 Sep 2012 13:52:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:dd8:3802:af98:bd60] (unknown [IPv6:2001:7b8:3a7:0:dd8:3802:af98:bd60]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3A4005C59; Sat, 22 Sep 2012 15:52:20 +0200 (CEST) Message-ID: <505DC299.4090407@andric.com> Date: Sat, 22 Sep 2012 15:52:25 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: "O. Hartmann" References: <505CDE9C.3060504@andric.com> <505D6A51.7090808@zedat.fu-berlin.de> <505DA447.40601@andric.com> <505DB49B.1090304@zedat.fu-berlin.de> In-Reply-To: <505DB49B.1090304@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: More kernel performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 13:52:27 -0000 On 2012-09-22 14:52, O. Hartmann wrote: ... > When we used FreeBSD for scientific work, that was around 1998 - 2002, > there were some attempts made to use Intel's icc compiler suite on > FreeBSD in the 32Bit Linuxulator. That time I used that compiler only > for compiling my modelling software, but there where reports of people > made it possible to use the icc compiler also for compiling the FreeBSD > system - with success as far as I know. What happened since then and > more recent days that the sources got "polluted" by those hacks? The Intel compiler support has been largely removed, because it was not maintained. There are still remnants in cdefs.h though, and in theory it could be revived, if there was enough interest. However, Intel simply does not support anything else besides Windows and Linux for its compiler suite, and even on the Linux side you are best off if you use Red Hat or a Red Hat-based distribution such as CentOS or Scientific Linux. Some time ago I attempted to get a fairly recent Intel compiler version working on FreeBSD, but it was very tricky, and I remember I did not get everything working correctly. So unless either Intel starts supporting FreeBSD (or other BSDs), which is very unlikely, or somebody manages to get the Linux version working perfectly as a port, I don't see much sense in restoring the Intel compiler support. > No offense to you, but somehow this sounds that the efford has been > placed in the wrong way since people revert with energy that what has > been hacked with energy ;-) I think you see this incorrectly; when I removed the Intel compiler support from the tree, it was unmaintained for several years already. Apparently there was very little interest for it. ... >> I have already done a few preliminary tests for -march=native, but at >> least for clang, there seems to be no measureable difference in >> performance. The tests for gcc are still running. > > I was wondering if the organisation and amount of cache present in a > modern CPU is not taken into account when optimising code. Our Core2Duo > CPUs still in use do have different architectural features than the more > recent Core-i7 systems. Latter ones have level 3 caches. How does a > compiler take advantage of those features by not given an explicit hint? I don't think the amount of CPU cache, or the number of levels, is taken into account, really. When you select a certain CPU type with -march, the compiler will just enable several features that are supported on that CPU, e.g. MMX, SSE, AVX and so on. It can also enable extra CPU registers, and/or switch to slightly different instruction scheduling. But since we are compiling the kernel with -mno-mmx, -mno-sse and even floating point disabled, apparently there is no real gain from specifying higher CPU types. -Dimitry From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 22 14:34:19 2012 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D24C4106564A; Sat, 22 Sep 2012 14:34:19 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 74B768FC0C; Sat, 22 Sep 2012 14:34:19 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TFQmg-002QyH-5H>; Sat, 22 Sep 2012 16:34:18 +0200 Received: from e178012211.adsl.alicedsl.de ([85.178.12.211] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TFQmf-001y57-WA>; Sat, 22 Sep 2012 16:34:18 +0200 Message-ID: <505DCC64.2010805@zedat.fu-berlin.de> Date: Sat, 22 Sep 2012 16:34:12 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <505CDE9C.3060504@andric.com> <505D6A51.7090808@zedat.fu-berlin.de> <505DA447.40601@andric.com> <505DB49B.1090304@zedat.fu-berlin.de> <505DC299.4090407@andric.com> In-Reply-To: <505DC299.4090407@andric.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7B925003902EC42F78AD1A32" X-Originating-IP: 85.178.12.211 Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: More kernel performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 14:34:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B925003902EC42F78AD1A32 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 09/22/12 15:52, schrieb Dimitry Andric: > On 2012-09-22 14:52, O. Hartmann wrote: > ... >> When we used FreeBSD for scientific work, that was around 1998 - 2002,= >> there were some attempts made to use Intel's icc compiler suite on >> FreeBSD in the 32Bit Linuxulator. That time I used that compiler only >> for compiling my modelling software, but there where reports of people= >> made it possible to use the icc compiler also for compiling the FreeBS= D >> system - with success as far as I know. What happened since then and >> more recent days that the sources got "polluted" by those hacks? >=20 > The Intel compiler support has been largely removed, because it was not= > maintained. There are still remnants in cdefs.h though, and in theory > it could be revived, if there was enough interest. >=20 > However, Intel simply does not support anything else besides Windows an= d > Linux for its compiler suite, and even on the Linux side you are best > off if you use Red Hat or a Red Hat-based distribution such as CentOS o= r > Scientific Linux. >=20 > Some time ago I attempted to get a fairly recent Intel compiler version= > working on FreeBSD, but it was very tricky, and I remember I did not ge= t > everything working correctly. >=20 > So unless either Intel starts supporting FreeBSD (or other BSDs), which= > is very unlikely, or somebody manages to get the Linux version working > perfectly as a port, I don't see much sense in restoring the Intel > compiler support. True. It is use- and senseless, from my point of view, having ancient 32bit support only via the Linuxulator (which is 32bit only). The ICC was only useable on 32bit machines and FBSD 32bit (i386), which isn't any kind of an option nowadays. The same discussion has been triggered with CUDA and Linuxulator. >=20 >=20 >> No offense to you, but somehow this sounds that the efford has been >> placed in the wrong way since people revert with energy that what has >> been hacked with energy ;-) >=20 > I think you see this incorrectly; when I removed the Intel compiler > support from the tree, it was unmaintained for several years already. > Apparently there was very little interest for it. To avoid further misunderstandings - I have no objections cleaning up the sources from unmaintained legacy. Since FreeBSD doesn't have 64Bit Linux support, the effort is wasted energy (my opinion, even if it is sometimes nice to see how it would perform ...). >=20 >=20 > ... >>> I have already done a few preliminary tests for -march=3Dnative, but = at >>> least for clang, there seems to be no measureable difference in >>> performance. The tests for gcc are still running. >> >> I was wondering if the organisation and amount of cache present in a >> modern CPU is not taken into account when optimising code. Our Core2Du= o >> CPUs still in use do have different architectural features than the mo= re >> recent Core-i7 systems. Latter ones have level 3 caches. How does a >> compiler take advantage of those features by not given an explicit hin= t? >=20 > I don't think the amount of CPU cache, or the number of levels, is take= n > into account, really. When you select a certain CPU type with -march, > the compiler will just enable several features that are supported on > that CPU, e.g. MMX, SSE, AVX and so on. It can also enable extra CPU > registers, and/or switch to slightly different instruction scheduling. Well, I'm not that deep into compiler development. I thought that optimizations are also done on the level of caches a CPU has and the size of it. >=20 > But since we are compiling the kernel with -mno-mmx, -mno-sse and even > floating point disabled, apparently there is no real gain from > specifying higher CPU types. I never came deeper into this logic - since I'm no operating system developer. But please correct me and, if possible, enlighten me, if there is something wrong in my understanding. Assumed, the option "-march=3Dnative" is switched on and the only "optimisation" is performed= due to selection of code portions at compile time which are enclosed, say in #ifdef __AVX__ __some__nasty__vector_ops_256bitwide(); #endif which is triggered by the "#define __AVX__" on Core-i7 CPUs with __AVX__ support, why is this explicitely disabled via "-no-avx" and friends? I would assume the developer has a reason not to use those speedy facilities, so I wouldn't expect any portion of #ifdef __AVX__ et cetera in the kernel code. The only explanation, from this naive point of view is, the compiler DOES DO some optimisations regarding the presence of such facilities and the "-no-XXX" options avoid those. Conclusively, I would expect a kind of performance gain when those features are made accessible. On the other hand, why are those features disabled? Intels silica is the reduced to something that gain speed from the clock cycle and the internal bandwidth due to cache sizes and clock speed and, naively spoken, all reduces to something "compatible" from ancients in the past. I can not fathom what the benefit of a Core i7 CPU then is compared to a Core2Duo when all the neat features are not used. A time ago, I read something about a Linux development for malloc(), which also utilises SSE facilities. I have no deeper clue what that development has achieved so far, but when I read the first time about it, they claim having 30% more performance gain over traditional SSE-less= =2E But this is something I do not know much about. >=20 > -Dimitry Oliver --------------enig7B925003902EC42F78AD1A32 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQXcxpAAoJEOgBcD7A/5N8KCoIAMAtybYEGYgNy/38RhW7Nxud PXyT5P8ufDMbGEGRp6PYAAIbHvNQD0dS7/PCIeFDMxkhN3b0IXSuYOz9blq5zk7i vwSshSOhlGOqi3FEFJbzTOeSgrmNoLcyp/HdUjCDcP+MgbXIuj/qTrjJ3ItwLQHm 3EM0UrSsKEdZZYcHMrRkwL/jIXPOI3Jf4rS30xAWXjP3c+DW4PFqgw4Ux+ZYBxi7 JXyMuLJTFlfsosvnJn+7h/90PoOWJT6hT+mKQGIo4TZrcf3a2DnuoHJu9gx/DxaC WCc8zTHgKNE1dNJqWkkQt/5Z7KSckyUfup9XNqHofWoS5YlQuPvRWnMXalm6S1M= =53XY -----END PGP SIGNATURE----- --------------enig7B925003902EC42F78AD1A32-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 22 14:46:57 2012 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 070B6106564A; Sat, 22 Sep 2012 14:46:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id B79BF8FC0A; Sat, 22 Sep 2012 14:46:56 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q8MEkjl1010174; Sat, 22 Sep 2012 07:46:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q8MEkjmB010173; Sat, 22 Sep 2012 07:46:45 -0700 (PDT) (envelope-from sgk) Date: Sat, 22 Sep 2012 07:46:45 -0700 From: Steve Kargl To: Konstantin Belousov Message-ID: <20120922144645.GA10139@troutmask.apl.washington.edu> References: <505CDE9C.3060504@andric.com> <20120922112014.GH37286@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120922112014.GH37286@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: More kernel performance tests on FreeBSD 10.0-CURRENT X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 14:46:57 -0000 On Sat, Sep 22, 2012 at 02:20:14PM +0300, Konstantin Belousov wrote: > On Fri, Sep 21, 2012 at 11:39:40PM +0200, Dimitry Andric wrote: > > Hi all, > > > > As a followup to my previous post about the performance of FreeBSD 10.0 > > kernels compiled with different compilers (clang and gcc), I did another > > series of tests, now on a more modern machine (Core i5-based). I also > > tested the performance with different compiler optimization settings. > > > > The attached text file[1] contains more information about these tests, > > performance data, and my conclusions. Any errors and omissions are also > > my fault, so if you notice them, please let me know. > > > > The executive summary: GENERIC kernels compiled with clang 3.2 are again > > a little faster than those compiled with gcc 4.2.1. For gcc, compiling > > with -O2 also gives a slightly faster kernel than with -O1, but for > > clang there is no measurable difference between those flags. > > > > Again, many thanks to Gavin Atkinson for providing the required > > hardware. > ... > > > Conclusion: > > ----------- > > Kernels compiled with clang are a little faster in real time for building world, > > and in system time the difference is even larger, roughly 10%. For clang, the > > difference between -O1 and -O2 is not measurable, but for gcc, -O2 is slightly > > faster than -O1. > > > > Thank you very much for finishing the initial assessment. > In my opinion, this positively closes the issue of the uncertainicity > of the performance impact of the proposed clang use by default for the > base system. It does not close everything. The kernel does not use floating point. I showed last week that clang may have problems with floating point. -- Steve