Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Chris Angelico Newsgroups: comp.lang.python Subject: Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Date: Sun, 13 Mar 2016 02:30:45 +1100 Lines: 33 Message-ID: References: <87h9gcxkd3.fsf@elektro.pacujo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: news.uni-berlin.de sM0WUBZHUKsxJ4iHlFp5XgYeliyUwcER2f3nraR7zM5A== Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.008 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'received:209.85.223': 0.03; 'cc:addr:python-list': 0.09; 'lost.': 0.09; 'subject:which': 0.09; 'python': 0.10; "'long'": 0.16; "(i'm": 0.16; '2016': 0.16; 'comparisons,': 0.16; 'compilers': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'integers,': 0.16; 'operation,': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'subject:?)': 0.16; 'wrote:': 0.16; 'string': 0.17; 'comparing': 0.18; 'integer': 0.18; 'language': 0.19; 'cc:2**0': 0.20; 'cc:addr:python.org': 0.20; 'machine': 0.21; 'trying': 0.22; 'am,': 0.23; 'code,': 0.23; 'header:In-Reply-To:1': 0.24; "i've": 0.25; "doesn't": 0.26; 'message-id:@mail.gmail.com': 0.27; '13,': 0.29; 'assembly': 0.29; 'that.': 0.30; 'guess': 0.31; 'operations': 0.31; 'especially': 0.32; 'maybe': 0.33; 'received:google.com': 0.35; 'could': 0.35; 'happened': 0.35; 'stopped': 0.35; 'something': 0.35; 'but': 0.36; 'instead': 0.36; 'there': 0.36; 'received:209.85': 0.36; '(and': 0.36; 'faster': 0.36; 'subject:: ': 0.37; 'difference': 0.38; 'received:209': 0.38; 'why': 0.39; 'sure': 0.39; 'rather': 0.39; 'where': 0.40; 'subject:The': 0.61; 'relationship': 0.61; 'show': 0.62; 'here.': 0.62; 'making': 0.62; 'different': 0.63; 'between': 0.65; 'mar': 0.65; "they're": 0.66; '10%': 0.72; 'funny': 0.83; 'benchmark': 0.84; 'chrisa': 0.84; 'to:none': 0.91 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:cc; bh=VG0akJd53SNhp9GTVfE6ZZAYyi40gnL1sDAguD19KFo=; b=n/PnxjPigXFJHlpDFT5O19LjwUiM6t2smBiaee3r6B1sx0BZ5Q/4AKvakJ0fEQpGQL xGUOVKhtaWyFQs+XRHw80QhrCvnorVqy4gFUNjCez9bLCi4OXxj5LUxex7uDPHDlShzX rK+8Q8wxNPZyp5rEwOhYIMlXIlxWJW3YgtvObzMKOit7GGkjDxqriHT/I9ijsnOwccMu zampytkEOCnwJ9jiG10nFqAz2ggEbY1B/8Nhr6KA+sWPz6hT06XrCkC1PMeNd1baijcQ 8+V58K5AnWozjRe0sRlzQR5QevIkxZIu4k4wQRfLmAmwMlVIeyXvfJ8T5bbzfb6lEEdZ c9sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc; bh=VG0akJd53SNhp9GTVfE6ZZAYyi40gnL1sDAguD19KFo=; b=cKiYDHkws7QPDDJK5nnhrX/G5c8rOsEIQq+Qb+TDyo72hq+I3wsIrnX3cZxyGJ8MXF I7JWADXO/lzjkccltoI3HqlPJ8H4wvCN+q9Mfy6MdYgEHQmgKR3u5Z/MCFGX1iFyqHUV rdB3dfaFjGCfHRxoFvBlMb99xy1qdvMor42UnSGa8EjpG20maUGE4hc/dJcvefIXttq3 +0M4Y3juf3DMj0odwioMuJkoMSIe8bbEoOtZKDRCDhwaM8voBZmScikWI7E0NrOhYaV4 5nz9gMkrjQ++mcUeGlwE4DKYm7uL1jkZYYekkmcgLLFXJYYE6hRvi9epzG2ILjvSUHZE B24g== X-Gm-Message-State: AD7BkJKYunR9COdYxlkl2mPLmJiBC7nLcWq1CiT/EJqpb+KuDlN90h9Cnx3JbLkFk218ejr4nXHxyIIL6B8ZvA== X-Received: by 10.107.47.163 with SMTP id v35mr15368193iov.19.1457796645969; Sat, 12 Mar 2016 07:30:45 -0800 (PST) In-Reply-To: X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com comp.lang.python:104710 On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote: > That explains why you rarely use integers, if you prefer to use strings even > when there is a choice! > > However, I was going to revise my benchmark to use strings instead of > integers, to show how much slower they would be. But the program was 10% > faster with strings! > > I don't know what to make of that. Clearly comparing an integer with an > integer is a very fast operation, or ought to be, while comparing strings is > much less efficient at machine level. > > So there's something funny going on. Either string operations are super-fast > or integer operations are somehow crippled. Or maybe there so many other > overheads, that the difference between strings and ints is lost. > > That doesn't explain why ints are slower though (and this was the case even > on Python 2 where the 'long' type is not involved). Or maybe they're all actually *object* comparisons, and what you know about assembly language has no relationship to what's going on here. This is why we keep advising you to get to know *Python*, rather than trying to use it as "assembly language with different syntax", especially when you start making performance estimates. Even with C code, I've stopped trying to predict what performance will be. (I'm not sure whether I could guess at assembly language performance; I stopped writing any at all when C compilers got provably better than me in all circumstances - which happened a good while ago.) The ONLY way to know whether X is faster than Y is to try them both. ChrisA