Math.clz()

Oliver Hunt oliver at apple.com
Sun Mar 4 13:50:16 PST 2012


It's worth noting that even "high performance" languages like C don't have clz, etc builtin - people still have to drop down to assembly to implement them.  If you really wanted to you could just use the standard bit fiddling techniques, and if necessary JS engines would start optimising those specific patterns (I say this based on the various other inane things that we've all optimised over time *sigh*)

--Oliver

On Mar 4, 2012, at 12:23 PM, Mark S. Miller wrote:

> Please don't take my message as an endorsement that these operations should be standardized at all, under any name. I do not yet have an opinion about that.
> 
> On Sun, Mar 4, 2012 at 12:22 PM, Mark S. Miller <erights at google.com> wrote:
> It seems very strange to me to have a "clz" and "getOwnPropertyDescriptor" coexist as naming choices in the same language. I have taken to doing
> 
>     var gopd = Object.getOwnPropertyDescriptor;
> 
> early in many of my source files. I think this is better than standardizing an obscure acronym. This way, for every file that "clz" or "gopd" appears in, there's a declaration at the beginning stating the correspondence with a name whose meaning is easier to guess. This practice becomes even better supported by our new module system's import-with-renaming.
> 
> Let's keep exported names clear. Let's abbreviate if necessary on import.
> 
> 
> On Sun, Mar 4, 2012 at 1:38 AM, Jussi Kalliokoski <jussi.kalliokoski at gmail.com> wrote:
> Bit.clz() sounds just as good to me. I don't know if they need to be less cryptic, if someone doesn't know the abbreviation, it is highly likely (s)he doesn't need the functions either. :)
> 
> 
> On Sun, Mar 4, 2012 at 10:01 AM, Tomas Carnecky <tomc at caurea.org> wrote:
> Wouldn't it be better to namespace these bit-operators in a different module?
> Bit.clz() perhaps? The Math module is getting a bit crowded.
> 
> On Sat, 03 Mar 2012 23:21:11 -0800, Brendan Eich <brendan at mozilla.org> wrote:
> > I'm open to clz/clo. The names perhaps need to be less cryptic... or not.
> >
> > Allen should weigh in.
> >
> > /be
> >
> > Jussi Kalliokoski wrote:
> > > We're working on JS audio decoders, and one huge performance issue atm
> > > is clz() [count leading zeroes], which is a very commonly used
> > > algorithm in decoders. We've tried several different approaches and
> > > benchmarked them [1], however, different approaches work better on
> > > different engines, so optimizing the function is a bit of a no-go,
> > > especially if we want to have it fast in the future as well.
> > >
> > > So, I thought I'd propose something that would go well with the
> > > earlier proposals to extend Math [2]:
> > >
> > > Math.clz(number)
> > >
> > > This would allow for great speed boost in our decoders if it the JS
> > > engine had this built-in and optimized.
> > >
> > > While at it, it might be wise to add other related functions as well,
> > > such as clo (count leading ones), although not as useful.
> > >
> > > Cheers,
> > > Jussi
> > >
> > > [1]: http://jsperf.com/read-leading-zeros/8
> > > [2]: http://wiki.ecmascript.org/doku.php?id=harmony:more_math_functions
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120304/5f57283f/attachment.html>


More information about the es-discuss mailing list