From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q32BQBBw001780 for ; Mon, 2 Apr 2012 13:26:12 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUBAGyMeU8SB0QihWdsb2JhbABEuQ4iAQEBCgsLBRYnggkBAQQBeQULC0ZXBogXCLBwiQmRHASpEw X-IronPort-AV: E=Sophos;i="4.75,355,1330902000"; d="scan'208";a="152287411" Received: from dmz-mailsec-scanner-5.mit.edu ([18.7.68.34]) by mail1-smtp-roc.national.inria.fr with ESMTP; 02 Apr 2012 13:26:07 +0200 X-AuditID: 12074422-b7fd66d0000008f9-c3-4f798cce41c8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 52.E7.02297.ECC897F4; Mon, 2 Apr 2012 07:26:06 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q32BQ5ue023630; Mon, 2 Apr 2012 07:26:06 -0400 Received: from localhost (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.9.64.11]) (authenticated bits=0) (User authenticated as jfc@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q32BQ49O018667; Mon, 2 Apr 2012 07:26:05 -0400 (EDT) Message-Id: <201204021126.q32BQ49O018667@outgoing.mit.edu> To: Hans Ole Rafaelsen cc: caml-list@inria.fr In-reply-to: References: <20120401195733.GB15870@annexia.org> Comments: In-reply-to Hans Ole Rafaelsen message dated "Mon, 02 Apr 2012 10:15:02 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Mon, 02 Apr 2012 07:26:04 -0400 From: John Carr X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixG6nonuup9Lf4Mk6cYtPOzawWBzpm8fu wOSxc9Zddo9JLw6xBDBFcdmkpOZklqUW6dslcGWcPL2fteA3W8X3te/YGhhPsnYxcnJICJhI XPzfww5hi0lcuLeerYuRi0NIYB+jxMJlv5khnPWMEiePTYBy/jNKnD4+lQWkhVfASuL0wSY2 EFtEQFdi6YIGMJsZaNSrhw/AxgoL2EisfjodzOYUCJTYsnwRC8SgXYwSjWdagRIcQA0lErff 2UGcoSvxcdFMsHoWAVWJ/1ffgp3KJiAr8ai9i3ECI/8CRoZVjLIpuVW6uYmZOcWpybrFyYl5 ealFuqZ6uZkleqkppZsYwaHkorSD8edBpUOMAhyMSjy8ng8q/IVYE8uKK3MPMUpyMCmJ8vZ1 V/oL8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuFlZgTK8aYkVlalFuXDpKQ5WJTEedW13vkJCaQn lqRmp6YWpBbBZGU4OJQkeL2AMSMkWJSanlqRlplTgpBm4uAEGc4DNFwWpIa3uCAxtzgzHSJ/ ilFRSpxXDSQhAJLIKM2D64XF+itGcaBXhHnNQap4gGkCrvsV0GAmoMGv/paDDC5JREhJNTBG fYnr3LY1bMvR0lblCxlBlkdYDhmoZNyqX3pE2kpe+/Pkkr47TeIqfBHrH5y/5Ltm+WKzQlur WW53NshmbHRgaMj4H34469W/1q5mBgOGH5PmZNT/Y3Ev3Tuvx/VhB7uoZ/jmDc9mrY/eUNP6 aAZjfWWw1e7la125Tuusiw2cFrGCLUxmTpMSS3FGoqEWc1FxIgDQ0Q9s0AIAAA== Subject: Re: [Caml-list] Strategies for finding memory leaks Cache misses count as CPU time. I've seen people measure parallel speedup by looking at CPU usage. They get linear increase in CPU use to eight threads even though the task saturated memory bandwidth after the second thread. If you have a way to measure instruction count you can compare increase in instruction count in GC to increase in time in GC. If instructions are constant while time increases you probably have a memory access problem. If instructions increase the structure of references within your data may be forcing the collector to do more work. > However, the application still consumes more and more CPU time. And it > seems to happen in the GC. Apart from that, the application seems to > be just fine. So it seems to be something in our code (or in LablGTK) > that is making the GC spend more and more time. Anyone experienced > this kind of problem?