Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75626 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86103 invoked from network); 17 Jul 2014 02:17:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jul 2014 02:17:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.180 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 74.125.82.180 mail-we0-f180.google.com Received: from [74.125.82.180] ([74.125.82.180:56726] helo=mail-we0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 26/50-19007-54237C35 for ; Wed, 16 Jul 2014 22:17:41 -0400 Received: by mail-we0-f180.google.com with SMTP id w61so1750266wes.39 for ; Wed, 16 Jul 2014 19:17:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D9R2KLQX58jAXmyh61vgguXgGo+EOtoPBvn0JzC6FRQ=; b=YpVvSI+rEp3szZPemLK/S1c1dbbM/xB11e7V1soX28jIwf6vf3h7b/gzHN4aveuLRe dtf85TFpRoOa/XoT8MNO7bg3PMa71sBPFLgPZFFj2s5Tq0DzT+dbuDF9GYya3+wWK4vm RoGZ+ig/vJ/L0X/V7/MzD7XEgiMVSv1Q7QRzcH1B3gIttWYzJAQcZWKA4nuQqASlaExT gyoHno8DgFCpuz/c/42Bph2szr6IvK6uhdt8DI9iHVVEokC17XMeHCWLov2F4dwkdE78 8Pe+W1T2WzptsUMEglzVk6fIIrsMQAIAh89p9i0mAYatsFi3pQ/8y2rrkNwOP0NqNhGU VKFA== X-Gm-Message-State: ALoCoQn2kVTFvl6EEzgvddxGplAmqPx1KqE9dnZakWPRzhiplGbt4JlKxTr42hFTZibntkCUFEyk MIME-Version: 1.0 X-Received: by 10.194.120.35 with SMTP id kz3mr40850678wjb.38.1405563458355; Wed, 16 Jul 2014 19:17:38 -0700 (PDT) Sender: php@golemon.com Received: by 10.217.57.193 with HTTP; Wed, 16 Jul 2014 19:17:38 -0700 (PDT) X-Originating-IP: [71.198.113.183] In-Reply-To: References: <7646A8D1-69A2-4255-B048-D3B9F28B422F@ajf.me> <37F89E54-C5B9-4E81-9D1B-660190BDB1FF@ajf.me> Date: Wed, 16 Jul 2014 19:17:38 -0700 X-Google-Sender-Auth: GKCO3VilY4DWjnuBkk71YQUijV0 Message-ID: To: Tjerk Meesters Cc: Andrea Faulds , bishop@php.net, PHP internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] intdiv() From: pollita@php.net (Sara Golemon) On Wed, Jul 16, 2014 at 6:51 PM, Tjerk Meesters wrote: > Just out of curiosity, does the compiler optimise it into something like > this? > > if (a % b) { > return a / b; > } else { > return (double)a / b; > } > Ya know what? I feel dumb. FP division is a whole separate instruction. I forgot that (int/int) is always int, even if you're storing in a double. Derp. So yeah, In that code you pasted, you get a single idivq in the int args with no remainder case, but you do have to do a divsd in the remainder exists case. So not as perf neutral as I was thinking. Beneficial in the int case since idivq is less costly than divsd, but the common case may well be ((a%b)!=0), so it's probably harmful more often than not. All that said, *I* think the tradeoff of an extra idivq in the (probably more common) remainder case is worth it in the interest of keeping PHP's syntax simple. If we're really set on adding a new operator, I'd vote for something which provides dividend *and* remainder in some way. (Useful for time arithmetic, for example) -Sara