220 41381 article Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Optimizing Power Function for Integral Types Date: Tue, 22 Jan 2019 12:52:39 -0500 Approved: news@gmane.org Message-ID: References: <1d2bd16a-c2f9-4baa-b2d3-4b0241de8992@isocpp.org> <7801bc16-e087-43ed-ab4f-5b5f907c125f@isocpp.org> Reply-To: std-proposals@isocpp.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d94f3f05800fa4c0" Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="63752"; mail-complaints-to="usenet@ciao.gmane.org" To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDLZJYWNDQIOXME54ICRUBBFCPMHS@isocpp.org Tue Jan 22 18:52:47 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr1-f72.google.com ([209.85.221.72]) by ciao.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gm0E9-000GRW-J2 for gclcip-std-proposals@m.gmane.org; Tue, 22 Jan 2019 18:52:45 +0100 Original-Received: by mail-wr1-f72.google.com with SMTP id m4sf12798695wrr.4 for ; Tue, 22 Jan 2019 09:52:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1548179564; cv=pass; d=google.com; s=arc-20160816; b=Y4545nci/5LZRd7+pcdaypOWBIHB7wh/VnBCPETcUTV5tWg9EmmSRuTas/b12o/QGM XWC28C9/QX2vCLvPlpT0t2qX7z8wU5RTvJFrTQje4njIQG99tGFS9A8yDaY30rCL93O+ JyM8gmmlW+6Cj+IWWyWlIfCHKoQWwlQOEv0hmUo1fMhOGrY6Be3BH30s4CVK0Jq27aJD 3oWqSoPOiNGSBI0nwII/fVVJGDG6fGIYSiysDwagl37qOwvvgkUPH6glkjxKKoM9Bdox 7PiTWH2IXdAYqyGAgRMZwpOE7HCaiC6A9EwdgGs5QLMKlatW+yj7kf79IOiHzRzxm2cV aOqw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=xcR1uS+RHiTWcVw7Tu2mmWAXIGIEmc9RjPQYey++8rA=; b=diyikFVczpM9HNEOMS3g6v3207g7ck8GFthib2Ru49HlBhiKqSebSY4FJlmvzhHa/N 0zOzFvEcb+unLZzT7VSQj/iNVHahmrc+iAZyG1EkDF7oi09KEHXTmXn5bASm3Pcqxe8r d6XVvO3Ml7EdrWAbBBF4jfWcpbrGRVO2SufNsJdYJWgfEdFaTisOl431EVG94UVvP7aH vhZ5/jvnlomDpoMcBCyvPrLZHY6vj2Hn3Zvfq9Tt7gYFFQnkyWswTh0dw3ENdAtixL8K yXTkXiXHLKDRU5teXscimnZkRYHNfMBB+/TQwRa3OU2IkiRLUWeyw9yAMNogK+1PnuEN Hkmg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dVc1nXcx; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=xcR1uS+RHiTWcVw7Tu2mmWAXIGIEmc9RjPQYey++8rA=; b=whAIT6yCehOEnoPASVbqEUuUx/2+ARbPGUfOBha3UjE+6toDMy7WtocHiTfBAi7t6c 2fXUjhkzOp76IVI4dxeR0LtUt55SaXf7hqVEbyzYwc+nVwOZk3P78TosAwcZmIKQDS3A njvPqRh1/yZy6tjW7HopaIrRJ4YkPo4CRO8zJIDBMs0yjvoBBRfIn9pBzX36Odbb+ScV 0ttIO/crWswOZooHrK3IeqgilicQxOOljhGI9gqoUYQFfQZAkMGeSKI61ihzZ1Aa8xh3 1y7dG1VNnqmLzOme8N0xfiJnjVnbexmQnEQvNxlSOJMdSxsXclswjryq3VYw2v0CZIm/ WnWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=xcR1uS+RHiTWcVw7Tu2mmWAXIGIEmc9RjPQYey++8rA=; b=WOOCp4Qjy9cKpLia/E9U1OlCVshiS4BiFnrLSDbiuvBlIuGPG/GaStWncoLv9vmW/F y8HL8+wUXpEInsR4PVseOfJiTdJYAYFyQg8OuuT6mQbSxM2f7XguV/EOrDMAneUsvPyO ZasUs6HAQStQLIqa9RhYlmgpuyB65E2gUZFYrUc/tLZC8a1Ki6en/TJ1YqyI18e+ySr2 mJbGbDMsotub29z+U5W077HZcGQG+R2zaInDMJ1lRX4cdZBS4Q+ij06y9PF3t5xJCnxY HAywnDvqPhFP7HxExaK1+jJIgKr8SzaNJfMHSYlqCQoHmhswx7cTRwREYp8iyUPuwlRI +/Sw== X-Gm-Message-State: AJcUukf8Yc6xec78Yont45UZAEkqmvO6i7CX0jNm0xnJ+pDisxjg3QqP YkZYjRTVzHAt2UierqBaVT+ICw== X-Google-Smtp-Source: ALg8bN4Ih4LW5WlnFzAuk5bIOg23j3qNzRW9zgFeg8hJoiCctLfYR5jw5Q/CxAfKfT/MXq8gdbiZ3w== X-Received: by 2002:a1c:6708:: with SMTP id b8mr174351wmc.5.1548179564697; Tue, 22 Jan 2019 09:52:44 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:adf:dc8e:: with SMTP id r14ls5651384wrj.2.gmail; Tue, 22 Jan 2019 09:52:43 -0800 (PST) X-Received: by 2002:adf:c042:: with SMTP id c2mr35087562wrf.158.1548179563005; Tue, 22 Jan 2019 09:52:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548179563; cv=none; d=google.com; s=arc-20160816; b=OoLEZNAjfiaYqiJeYB25hVRafq522f/JFXVJ0bPxMQeLKZDLdvPka++Qtv4P8k50xb BD3yrjvIeCum0UAKHX+4xX2Y8bJNXUtNt5g1pScsbjLt1MXF/blGPdFP+uI4WnpSCsvg 6Fh0oDzGkaLSUguSsSSQVlz+z78MEv2YficBGW7GEqtCI6fgLrwvrG6CJRHiroxwSfXF BIro6wHSpve97sLABCzzvQldTmXJBwYf/opzJf2aTPm5qD0A6KFD7IHrCwF0G8rLz/Zs 68CaCN+yXuCEtD5Nx6bPCaKF294JpyMIDEU+fRfT4WOiTgx+TeDDlyHN7aKZNcz9vHhH E4cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=11TXMEGG3mTb12ED+0NAuB4I7DbQY4mrURoQ30VEhbs=; b=KIXHUaEFXPGgmZLW6m7HkV39ZLbsfBU2I/mSQptuVEpXzlhqh/BDmXY5O+9Vyjjf1h 7FAZFIxEEf4LXSlvip3jbnnbeteVaYJobiVnWWO1czopTk5mOfStKd0peIPS5qyRDG7Y fj84can4F6/FpZ++eocTKjEJuVzLcukTAI5L0xnayjz01v00UmjDBBzWhtSmrxr6befN Os9p07A6MuuBfz80kBpAwNxAPhTVjbANwbfk1wybn7oe6id0kz297GKuViulwtQKxIVp bLn5NTM62iPoVzdRZmcnN8gCsEB1mTNCzqOQGUtZH61U7iPVo3CcT+AmslL0C61L+Hed leIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dVc1nXcx; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 69sor34303465wmy.3.2019.01.22.09.52.42 for (Google Transport Security); Tue, 22 Jan 2019 09:52:42 -0800 (PST) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a1c:bdc5:: with SMTP id n188mr4957826wmf.69.1548179562121; Tue, 22 Jan 2019 09:52:42 -0800 (PST) In-Reply-To: <7801bc16-e087-43ed-ab4f-5b5f907c125f@isocpp.org> X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dVc1nXcx; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41381 Archived-At: --000000000000d94f3f05800fa4c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why don't you just post your benchmark code? Why all the graphs and "oops here's the new graph" and so on? On Tue, Jan 22, 2019 at 12:51 PM wrote: > I wasn't aware of Google Benchmark before now. I will attempt to > familiarize myself with it, so that I can get more accurate timings. In t= he > meanwhile, below is my implementation of what I hope to propose. If the > results from Google Benchmark don't align with what I have presented, I > sincerely apologize for the misinformation. > > __declspec(naked) __int32 __fastcall powi(__int32 base, __int32 exponent) > { > __asm { > // No Stack Usage > /*------- Prolog ---------*/ > //push ebp > //mov ebp, esp > //sub esp, __LOCAL_SIZE > /*------------------------*/ > > > // Entry Register Values > //------------------------ > // EAX =3D UNDEFINED > // EBX =3D UNDEFINED > // ECX =3D base > // EDX =3D exponent > // ESI =3D UNDEFINED > // EDI =3D UNDEFINED > //------------------------ > > > // eax =3D 0 > xor eax, eax; > > > // if(exponent =3D=3D 0) { return 1; } > test edx, edx; > jnz if_zero_exp; > inc eax; // Set eax to 1 > jmp powi_exit; > if_zero_exp: > > // if(base =3D=3D 0) { return 0; } > test ecx, ecx; > jz powi_exit; > > > // ebx =3D base > // ecx =3D exponent > mov ebx, ecx; > mov ecx, edx; > > > > // ecx =3D abs(exponent) > // edx =3D sign(exponent) > sar edx, 31; > xor ecx, edx; > sub ecx, edx; > > > // Create a copy of the base, and move it to a temporary register > mov esi, ebx; > > /* find abs(base) */ > mov eax, ebx; // Copy the base to the accumulator > sar eax, 31; // Fill with sign bit > xor ebx, eax; // Not the value, if sign bit is set > sub ebx, eax; // Subtract the sign bit, giving the absolute value > > // Return the copy to the accumulator > mov eax, esi; > > > // EAX =3D base > // EBX =3D abs(base) > // ECX =3D abs(exponent) > // EDX =3D sign(exponent) > > > // if exponent is negative > /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D*/ > test edx, edx; > jz if_exp_sign_eq_0; > > > // if abs(base) =3D=3D 1 > /*----------------------------*/ > cmp ebx, 1; > jg if_base_gt_1; > // ecx =3D exponent & 1 > and ecx, ebx; > > // eax =3D exponent & 1 ? (base < 0 ? -1 : 1) : 0 > imul ecx; > > > // ecx =3D exponent & 1 ? 0 : 1 > xor ecx, ebx; > > > // eax =3D exponent & 1 ? (base < 0 ? -1 : 1) : 1 > add eax, ecx; > > > // Return exponent & 1 ? (base < 0 ? -1 : 1) : 1 > jmp powi_exit; > if_base_gt_1: > /*----------------------------*/ > > // Return 0 > xor eax, eax; > jmp powi_exit; > > > if_exp_sign_eq_0: > /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D*/ > > > /* if exponent =3D=3D 1, return base */ > dec ecx; > jz powi_exit; > > > // If base =3D=3D 2 > //cmp ebx, 2; > //jne if_base_2; > // sal eax, cl; > // ret; > //if_base_2: > > > /* Exponentiate the multiplication */ > mov ebx, eax; > multiply: > shr ecx, 1; // Shift and check the first bit of the loop counter > jnc noMulByEBX > imul ebx; // Multiply by the current multiplier > noMulByEBX: > imul ebx, ebx; // Square the multiplier > test ecx, ecx; // Test if this was the last itteration > jnz multiply; > > > /* Exit the function, returning the value of eax */ > powi_exit : > // No stack usage > /*------- Epilog ---------*/ > //mov esp, ebp; > //pop ebp; > /*------------------------*/ > ret; > } > } > > > On Friday, January 18, 2019 at 10:59:21 PM UTC-8, Arthur O'Dwyer wrote: >> >> On Fri, Jan 18, 2019 at 8:12 PM wrote: >> >>> The case you pointed out of using the double-type of the return for >>> 'pow(int, int)' would be a major concern. Perhaps a workaround would be= the >>> requirement of an explicit template? i.e. "double x =3D std::pow(10, 20= );" >>> would use overload 7, whereas "std::pow(10, 20)" would return >>> int? Alternatively, as Jake Arkinstall suggested, a new syntax for 'pow= ' as >>> 'power' might be in order, in which case, such contingencies wouldn't b= e as >>> large a concern. I would also argue that the above code segment is poor >>> practice, as it is relying upon the pow function to convert the two >>> integers to doubles. More explicit typing would be preferred in most co= ding >>> environments. Another solution, as is implemented with powl and powf, i= s to >>> use a single-letter abbreviation to explicitly define the types used. i= ..e. >>> powi. >>> >>> As for the graph; I mentioned in a reply to my original posting that I >>> have since found an issue with the testing method I used for graphing t= he >>> execution times for pow and powi. I have since done other tests as show= n >>> below [avg. of 20000 runs for powi, and 500 for pow (since the executio= n is >>> longer, I decided to neglect the sample-count somewhat)]: >>> >>> [image: Untitled2.png] >>> >>> As you can see, powi does experience a gradual increase in execution >>> length with the increasing exponents (since it needs to do at worst [if= an >>> implementation were to use a simple linear approach, O(n) multiplicatio= ns]). >>> >> But really O(lg n) multiplications, right? >> That graph looks a lot better (flatter), but I'd still have to see the >> code before I believe it. You say your data was >> >> > gathered using "std::chrono::high_resolution_clock::now()" surrounding >> for-loops executing the functions >> >> which pointedly omits any reference to e.g. Google Benchmark >> or ClobberMemory/DoNotOptimize. >> Which suggests that your benchmark might not have been measuring anythin= g >> meaningful. >> >> =E2=80=93Arthur >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/y9qMRNKrS2E/= unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7801bc16-e08= 7-43ed-ab4f-5b5f907c125f%40isocpp.org > > . > --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CADvuK0%2B1ZC60c%2B9ScSKNtu2id34E6wVnXzQ7WP61cKh= u%2BeYARg%40mail.gmail.com. --000000000000d94f3f05800fa4c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why don't you just post your benchmark code? Why all t= he graphs and "oops here's the new graph" and so on?
On Tue, J= an 22, 2019 at 12:51 PM <jo= el.g.hemphill@gmail.com> wrote:
I wasn't aware of Google Benchmark before now. I will attempt = to familiarize myself with it, so that I can get more accurate timings. In = the meanwhile, below is my implementation of what I hope to propose. If the= results from Google Benchmark don't align with what I have presented, = I sincerely apologize for the misinformation.

