Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #24750 > unrolled thread

Re: "i = i|0"

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 00:00 +0200
    Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 01:04 +0200
      Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 13:22 +0200
        Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 13:35 +0200
          Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 15:26 +0200

#24750 — Re: "i = i|0"

Stefan Ram wrote:

>   I have read this in a World-Wide Web encyclopedia:
> 
> For example, given the following C code:
> 
> int f(int i) {
>   return i + 1;
> }
> 
> Emscripten would output the following JS code:
> 
> function f(i) {
>   i = i|0;
>   return (i + 1)|0;
> }
> 
>   Do you think that the »|0« is necessary to express the
>   C semantics in JavaScript, or could the speed of the
>   generated code be improved by omitting it?

At least the C semantics are better matched; consider arbitrary input to
the function, or an overflow occuring in the calculation.

I'm not sure about the performance.  Actually, this idiom is quite
common, so it might cause performance improvements in some ECMAScript
implementations.  At least it is used in asm.js to enforce the type of i
and the return value to be an integer type.

[xpost & fup2 comp.lang.javascript]

-- 
Christoph M. Becker

[toc] | [next] | [standalone]

#24754

Christoph Michael Becker wrote:

> Stefan Ram wrote:
>>   I have read this in a World-Wide Web encyclopedia:

OP: When will you learn to provide *proper* references?
 
>> For example, given the following C code:
>> 
>> int f(int i) {
>>   return i + 1;
>> }
>> 
>> Emscripten would output the following JS code:
>> 
>> function f(i) {
>>   i = i|0;
>>   return (i + 1)|0;
>> }
>> 
>>   Do you think that the »|0« is necessary to express the
>>   C semantics in JavaScript, or could the speed of the
>>   generated code be improved by omitting it?
> 
> At least the C semantics are better matched; consider arbitrary input to
> the function, or an overflow occuring in the calculation.
> 
> I'm not sure about the performance.  Actually, this idiom is quite
> common, so it might cause performance improvements in some ECMAScript
> implementations.  At least it is used in asm.js to enforce the type of i
> and the return value to be an integer type.

Unfortunately, you are wrong on all accounts.

It would appear that at least this Emscripten version (probably asm.js, too) 
is yet another script-kiddie approach that should be avoided, at least for 
all computationally critical uses.  ToInt32(…) is _not_ equivalent to 
C/C++’s “int”.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#24761

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> At least the C semantics are better matched; consider arbitrary input to
>> the function, or an overflow occuring in the calculation.
>>
>> I'm not sure about the performance.  Actually, this idiom is quite
>> common, so it might cause performance improvements in some ECMAScript
>> implementations.  At least it is used in asm.js to enforce the type of i
>> and the return value to be an integer type.
> 
> Unfortunately, you are wrong on all accounts.

Even if I am wrong on all accounts, I wouldn't call that unfortunate--at
least I could learn from the mistake/misinformation. :)

> It would appear that at least this Emscripten version (probably asm.js, too) 
> is yet another script-kiddie approach that should be avoided, at least for 
> all computationally critical uses.  

I wouldn't call Emscripten/asm.js a script-kiddie approach.  It seems
asm.js is already supported by all major browsers, and it seems that
there are areas of application where asm.js is mandatory for
performance, e.g. browser games.

>                                     ToInt32(…) is _not_ equivalent to 
> C/C++’s “int”.

Of course.  But if I'm not mistaken, there is no ToInt32() involved in
asm.js code, which instead deals with native "int"s.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24763

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> At least the C semantics are better matched; consider arbitrary input to
>>> the function, or an overflow occuring in the calculation.
>>>
>>> I'm not sure about the performance.  Actually, this idiom is quite
>>> common, so it might cause performance improvements in some ECMAScript
>>> implementations.  At least it is used in asm.js to enforce the type of i
>>> and the return value to be an integer type.
>> 
>> Unfortunately, you are wrong on all accounts.
> 
> Even if I am wrong on all accounts, I wouldn't call that unfortunate--at
> least I could learn from the mistake/misinformation. :)

I would rather that you had not been wrong and this mistake by others had 
been discovered earlier.
 
>> It would appear that at least this Emscripten version (probably asm.js,
>> too) is yet another script-kiddie approach that should be avoided, at
>> least for all computationally critical uses.
> 
> I wouldn't call Emscripten/asm.js a script-kiddie approach.  It seems
> asm.js is already supported by all major browsers, and it seems that
> there are areas of application where asm.js is mandatory for
> performance, e.g. browser games.

So much the worse.
 
>>                                     ToInt32(…) is _not_ equivalent to
>> C/C++’s “int”.
> 
> Of course.  But if I'm not mistaken, there is no ToInt32() involved in
> asm.js code, which instead deals with native "int"s.

You are missing the point.  Native “int”s are *generic*; the “|” algorithm 
is not.  It matters not that asm.js does not use ToInt32(); Emscripten is 
used to transcompile to asm.js, and Emscripten apparently generates code 
that uses ToInt32() implicitly; namely, it uses the “|” operator for 
conversion to pseudo-integer.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#24771

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> Of course.  But if I'm not mistaken, there is no ToInt32() involved in
>> asm.js code, which instead deals with native "int"s.
> 
> You are missing the point.  Native “int”s are *generic*; the “|” algorithm 
> is not.  It matters not that asm.js does not use ToInt32(); Emscripten is 
> used to transcompile to asm.js, and Emscripten apparently generates code 
> that uses ToInt32() implicitly; namely, it uses the “|” operator for 
> conversion to pseudo-integer.

As I understand it, browsers that implement asm.js natively do not use
ECMAScript semantics when dealing with "int"s in "use asm" sections.  In
this case the "|0" "operation" is not executed, but rather serves as
type declaration.  See <http://asmjs.org/spec/latest/#validation> and
the following section.

-- 
Christoph M. Becker

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web