From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12749 invoked by alias); 26 Jan 2014 07:50:43 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 12739 invoked by uid 89); 26 Jan 2014 07:50:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: na3sys009aog107.obsmtp.com Received: from na3sys009aog107.obsmtp.com (HELO na3sys009aog107.obsmtp.com) (74.125.149.197) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Sun, 26 Jan 2014 07:50:40 +0000 Received: from mail-lb0-f175.google.com ([209.85.217.175]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUuS+TjuJhzpli/rIMbW0yc78VQdpj0uJ@postini.com; Sat, 25 Jan 2014 23:50:40 PST Received: by mail-lb0-f175.google.com with SMTP id p9so3648809lbv.34 for ; Sat, 25 Jan 2014 23:50:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=ZusGuqaKI486XrFxSDp/poUskqIK1+eJ/kMY5w31+ug=; b=jL8r1evX1nugQ+Uog/dsiXzKmfSXWYZbqjeml3JoVve3tQqJPfH0hU499+z6L/aOMK Y4SfiVb/+kA52njDmshdMX7mKwMfJIc/iOPWoRrqyMcrJFtk3AJhK/X8rR3T4hDNHyWq YEmu9TImQdSdxj0RNGMVqTFUGWsd4aKAM2FeXFWQwyZRDiOi2m04N79XztES2piDbobc 28eBkCLfgJcjdxPah+9xoaZcdZcU8DV4JN/3OLD+KNzIlgfzN9jCPreUqP/042SHoBRw 1frKLBCiWhM9ndpIFcJwinT+uKiWVys4CpHgCVPg0fiD8PQ+S892F9Q2FT9VC/lgVQRm HHZw== X-Gm-Message-State: ALoCoQkV4dZzoI5iq6iSwE+iicxdrOf3+eesSFT4+uJEjL+zvEY0pLRSeUOPzorTYWXAeYY8M2oLGXxNAkxPdFIBCul7NbfMGIpouQbPm+L1chwzd646UqUAMyqJvHIJpoTTif/C44uqsvdOWR3zHrzL6sG2Iyprsw== X-Received: by 10.153.0.33 with SMTP id av1mr8805487lad.14.1390722636966; Sat, 25 Jan 2014 23:50:36 -0800 (PST) X-Received: by 10.153.0.33 with SMTP id av1mr8805475lad.14.1390722636635; Sat, 25 Jan 2014 23:50:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.69.200 with HTTP; Sat, 25 Jan 2014 23:50:16 -0800 (PST) From: Keith Erickson Date: Sun, 26 Jan 2014 07:50:00 -0000 Message-ID: Subject: Why does std::chrono now() uses slow syscall? To: gcc-help Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2014-01/txt/msg00092.txt.bz2 When I do this: #include #include using Clk = std::chrono::high_resolution_clock; int main() { auto t1 = Clk::now(); auto t2 = Clk::now(); std::cout << "Chrono: " << (t2-t1).count() << "ns" << std::endl; } I get results of about 1.5us to do the clock operations. When I do the same thing in C using clock_gettime, it's on the order of 250ns. When I run the above code on ideone.com, I get the expected C time of about 250ns. I traced this down to the fact that my version of chrono.cc got compiled with _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL defined, and so I was using the absurdly slow syscall to get time instead of the very fast clock_gettime(). My questions, then, are.... why would I ever want to use the syscall version? It seems that configure prefers it, and will use it if it's available. But it's stupidly slow, even on the fasted server CPU that AMD sells (Opteron 6386 SE at the time of this writing). How do I not use this slow method? Do I have to compile gcc specially? What are the drawbacks to forcing configure to not set that #define? Is there an approved way to tell configure to use a fast time?