__declspec(naked) __int32 _= _fastcall powi(__int32 base,= __int32 exponent) <= span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-1637743423785989120st= yled-by-prettify">{
=C2=A0 __asm {
=C2=A0 // No St= ack Usage
=C2=A0 /*-------= Prolog ---------*/
=C2=A0 //push ebp
=C2=A0 //mov e= bp, esp
=C2=A0 //sub esp, = __LOCAL_SIZE
=C2=A0 /*----= --------------------*/


=C2=A0 // Entry Register Values
=C2=A0 //------------------------
=C2= =A0 // EAX =3D UNDEFINED
= =C2=A0 // EBX =3D UNDEFINED=C2=A0 // ECX =3D base
= =C2=A0 // EDX =3D exponent=C2=A0 // ESI =3D UNDEFINED<= br>=C2=A0 // EDI =3D UNDEFINED
=C2=A0 //------------------------


=C2=A0 // eax =3D 0
=C2=A0 xor eax, eax;


=C2=A0= // if(exponent =3D=3D 0) { return 1; }
=C2=A0 test edx, edx;
=C2=A0 jnz if_= zero_exp;
=C2=A0 inc eax= ; /= / Set eax to 1
=C2=A0 jmp powi_exit;
if_zero_exp= :
=C2=A0
=C2=A0 // if(b= ase =3D=3D 0) { return 0; }
=C2=A0 test ecx= , ecx;
=C2=A0 jz powi_exit;


=C2=A0 // ebx =3D base=
=C2=A0 // ecx =3D exponen= t
=C2=A0 mov ebx,= ecx;
=C2= =A0 mov ecx, edx;


=C2=A0
=C2=A0 <= span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-1637743423785989120styl= ed-by-prettify">// ecx =3D abs(exponent)
=C2=A0 // edx =3D sign(exponent)
= =C2=A0 sar edx, 31;
=C2= =A0 xor ecx, edx;
=C2=A0 su= b ecx, edx;


=C2=A0 // Create a copy of the base, and move it to a tempor= ary register
=C2=A0 mov esi, ebx;
=C2=A0
=C2=A0 /* find abs(base) */
=C2=A0 mov eax, ebx; // Copy the base to the accumulator
=C2= =A0 sar eax, 31; =C2=A0// Fill with sign bit
=C2=A0 xo= r ebx, eax; // Not the value, = if sign bit is set
=C2=A0 = sub ebx, eax; // Subtract the sign bit, giving the absolute value
=C2=A0
=C2=A0 // Return the copy to t= he accumulator
=C2=A0 mov eax, esi;


=C2=A0 // EAX =3D base
=C2=A0 // EBX =3D abs(base)
=C2=A0 // ECX =3D abs(exponent)
=C2=A0 // EDX =3D sign(expon= ent)


=C2=A0 // if = exponent is negative
=C2=A0 /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D*/
=C2=A0 test edx, edx= ;
=C2=A0 jz if_exp_sign_eq_0;


=C2=A0 // if= abs(base) =3D=3D 1
=C2=A0 /*----------------------------*/
=C2=A0 cmp ebx, 1= ;
=C2=A0 jg if_base_gt_1= ;
=C2=A0 // ecx =3D exponent & 1
=C2=A0 and ecx,<= /span> ebx;=
=C2=A0
=C2=A0 // eax =3D exponent & 1 ? = (base < 0 ? -1 : 1) : 0
=C2=A0 imul ecx<= span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-1637743423785989120st= yled-by-prettify">;


=C2=A0 // ecx =3D exponent & 1 ? 0 : 1
=C2= =A0 xor ecx, ebx;


=C2=A0 // eax =3D exponent & 1 ? (base < 0 ? -1 : 1) : 1
=C2=A0 add eax, ecx;


=C2=A0 // Return exponent & 1 ? (base < 0 ? -1 : 1) := 1
=C2=A0 jmp powi_exit;=
if_base_gt_1:
=C2=A0 /*--------------------------= --*/
=C2=A0
=C2=A0 // R= eturn 0
=C2=A0 xor eax,<= /span> eax;=
=C2=A0 jmp powi_exit;=


if_exp_sign_eq_0:
=C2=A0 /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/


=C2=A0 /* if exponent =3D= =3D 1, return base */
=C2=A0 dec ecx;
=C2=A0 jz powi_exit;


=C2=A0 = // If base =3D=3D 2
=C2=A0 //cmp ebx, 2;
=C2=A0 //jn= e if_base_2;
=C2=A0 // sal= eax, cl;
=C2=A0 // ret;
=C2=A0 //if_base_2:<= span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-1637743423785989120styled= -by-prettify">


=C2=A0 /* Exponentiate th= e multiplication */
=C2=A0 mov ebx, eax;
multiply:=C2=A0 shr ecx, 1; =C2=A0 = =C2=A0// Shift and check the first bit of the loop = counter
=C2=A0 jnc noMulByEBX
=C2=A0 imul ebx; =C2=A0// Multiply by the current multiplier
noMulByEB= X:
=C2=A0 imul ebx, ebx= ; // Square the multiplier
=C2=A0 test ecx, ecx; // Test if this was the last itteration
=C2=A0 jnz multiply;=


=C2=A0 /* Exit the function, returning = the value of eax */
powi_exit :
=C2=A0 // No sta= ck usage
=C2=A0 /*------- = Epilog ---------*/
=C2=A0 = //mov esp, ebp;
=C2=A0 //p= op ebp;
=C2=A0 /*---------= ---------------*/
=C2=A0 ret;
=C2=A0 }
}


