From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleksandr Gavenko Newsgroups: gmane.emacs.help Subject: Re: Size and length limits for Emacs primitive types and etc data? Date: Tue, 05 Feb 2013 22:04:56 +0200 Organization: Oleksandr Gavenko , http://gavenkoa.users.sf.net Message-ID: <87mwvio7br.fsf@gavenkoa.example.com> References: <87sj5s50vn.fsf@gavenkoa.example.com> <8338xdb42f.fsf@gnu.org> <83r4kw9imv.fsf@gnu.org> <877gmnp064.fsf@gavenkoa.example.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1360094732 6446 80.91.229.3 (5 Feb 2013 20:05:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Feb 2013 20:05:32 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Feb 05 21:05:53 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U2om8-0003vd-CK for geh-help-gnu-emacs@m.gmane.org; Tue, 05 Feb 2013 21:05:52 +0100 Original-Received: from localhost ([::1]:53591 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2olp-0002Jf-LL for geh-help-gnu-emacs@m.gmane.org; Tue, 05 Feb 2013 15:05:33 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2olc-0002IW-Gx for help-gnu-emacs@gnu.org; Tue, 05 Feb 2013 15:05:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2olY-00081I-SV for help-gnu-emacs@gnu.org; Tue, 05 Feb 2013 15:05:20 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:60082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2olY-0007xq-L9 for help-gnu-emacs@gnu.org; Tue, 05 Feb 2013 15:05:16 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U2olj-0003eP-Nx for help-gnu-emacs@gnu.org; Tue, 05 Feb 2013 21:05:27 +0100 Original-Received: from 37.229.4.200 ([37.229.4.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Feb 2013 21:05:27 +0100 Original-Received: from gavenkoa by 37.229.4.200 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Feb 2013 21:05:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 37.229.4.200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:Z1LplrCkUxazOIVVbMqe0VVg/8A= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:88969 Archived-At: On 2013-02-05, Burton Samograd wrote: > Eli Zaretskii writes: > >>> I think linked nature of elisp data structure cause very high rate of CPU >>> cache miss (but I don't actually run any AMD/Intel CPU profilers). >> >> Prove it. > I don't familiar with appropriated CPU profilers: http://developer.amd.com/tools/heterogeneous-computing/amd-codeanalyst-performance-analyzer/ CodeAnalyst Performance Analyzer http://developer.amd.com/tools/heterogeneous-computing/codexl/ GPU debugging, comprehensive GPU and CPU profiling, and static OpenCL™ kernel analysis capabilities http://software.intel.com/en-us/intel-vtune-amplifier-xe Intel® VTune™ Amplifier XE 2013 is the premier profiler for C, C++, C#, Fortran, Assembly and Java. Main reason that it is hard to interpret right what they show (modern CPU have too complicate execution architecture). > Here's an analysis of cache misses with pointer based data structures > (linked list and trees): > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.9669 > > It's common knowledge that linked lists are not cache friendly, leading > to creation of structures like Unrolled Linked Lists > (http://en.wikipedia.org/wiki/Unrolled_linked_list) to help. > I work with Isabelle proof assistant (written in ML) on my old laptop with 512 MiB of RAM (in 64-bit userspace). On large theories my laptop froze on disk (swap) operations. While non-functional programs like Firefox and OpenOffice operated with minor slowness in IU when out of 512 MiB. It is possible to say that I run into 100% RAM misses!! After installing additional memory module (up to 1 GiB) any disk operation go away on those large theories! Also interesting result we get when work on optimisation of GOST cipher. It have permutation table and in order to increase speed we expand this table. Usually larger precomputation give better performance... but in our case as soon table out of CPU cache we lose speed in 2 or more times... Deduce from theoretical positions (look to Burton Samograd link) it is possible frequently cache misses in Elisp. As I don't know GNU Emacs internals I ask about Elisp and CPU cache misses... -- Best regards!