On Friday, January 18, 2019 at 10:59:21 PM UTC-= 8, Arthur O'Dwyer wrote:
On Fri, Jan 18, 2019 at 8:12 PM <joel.g....@gmai= l.com> wrote:
=
The case you pointed out of using the double-type of the r= eturn for 'pow(int, int)' would be a major concern. Perhaps a worka= round would be the requirement of an explicit template? i.e. "double x= =3D std::pow(10, 20);" would use overload 7, whereas "std::pow&l= t;int, int>(10, 20)" would return int? Alternatively, as Jake Arkin= stall suggested, a new syntax for 'pow' as 'power' might be= in order, in which case, such contingencies wouldn't be as large a con= cern. I would also argue that the above code segment is poor practice, as i= t is relying upon the pow function to convert the two integers to doubles. = More explicit typing would be preferred in most coding environments. Anothe= r solution, as is implemented with powl and powf, is to use a single-letter= abbreviation to explicitly define the types used. i.e. powi.

As for the graph; I mentioned in a reply to my original posting that = I have since found an issue with the testing method I used for graphing the= execution times for pow and powi. I have since done other tests as shown b= elow [avg. of 20000 runs for powi, and 500 for pow (since the execution is = longer, I decided to neglect the sample-count somewhat)]:

3D"Untitled2.png"

As you can see, powi does experience a gr= adual increase in execution length with the increasing exponents (since it = needs to do at worst [if an implementation were to use a simple linear appr= oach, O(n) multiplications]).

But really O(l= g n) multiplications, right?
That graph looks a lot better (flatt= er), but I'd still have to see the code before I believe it. You say yo= ur data was

> gathered using "std::chrono:= :high_resolution_clock::now()" surrounding for-loops executing the fun= ctions

which pointedly omits any reference to e.g.= Google Benchmark or ClobberMemory/DoNotOptimize. Which suggest= s that your benchmark might not have been measuring anything meaningful.

=E2=80=93Arthur

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/y9qMRNKrS2E= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit = https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7801bc16-e087-= 43ed-ab4f-5b5f907c125f%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B1= ZC60c%2B9ScSKNtu2id34E6wVnXzQ7WP61cKhu%2BeYARg%40mail.gmail.com.
--000000000000d94f3f05800fa4c0-- .