<?php
$size = 10000000;
$start = microtime(true);
for ($i = 0; $i < $size; $i++);
$elapsed = microtime(true) - $start;
?>

<script>
start = (new Date()).getTime();
for (i = 0; i < <?php echo $size; ?>; i++);
elapsed = ((new Date()).getTime() - start) / 1000;
document.open();
document.writeln("javascript took " + elapsed + " seconds<br />");
document.writeln("php took <?php echo $elapsed; ?> seconds");
document.close();
</script>

On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
Javascript takes about 0.05 seconds.  Why is Javascript so much faster?

yawnmoth wrote:
> <?php
> $size = 10000000;
> $start = microtime(true);
> for ($i = 0; $i < $size; $i++);
> $elapsed = microtime(true) - $start;
> ?>
> 
> <script>
> start = (new Date()).getTime();
> for (i = 0; i < <?php echo $size; ?>; i++);
> elapsed = ((new Date()).getTime() - start) / 1000;
> document.open();
> document.writeln("javascript took " + elapsed + " seconds<br />");
> document.writeln("php took <?php echo $elapsed; ?> seconds");
> document.close();
> </script>
> 
> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?

Impossible to tell - there are too many variables. Also, different 
servers will give different results, and even the same server can give 
widely different results on different runs.

But the bottom line is - it's immaterial.  They have two different uses; 
PHP is server side and javascript is client side.  You use whichever one 
you need.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

yawnmoth meinte:
> <?php
> $size = 10000000;
> $start = microtime(true);
> for ($i = 0; $i < $size; $i++);
> $elapsed = microtime(true) - $start;
> ?>
> 
> <script>
> start = (new Date()).getTime();
> for (i = 0; i < <?php echo $size; ?>; i++);
> elapsed = ((new Date()).getTime() - start) / 1000;
> document.open();
> document.writeln("javascript took " + elapsed + " seconds<br />");
> document.writeln("php took <?php echo $elapsed; ?> seconds");
> document.close();
> </script>
> 
> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?

Because of your browser? Because of your hardware (or are you testing on 
localhost)? Because of your server setup? Because PHP is a *completely* 
different thing? Because the above JS run in my Firebug console on a 
FF3.5 takes 10.024 seconds?

Gregor


-- 
http://www.gregorkofler.com

On Jan 23, 12:23=A0pm, Gregor Kofler <use...@gregorkofler.com> wrote:
> yawnmoth meinte:
>
>
>
> > <?php
> > $size =3D 10000000;
> > $start =3D microtime(true);
> > for ($i =3D 0; $i < $size; $i++);
> > $elapsed =3D microtime(true) - $start;
> > ?>
>
> > <script>
> > start =3D (new Date()).getTime();
> > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > document.open();
> > document.writeln("javascript took " + elapsed + " seconds<br />");
> > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > document.close();
> > </script>
>
> > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > Javascript takes about 0.05 seconds. =A0Why is Javascript so much faste=
r?
>
> Because of your browser? Because of your hardware (or are you testing on
> localhost)? Because of your server setup? Because PHP is a *completely*
> different thing? Because the above JS run in my Firebug console on a
> FF3.5 takes 10.024 seconds?

I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
amount of RAM, etc.  Just significantly different times.

If my server setup is causing that significant a slow down what
changes would need to be done to speed it up?  My php.ini file is
pretty minimalistic:

[PHP]
extension_dir =3D "."
extension=3Dphp_gmp.dll

Also, Firebug might be slowing things down for you considerably.
php_xdebug.dll does for me for PHP by three times as much.

yawnmoth wrote:
> On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
>> yawnmoth meinte:
>>
>>
>>
>>> <?php
>>> $size = 10000000;
>>> $start = microtime(true);
>>> for ($i = 0; $i < $size; $i++);
>>> $elapsed = microtime(true) - $start;
>>> ?>
>>> <script>
>>> start = (new Date()).getTime();
>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>> document.open();
>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>> document.close();
>>> </script>
>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>> Because of your browser? Because of your hardware (or are you testing on
>> localhost)? Because of your server setup? Because PHP is a *completely*
>> different thing? Because the above JS run in my Firebug console on a
>> FF3.5 takes 10.024 seconds?
> 
> I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
> amount of RAM, etc.  Just significantly different times.
> 
> If my server setup is causing that significant a slow down what
> changes would need to be done to speed it up?  My php.ini file is
> pretty minimalistic:
> 
> [PHP]
> extension_dir = "."
> extension=php_gmp.dll
> 
> Also, Firebug might be slowing things down for you considerably.
> php_xdebug.dll does for me for PHP by three times as much.

What is the problem you're having?  Or are you just prematurely optimizing?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

yawnmoth wrote:
> On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
>> yawnmoth meinte:
>>
>>
>>
>>> <?php
>>> $size = 10000000;
>>> $start = microtime(true);
>>> for ($i = 0; $i < $size; $i++);
>>> $elapsed = microtime(true) - $start;
>>> ?>
>>> <script>
>>> start = (new Date()).getTime();
>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>> document.open();
>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>> document.close();
>>> </script>
>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>> Because of your browser? Because of your hardware (or are you testing on
>> localhost)? Because of your server setup? Because PHP is a *completely*
>> different thing? Because the above JS run in my Firebug console on a
>> FF3.5 takes 10.024 seconds?
> 
> I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
> amount of RAM, etc.  Just significantly different times.
> 
> If my server setup is causing that significant a slow down what
> changes would need to be done to speed it up?  My php.ini file is
> pretty minimalistic:
> 
> [PHP]
> extension_dir = "."
> extension=php_gmp.dll
> 
> Also, Firebug might be slowing things down for you considerably.
> php_xdebug.dll does for me for PHP by three times as much.

And BTW - on my older laptop, I get:

javascript took 3.754 seconds
php took 3.2663130760193 seconds

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

In article 
<6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com>, yawnmoth 
<terra1024@yahoo.com> wrote:
><?php
>$size = 10000000;
>$start = microtime(true);
>for ($i = 0; $i < $size; $i++);
>$elapsed = microtime(true) - $start;
>?>
>
><script>
>start = (new Date()).getTime();
>for (i = 0; i < <?php echo $size; ?>; i++);
>elapsed = ((new Date()).getTime() - start) / 1000;
>document.open();
>document.writeln("javascript took " + elapsed + " seconds<br />");
>document.writeln("php took <?php echo $elapsed; ?> seconds");
>document.close();
></script>
>
>On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>Javascript takes about 0.05 seconds.  Why is Javascript so much faster?

It isn't. Not on my machine, anyway:
javascript took 2.299 seconds
php took 1.0417001247406 seconds 

Windows Vista, PHP 5.2.1, Firefox 3.0.17

On Jan 23, 1:31=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> yawnmoth wrote:
> > On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
> >> yawnmoth meinte:
>
> >>> <?php
> >>> $size =3D 10000000;
> >>> $start =3D microtime(true);
> >>> for ($i =3D 0; $i < $size; $i++);
> >>> $elapsed =3D microtime(true) - $start;
> >>> ?>
> >>> <script>
> >>> start =3D (new Date()).getTime();
> >>> for (i =3D 0; i < <?php echo $size; ?>; i++);
> >>> elapsed =3D ((new Date()).getTime() - start) / 1000;
> >>> document.open();
> >>> document.writeln("javascript took " + elapsed + " seconds<br />");
> >>> document.writeln("php took <?php echo $elapsed; ?> seconds");
> >>> document.close();
> >>> </script>
> >>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> >>> Javascript takes about 0.05 seconds. =A0Why is Javascript so much fas=
ter?
> >> Because of your browser? Because of your hardware (or are you testing =
on
> >> localhost)? Because of your server setup? Because PHP is a *completely=
*
> >> different thing? Because the above JS run in my Firebug console on a
> >> FF3.5 takes 10.024 seconds?
>
> > I'm testing on localhost. =A0http://127.0.0.1/test.php. =A0Same CPU, sa=
me
> > amount of RAM, etc. =A0Just significantly different times.
>
> > If my server setup is causing that significant a slow down what
> > changes would need to be done to speed it up? =A0My php.ini file is
> > pretty minimalistic:
>
> > [PHP]
> > extension_dir =3D "."
> > extension=3Dphp_gmp.dll
>
> > Also, Firebug might be slowing things down for you considerably.
> > php_xdebug.dll does for me for PHP by three times as much.
>
> What is the problem you're having? =A0Or are you just prematurely optimiz=
ing?

It's not a problem, per say - I'm just curious why PHP is so much
slower.  If what Javascript is doing, internally, is so much faster
than what PHP is doing, internally, why isn't PHP doing what
Javascript is doing, instead?  The only premature optimization I could
really do in PHP would be to replace $i++ with ++$i but that's not
going to get me anywhere even close to Javascript's speed.

That said, it is interesting that Javascript, on your older laptop, is
slower than PHP.  Maybe Firefox's Javascript engine has improved quite
a bit between the version you're using on your old laptop and current
versions?  Or maybe it's a different browser all together?  If it's
the exact same browser (version included) and it was slower that'd
be...  odd.

On Jan 23, 2:27=A0pm, spamb...@milmac.com (Doug Miller) wrote:
> In article
> <6f05c2d9-5919-434d-b4ec-9fed69b57...@l11g2000yqb.googlegroups.com>, yawn=
moth
>
>
>
> <terra1...@yahoo.com> wrote:
> ><?php
> >$size =3D 10000000;
> >$start =3D microtime(true);
> >for ($i =3D 0; $i < $size; $i++);
> >$elapsed =3D microtime(true) - $start;
> >?>
>
> ><script>
> >start =3D (new Date()).getTime();
> >for (i =3D 0; i < <?php echo $size; ?>; i++);
> >elapsed =3D ((new Date()).getTime() - start) / 1000;
> >document.open();
> >document.writeln("javascript took " + elapsed + " seconds<br />");
> >document.writeln("php took <?php echo $elapsed; ?> seconds");
> >document.close();
> ></script>
>
> >On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> >Javascript takes about 0.05 seconds. =A0Why is Javascript so much faster=
?
>
> It isn't. Not on my machine, anyway:
> javascript took 2.299 seconds
> php took 1.0417001247406 seconds
>
> Windows Vista, PHP 5.2.1, Firefox 3.0.17

Hmmm....  I just tried it out on Opera (I was using FF3.5) and got
this:

javascript took 4.306 seconds
php took 2.0045421123505 seconds

Maybe FF3.5's javascript engine is able to recognize that the for loop
isn't doing anything and is just skipping to the end or something...
strange...

yawnmoth wrote:
> On Jan 23, 1:31 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> yawnmoth wrote:
>>> On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
>>>> yawnmoth meinte:
>>>>> <?php
>>>>> $size = 10000000;
>>>>> $start = microtime(true);
>>>>> for ($i = 0; $i < $size; $i++);
>>>>> $elapsed = microtime(true) - $start;
>>>>> ?>
>>>>> <script>
>>>>> start = (new Date()).getTime();
>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>> document.open();
>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>> document.close();
>>>>> </script>
>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>>>> Because of your browser? Because of your hardware (or are you testing on
>>>> localhost)? Because of your server setup? Because PHP is a *completely*
>>>> different thing? Because the above JS run in my Firebug console on a
>>>> FF3.5 takes 10.024 seconds?
>>> I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
>>> amount of RAM, etc.  Just significantly different times.
>>> If my server setup is causing that significant a slow down what
>>> changes would need to be done to speed it up?  My php.ini file is
>>> pretty minimalistic:
>>> [PHP]
>>> extension_dir = "."
>>> extension=php_gmp.dll
>>> Also, Firebug might be slowing things down for you considerably.
>>> php_xdebug.dll does for me for PHP by three times as much.
>> What is the problem you're having?  Or are you just prematurely optimizing?
> 
> It's not a problem, per say - I'm just curious why PHP is so much
> slower.  If what Javascript is doing, internally, is so much faster
> than what PHP is doing, internally, why isn't PHP doing what
> Javascript is doing, instead?  The only premature optimization I could
> really do in PHP would be to replace $i++ with ++$i but that's not
> going to get me anywhere even close to Javascript's speed.
> 
> That said, it is interesting that Javascript, on your older laptop, is
> slower than PHP.  Maybe Firefox's Javascript engine has improved quite
> a bit between the version you're using on your old laptop and current
> versions?  Or maybe it's a different browser all together?  If it's
> the exact same browser (version included) and it was slower that'd
> be...  odd.

Nope, I'm running the next to latest version of Firefox.  Haven't 
upgraded to the one which came out a couple of weeks ago because one of 
my extensions doesn't work.

And php isn't doing what javascript is doing because they are two 
entirely different languages, with two entirely different 
implementations.  Pick another language and you'll get a different result.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

In article <92a5bdae-e472-4ebd-a46a-bb501b0610aa@k35g2000yqb.googlegroups.com>, yawnmoth <terra1024@yahoo.com> wrote:
>On Jan 23, 2:27=A0pm, spamb...@milmac.com (Doug Miller) wrote:
>> In article
>> <6f05c2d9-5919-434d-b4ec-9fed69b57...@l11g2000yqb.googlegroups.com>, yawn=
>moth
[...]
>>
>> >On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>> >Javascript takes about 0.05 seconds. Why is Javascript so much faster?
>>
>> It isn't. Not on my machine, anyway:
>> javascript took 2.299 seconds
>> php took 1.0417001247406 seconds
>>
>> Windows Vista, PHP 5.2.1, Firefox 3.0.17
>
>Hmmm....  I just tried it out on Opera (I was using FF3.5) and got this:
>
>javascript took 4.306 seconds
>php took 2.0045421123505 seconds
>
>Maybe FF3.5's javascript engine is able to recognize that the for loop
>isn't doing anything and is just skipping to the end or something...
>strange...

That's certainly a plausible explanation. Comment out the Javascript for loop, 
and try again. I'll bet the time doesn't differ substantially.

"yawnmoth" <terra1024@yahoo.com> wrote in message 
news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
> <?php
> $size = 10000000;
> $start = microtime(true);
> for ($i = 0; $i < $size; $i++);
> $elapsed = microtime(true) - $start;
> ?>
>
> <script>
> start = (new Date()).getTime();
> for (i = 0; i < <?php echo $size; ?>; i++);
> elapsed = ((new Date()).getTime() - start) / 1000;
> document.open();
> document.writeln("javascript took " + elapsed + " seconds<br />");
> document.writeln("php took <?php echo $elapsed; ?> seconds");
> document.close();
> </script>
>
> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> Javascript takes about 0.05 seconds.  Why is Javascript so much 
> faster?

My Porsche is even faster! ;)
If you compare the speed of JS and PHP, then the comparison with my 
car is just as valid. ;)

R. 

Jerry Stuckle <jstucklex@attglobal.net> writes:

> yawnmoth wrote:
>> On Jan 23, 1:31 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>> yawnmoth wrote:
>>>> On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
>>>>> yawnmoth meinte:
>>>>>> <?php
>>>>>> $size = 10000000;
>>>>>> $start = microtime(true);
>>>>>> for ($i = 0; $i < $size; $i++);
>>>>>> $elapsed = microtime(true) - $start;
>>>>>> ?>
>>>>>> <script>
>>>>>> start = (new Date()).getTime();
>>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>>> document.open();
>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>>> document.close();
>>>>>> </script>
>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>>>>> Because of your browser? Because of your hardware (or are you testing on
>>>>> localhost)? Because of your server setup? Because PHP is a *completely*
>>>>> different thing? Because the above JS run in my Firebug console on a
>>>>> FF3.5 takes 10.024 seconds?
>>>> I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
>>>> amount of RAM, etc.  Just significantly different times.
>>>> If my server setup is causing that significant a slow down what
>>>> changes would need to be done to speed it up?  My php.ini file is
>>>> pretty minimalistic:
>>>> [PHP]
>>>> extension_dir = "."
>>>> extension=php_gmp.dll
>>>> Also, Firebug might be slowing things down for you considerably.
>>>> php_xdebug.dll does for me for PHP by three times as much.
>>> What is the problem you're having?  Or are you just prematurely optimizing?
>> 
>> It's not a problem, per say - I'm just curious why PHP is so much
>> slower.  If what Javascript is doing, internally, is so much faster
>> than what PHP is doing, internally, why isn't PHP doing what
>> Javascript is doing, instead?  The only premature optimization I could
>> really do in PHP would be to replace $i++ with ++$i but that's not
>> going to get me anywhere even close to Javascript's speed.
>> 
>> That said, it is interesting that Javascript, on your older laptop, is
>> slower than PHP.  Maybe Firefox's Javascript engine has improved quite
>> a bit between the version you're using on your old laptop and current
>> versions?  Or maybe it's a different browser all together?  If it's
>> the exact same browser (version included) and it was slower that'd
>> be...  odd.
>
> Nope, I'm running the next to latest version of Firefox.  Haven't 
> upgraded to the one which came out a couple of weeks ago because one of 
> my extensions doesn't work.
>
> And php isn't doing what javascript is doing because they are two 
> entirely different languages, with two entirely different 
> implementations.  Pick another language and you'll get a different
> result.

Its not out of the realms of interest to wonder why two different
languages should be so totally different when doing the same kind of
core programming manipulations however, It is often querying this type
of thing that causes people to select the target language. Any half
decent programmer should not be satisfied with "shrug who cares, its a
different language". An enquiring mind might want to know why and be
aware of potential issues with efficiency if they choose that solution.


-- 
Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
ASCII ribbon campaign ( )
 - against HTML email  X
             & vCards / \

"Richard" <root@localhost> writes:

> "yawnmoth" <terra1024@yahoo.com> wrote in message 
> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>> <?php
>> $size = 10000000;
>> $start = microtime(true);
>> for ($i = 0; $i < $size; $i++);
>> $elapsed = microtime(true) - $start;
>> ?>
>>
>> <script>
>> start = (new Date()).getTime();
>> for (i = 0; i < <?php echo $size; ?>; i++);
>> elapsed = ((new Date()).getTime() - start) / 1000;
>> document.open();
>> document.writeln("javascript took " + elapsed + " seconds<br />");
>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>> document.close();
>> </script>
>>
>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>> Javascript takes about 0.05 seconds.  Why is Javascript so much 
>> faster?
>
> My Porsche is even faster! ;)
> If you compare the speed of JS and PHP, then the comparison with my 
> car is just as valid. ;)
>
> R. 
>

How silly. One can explain the difference between your Porsche and
another car.

I too would wonder why two languages are apparently so hugely different
doing pretty much the same thing. But to look at it properly, clearly one
has to take into account all factors and try and keep a much common
between the test cases in order to evaluate the relative efficiency of
core language constructs between the two languages.

-- 
Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
ASCII ribbon campaign ( )
 - against HTML email  X
             & vCards / \

Richard Riley wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> yawnmoth wrote:
>>> On Jan 23, 1:31 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> yawnmoth wrote:
>>>>> On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
>>>>>> yawnmoth meinte:
>>>>>>> <?php
>>>>>>> $size = 10000000;
>>>>>>> $start = microtime(true);
>>>>>>> for ($i = 0; $i < $size; $i++);
>>>>>>> $elapsed = microtime(true) - $start;
>>>>>>> ?>
>>>>>>> <script>
>>>>>>> start = (new Date()).getTime();
>>>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>>>> document.open();
>>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>>>> document.close();
>>>>>>> </script>
>>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>>>>>> Because of your browser? Because of your hardware (or are you testing on
>>>>>> localhost)? Because of your server setup? Because PHP is a *completely*
>>>>>> different thing? Because the above JS run in my Firebug console on a
>>>>>> FF3.5 takes 10.024 seconds?
>>>>> I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
>>>>> amount of RAM, etc.  Just significantly different times.
>>>>> If my server setup is causing that significant a slow down what
>>>>> changes would need to be done to speed it up?  My php.ini file is
>>>>> pretty minimalistic:
>>>>> [PHP]
>>>>> extension_dir = "."
>>>>> extension=php_gmp.dll
>>>>> Also, Firebug might be slowing things down for you considerably.
>>>>> php_xdebug.dll does for me for PHP by three times as much.
>>>> What is the problem you're having?  Or are you just prematurely optimizing?
>>> It's not a problem, per say - I'm just curious why PHP is so much
>>> slower.  If what Javascript is doing, internally, is so much faster
>>> than what PHP is doing, internally, why isn't PHP doing what
>>> Javascript is doing, instead?  The only premature optimization I could
>>> really do in PHP would be to replace $i++ with ++$i but that's not
>>> going to get me anywhere even close to Javascript's speed.
>>>
>>> That said, it is interesting that Javascript, on your older laptop, is
>>> slower than PHP.  Maybe Firefox's Javascript engine has improved quite
>>> a bit between the version you're using on your old laptop and current
>>> versions?  Or maybe it's a different browser all together?  If it's
>>> the exact same browser (version included) and it was slower that'd
>>> be...  odd.
>> Nope, I'm running the next to latest version of Firefox.  Haven't 
>> upgraded to the one which came out a couple of weeks ago because one of 
>> my extensions doesn't work.
>>
>> And php isn't doing what javascript is doing because they are two 
>> entirely different languages, with two entirely different 
>> implementations.  Pick another language and you'll get a different
>> result.
> 
> Its not out of the realms of interest to wonder why two different
> languages should be so totally different when doing the same kind of
> core programming manipulations however, It is often querying this type
> of thing that causes people to select the target language. Any half
> decent programmer should not be satisfied with "shrug who cares, its a
> different language". An enquiring mind might want to know why and be
> aware of potential issues with efficiency if they choose that solution.
> 
> 

Not when you're talking apples and oranges, it's not.

And, as a matter of fact, unless you're programming something where 
performance is critical, such as real time operations or weather 
prediction, performance is one of the LAST criteria you should be 
considering.  There are too many other things which are more important.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Richard Riley" <rileyrgdev@gmail.com> wrote in message 
news:hjgbbh$vr6$2@news.eternal-september.org...
> "Richard" <root@localhost> writes:
>
>> "yawnmoth" <terra1024@yahoo.com> wrote in message
>> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>>> <?php
>>> $size = 10000000;
>>> $start = microtime(true);
>>> for ($i = 0; $i < $size; $i++);
>>> $elapsed = microtime(true) - $start;
>>> ?>
>>>
>>> <script>
>>> start = (new Date()).getTime();
>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>> document.open();
>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>> document.close();
>>> </script>
>>>
>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>> Javascript takes about 0.05 seconds.  Why is Javascript so much
>>> faster?
>>
>> My Porsche is even faster! ;)
>> If you compare the speed of JS and PHP, then the comparison with my
>> car is just as valid. ;)
>>
>> R.
>>
>
> How silly. One can explain the difference between your Porsche and
> another car.
>
> I too would wonder why two languages are apparently so hugely 
> different
> doing pretty much the same thing. But to look at it properly, 
> clearly one
> has to take into account all factors and try and keep a much common
> between the test cases in order to evaluate the relative efficiency 
> of
> core language constructs between the two languages.
>
> -- 
> Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
> ASCII ribbon campaign ( )
> - against HTML email  X
>             & vCards / \

Ah,
these two languages are so different, it simply makes no sense to 
compare (of all things...) _speed_.
They dont DO the same things, run in totally different environments, 
serve a totally different purpose.

One machine can give decent performance for one language, but be 
horrible for the other.
Change a little in the environment and you get totally different 
outcomes. Now what?

That is all I wanted to say with my comparison.

Oh, BTW: today my Porsche was not even fast, I got taken over by a 
truck.
We had some snow here .... :(

R. 

Jerry Stuckle <jstucklex@attglobal.net> writes:

> Richard Riley wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> 
>>> yawnmoth wrote:
>>>> On Jan 23, 1:31 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>> yawnmoth wrote:
>>>>>> On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
>>>>>>> yawnmoth meinte:
>>>>>>>> <?php
>>>>>>>> $size = 10000000;
>>>>>>>> $start = microtime(true);
>>>>>>>> for ($i = 0; $i < $size; $i++);
>>>>>>>> $elapsed = microtime(true) - $start;
>>>>>>>> ?>
>>>>>>>> <script>
>>>>>>>> start = (new Date()).getTime();
>>>>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>>>>> document.open();
>>>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>>>>> document.close();
>>>>>>>> </script>
>>>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>>>>>>> Because of your browser? Because of your hardware (or are you testing on
>>>>>>> localhost)? Because of your server setup? Because PHP is a *completely*
>>>>>>> different thing? Because the above JS run in my Firebug console on a
>>>>>>> FF3.5 takes 10.024 seconds?
>>>>>> I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
>>>>>> amount of RAM, etc.  Just significantly different times.
>>>>>> If my server setup is causing that significant a slow down what
>>>>>> changes would need to be done to speed it up?  My php.ini file is
>>>>>> pretty minimalistic:
>>>>>> [PHP]
>>>>>> extension_dir = "."
>>>>>> extension=php_gmp.dll
>>>>>> Also, Firebug might be slowing things down for you considerably.
>>>>>> php_xdebug.dll does for me for PHP by three times as much.
>>>>> What is the problem you're having?  Or are you just prematurely optimizing?
>>>> It's not a problem, per say - I'm just curious why PHP is so much
>>>> slower.  If what Javascript is doing, internally, is so much faster
>>>> than what PHP is doing, internally, why isn't PHP doing what
>>>> Javascript is doing, instead?  The only premature optimization I could
>>>> really do in PHP would be to replace $i++ with ++$i but that's not
>>>> going to get me anywhere even close to Javascript's speed.
>>>>
>>>> That said, it is interesting that Javascript, on your older laptop, is
>>>> slower than PHP.  Maybe Firefox's Javascript engine has improved quite
>>>> a bit between the version you're using on your old laptop and current
>>>> versions?  Or maybe it's a different browser all together?  If it's
>>>> the exact same browser (version included) and it was slower that'd
>>>> be...  odd.
>>> Nope, I'm running the next to latest version of Firefox.  Haven't 
>>> upgraded to the one which came out a couple of weeks ago because one of 
>>> my extensions doesn't work.
>>>
>>> And php isn't doing what javascript is doing because they are two 
>>> entirely different languages, with two entirely different 
>>> implementations.  Pick another language and you'll get a different
>>> result.
>> 
>> Its not out of the realms of interest to wonder why two different
>> languages should be so totally different when doing the same kind of
>> core programming manipulations however, It is often querying this type
>> of thing that causes people to select the target language. Any half
>> decent programmer should not be satisfied with "shrug who cares, its a
>> different language". An enquiring mind might want to know why and be
>> aware of potential issues with efficiency if they choose that solution.
>> 
>> 
>
> Not when you're talking apples and oranges, it's not.

Sorry. I disagree completely. It is not apples and oranges. Relative
efficiencies should be of interest to a competent analyst programmer.
>
> And, as a matter of fact, unless you're programming something where 
> performance is critical, such as real time operations or weather 
> prediction, performance is one of the LAST criteria you should be 

Weather prediction? What a strange example. What about anything with
fluid dynamics or game engines or rdbms engines or language parsers or
....

> considering.  There are too many other things which are more
> important.

That is an old wives tale. Efficiency should be in your mind at all
times of application design. This does not mean you conjure up a total
mess to save a few clock cycles obviously.

Without taking into account efficiency at a suitable early time you
would be unable to select the correct and most efficient tools even to
do the job. You might not get a data model which actually performs in
the real world and resulting in a total rewrite and business object re
implementation. So no. Efficiency is NOT something you leave to the very
end. It would be ludicrous to build a system without considering
efficiency.

And leading on from that comes a perfectly reasonable query about why one
language is more suitable for certain programming constructs than
another. The OPs query is perfectly understandable.

-- 
Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
ASCII ribbon campaign ( )
 - against HTML email  X
             & vCards / \

"Richard" <root@localhost> writes:

> "Richard Riley" <rileyrgdev@gmail.com> wrote in message 
> news:hjgbbh$vr6$2@news.eternal-september.org...
>> "Richard" <root@localhost> writes:
>>
>>> "yawnmoth" <terra1024@yahoo.com> wrote in message
>>> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>>>> <?php
>>>> $size = 10000000;
>>>> $start = microtime(true);
>>>> for ($i = 0; $i < $size; $i++);
>>>> $elapsed = microtime(true) - $start;
>>>> ?>
>>>>
>>>> <script>
>>>> start = (new Date()).getTime();
>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>> document.open();
>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>> document.close();
>>>> </script>
>>>>
>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much
>>>> faster?
>>>
>>> My Porsche is even faster! ;)
>>> If you compare the speed of JS and PHP, then the comparison with my
>>> car is just as valid. ;)
>>>
>>> R.
>>>
>>
>> How silly. One can explain the difference between your Porsche and
>> another car.
>>
>> I too would wonder why two languages are apparently so hugely 
>> different
>> doing pretty much the same thing. But to look at it properly, 
>> clearly one
>> has to take into account all factors and try and keep a much common
>> between the test cases in order to evaluate the relative efficiency 
>> of
>> core language constructs between the two languages.
>>
>> -- 
>> Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
>> ASCII ribbon campaign ( )
>> - against HTML email  X
>>             & vCards / \
>
> Ah,
> these two languages are so different, it simply makes no sense to 
> compare (of all things...) _speed_.
> They dont DO the same things, run in totally different environments, 
> serve a totally different purpose.

It dos not make any sense to compare the speed of two languages? That is
patently nonsense. An enquiring mind might want to know why certain
languages do certain things faster in order to select a language for
certain system components.

If I worked with a programmer who didn't give a hoot as to why one
language took 100x longer sorting an array of integers than an another I
would wonder if he should even be involved in that project.

Indeed, that difference in performance could well influence the design
of the system and the decisions on WHERE the processing of various
business is done and how.

>
> One machine can give decent performance for one language, but be 
> horrible for the other.

Obviously.  But clearly I am referring to comparing performance of
similar processing on similar HW.

> Change a little in the environment and you get totally different 
> outcomes. Now what?

This is true of the same language on different HW. I'm not sure what you
are trying to say here. It is so obvious as to be rather
immaterial. Clearly any intelligent debate on the merits or efficiencies
of the two languages must assume similar HW or, well, its pointless...

>
> That is all I wanted to say with my comparison.
>
> Oh, BTW: today my Porsche was not even fast, I got taken over by a 
> truck.
> We had some snow here .... :(
>
> R. 
>

-- 
Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
ASCII ribbon campaign ( )
 - against HTML email  X
             & vCards / \

Richard Riley wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> Richard Riley wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> yawnmoth wrote:
>>>>> On Jan 23, 1:31 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>>> yawnmoth wrote:
>>>>>>> On Jan 23, 12:23 pm, Gregor Kofler <use...@gregorkofler.com> wrote:
>>>>>>>> yawnmoth meinte:
>>>>>>>>> <?php
>>>>>>>>> $size = 10000000;
>>>>>>>>> $start = microtime(true);
>>>>>>>>> for ($i = 0; $i < $size; $i++);
>>>>>>>>> $elapsed = microtime(true) - $start;
>>>>>>>>> ?>
>>>>>>>>> <script>
>>>>>>>>> start = (new Date()).getTime();
>>>>>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>>>>>> document.open();
>>>>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>>>>>> document.close();
>>>>>>>>> </script>
>>>>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>>>>>>>> Because of your browser? Because of your hardware (or are you testing on
>>>>>>>> localhost)? Because of your server setup? Because PHP is a *completely*
>>>>>>>> different thing? Because the above JS run in my Firebug console on a
>>>>>>>> FF3.5 takes 10.024 seconds?
>>>>>>> I'm testing on localhost.  http://127.0.0.1/test.php.  Same CPU, same
>>>>>>> amount of RAM, etc.  Just significantly different times.
>>>>>>> If my server setup is causing that significant a slow down what
>>>>>>> changes would need to be done to speed it up?  My php.ini file is
>>>>>>> pretty minimalistic:
>>>>>>> [PHP]
>>>>>>> extension_dir = "."
>>>>>>> extension=php_gmp.dll
>>>>>>> Also, Firebug might be slowing things down for you considerably.
>>>>>>> php_xdebug.dll does for me for PHP by three times as much.
>>>>>> What is the problem you're having?  Or are you just prematurely optimizing?
>>>>> It's not a problem, per say - I'm just curious why PHP is so much
>>>>> slower.  If what Javascript is doing, internally, is so much faster
>>>>> than what PHP is doing, internally, why isn't PHP doing what
>>>>> Javascript is doing, instead?  The only premature optimization I could
>>>>> really do in PHP would be to replace $i++ with ++$i but that's not
>>>>> going to get me anywhere even close to Javascript's speed.
>>>>>
>>>>> That said, it is interesting that Javascript, on your older laptop, is
>>>>> slower than PHP.  Maybe Firefox's Javascript engine has improved quite
>>>>> a bit between the version you're using on your old laptop and current
>>>>> versions?  Or maybe it's a different browser all together?  If it's
>>>>> the exact same browser (version included) and it was slower that'd
>>>>> be...  odd.
>>>> Nope, I'm running the next to latest version of Firefox.  Haven't 
>>>> upgraded to the one which came out a couple of weeks ago because one of 
>>>> my extensions doesn't work.
>>>>
>>>> And php isn't doing what javascript is doing because they are two 
>>>> entirely different languages, with two entirely different 
>>>> implementations.  Pick another language and you'll get a different
>>>> result.
>>> Its not out of the realms of interest to wonder why two different
>>> languages should be so totally different when doing the same kind of
>>> core programming manipulations however, It is often querying this type
>>> of thing that causes people to select the target language. Any half
>>> decent programmer should not be satisfied with "shrug who cares, its a
>>> different language". An enquiring mind might want to know why and be
>>> aware of potential issues with efficiency if they choose that solution.
>>>
>>>
>> Not when you're talking apples and oranges, it's not.
> 
> Sorry. I disagree completely. It is not apples and oranges. Relative
> efficiencies should be of interest to a competent analyst programmer.

Not when you're comparing apples and oranges.

>> And, as a matter of fact, unless you're programming something where 
>> performance is critical, such as real time operations or weather 
>> prediction, performance is one of the LAST criteria you should be 
> 
> Weather prediction? What a strange example. What about anything with
> fluid dynamics or game engines or rdbms engines or language parsers or
> ...
>

Weather prediction is well known to be one of the most CPU intensive 
processes known toman.  It takes the largest and fastest supercomputers 
in existence and still cannot process data fast enough to get totally 
accurate results.

>> considering.  There are too many other things which are more
>> important.
> 
> That is an old wives tale. Efficiency should be in your mind at all
> times of application design. This does not mean you conjure up a total
> mess to save a few clock cycles obviously.
> 

No, the old wives tale is that efficiency is of great importance, and 
comes from over 40 years ago when storage and cpu were very limited. 
That's when I started programming, and I remember the things we had to 
do then.

> Without taking into account efficiency at a suitable early time you
> would be unable to select the correct and most efficient tools even to
> do the job. You might not get a data model which actually performs in
> the real world and resulting in a total rewrite and business object re
> implementation. So no. Efficiency is NOT something you leave to the very
> end. It would be ludicrous to build a system without considering
> efficiency.
>

If efficiency is so important to you, then I suggest you forget all 
other languages and only program assembler.  It's the most efficient 
language around.

There are many, many more factors to consider than speed.  You're just 
falling into the trap of premature optimization.

If there is a problem with speed, you find the problem and fix it.

> And leading on from that comes a perfectly reasonable query about why one
> language is more suitable for certain programming constructs than
> another. The OPs query is perfectly understandable.
> 

Not at all.  They are two entirely different languages,  with two 
entirely different targets, running in two entirely different environments.

Apples and oranges.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Richard Riley wrote:
> "Richard" <root@localhost> writes:
> 
>> "Richard Riley" <rileyrgdev@gmail.com> wrote in message 
>> news:hjgbbh$vr6$2@news.eternal-september.org...
>>> "Richard" <root@localhost> writes:
>>>
>>>> "yawnmoth" <terra1024@yahoo.com> wrote in message
>>>> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>>>>> <?php
>>>>> $size = 10000000;
>>>>> $start = microtime(true);
>>>>> for ($i = 0; $i < $size; $i++);
>>>>> $elapsed = microtime(true) - $start;
>>>>> ?>
>>>>>
>>>>> <script>
>>>>> start = (new Date()).getTime();
>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>> document.open();
>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>> document.close();
>>>>> </script>
>>>>>
>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much
>>>>> faster?
>>>> My Porsche is even faster! ;)
>>>> If you compare the speed of JS and PHP, then the comparison with my
>>>> car is just as valid. ;)
>>>>
>>>> R.
>>>>
>>> How silly. One can explain the difference between your Porsche and
>>> another car.
>>>
>>> I too would wonder why two languages are apparently so hugely 
>>> different
>>> doing pretty much the same thing. But to look at it properly, 
>>> clearly one
>>> has to take into account all factors and try and keep a much common
>>> between the test cases in order to evaluate the relative efficiency 
>>> of
>>> core language constructs between the two languages.
>>>
>>> -- 
>>> Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
>>> ASCII ribbon campaign ( )
>>> - against HTML email  X
>>>             & vCards / \
>> Ah,
>> these two languages are so different, it simply makes no sense to 
>> compare (of all things...) _speed_.
>> They dont DO the same things, run in totally different environments, 
>> serve a totally different purpose.
> 
> It dos not make any sense to compare the speed of two languages? That is
> patently nonsense. An enquiring mind might want to know why certain
> languages do certain things faster in order to select a language for
> certain system components.
> 
> If I worked with a programmer who didn't give a hoot as to why one
> language took 100x longer sorting an array of integers than an another I
> would wonder if he should even be involved in that project.
>

Oh, and since you brought it up - if I had a programmer on my project 
who was so worried about performance, he wouldn't be on my project any 
more.  I need someone who works, not worries about maybe's.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Richard Riley" <rileyrgdev@gmail.com> wrote in message 
news:hjgfkf$hi4$2@news.eternal-september.org...
> "Richard" <root@localhost> writes:
>
>> "Richard Riley" <rileyrgdev@gmail.com> wrote in message
>> news:hjgbbh$vr6$2@news.eternal-september.org...
>>> "Richard" <root@localhost> writes:
>>>
>>>> "yawnmoth" <terra1024@yahoo.com> wrote in message
>>>> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>>>>> <?php
>>>>> $size = 10000000;
>>>>> $start = microtime(true);
>>>>> for ($i = 0; $i < $size; $i++);
>>>>> $elapsed = microtime(true) - $start;
>>>>> ?>
>>>>>
>>>>> <script>
>>>>> start = (new Date()).getTime();
>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>> document.open();
>>>>> document.writeln("javascript took " + elapsed + " seconds<br 
>>>>> />");
>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>> document.close();
>>>>> </script>
>>>>>
>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much
>>>>> faster?
>>>>
>>>> My Porsche is even faster! ;)
>>>> If you compare the speed of JS and PHP, then the comparison with 
>>>> my
>>>> car is just as valid. ;)
>>>>
>>>> R.
>>>>
>>>
>>> How silly. One can explain the difference between your Porsche and
>>> another car.
>>>
>>> I too would wonder why two languages are apparently so hugely
>>> different
>>> doing pretty much the same thing. But to look at it properly,
>>> clearly one
>>> has to take into account all factors and try and keep a much 
>>> common
>>> between the test cases in order to evaluate the relative 
>>> efficiency
>>> of
>>> core language constructs between the two languages.
>>>
>>> -- 
>>> Google Talk : rileyrgdev@googlemail.com 
>>> http://www.google.com/talk
>>> ASCII ribbon campaign ( )
>>> - against HTML email  X
>>>             & vCards / \
>>
>> Ah,
>> these two languages are so different, it simply makes no sense to
>> compare (of all things...) _speed_.
>> They dont DO the same things, run in totally different 
>> environments,
>> serve a totally different purpose.
>
> It dos not make any sense to compare the speed of two languages? 
> That is
> patently nonsense. An enquiring mind might want to know why certain
> languages do certain things faster in order to select a language for
> certain system components.
>
> If I worked with a programmer who didn't give a hoot as to why one
> language took 100x longer sorting an array of integers than an 
> another I
> would wonder if he should even be involved in that project.
>
> Indeed, that difference in performance could well influence the 
> design
> of the system and the decisions on WHERE the processing of various
> business is done and how.
>
>>
>> One machine can give decent performance for one language, but be
>> horrible for the other.
>
> Obviously.  But clearly I am referring to comparing performance of
> similar processing on similar HW.
>
>> Change a little in the environment and you get totally different
>> outcomes. Now what?
>
> This is true of the same language on different HW. I'm not sure what 
> you
> are trying to say here. It is so obvious as to be rather
> immaterial. Clearly any intelligent debate on the merits or 
> efficiencies
> of the two languages must assume similar HW or, well, its 
> pointless...
>
>>
>> That is all I wanted to say with my comparison.
>>
>> Oh, BTW: today my Porsche was not even fast, I got taken over by a
>> truck.
>> We had some snow here .... :(
>>
>> R.
>>
>
> -- 
> Google Talk : rileyrgdev@googlemail.com  http://www.google.com/talk
> ASCII ribbon campaign ( )
> - against HTML email  X
>             & vCards / \

Hm.... you seem to have some issues... I dont know why. Did I say 
something mean to you in a former life?

It does not make sense to compare the speed of THESE two languages, 
please!

>>> doing pretty much the same thing.
Oh nono, they do not do the same thing AT ALL.

The OUTPUT on screen may LOOK the same (some time elapsed), but the 
result of the test is in a completely different scope!
To me, in these 2 situations something completely different happened.

If you really want to compare speed, then you need a valid test. 
But... I cant even think of one.
If you can, then let me know.

Richard

Richard Riley <rileyrgdev@gmail.com> wrote:
> It dos not make any sense to compare the speed of two languages?

When two languages can be used for the same purpose it might make sense to
make a number of comparisions and comparing the speed might be one such
good comparision.

However, when comparing the speed it would be important to measure the
time it takes to do something relevant for the intended usage. To only
measure the time it takes for a loop to do nothing will only give a result
that is worth exactly nothing.

In the best case whe might be measuring what time it takes to increment a
loop variable, but it is rather trivial for a language to optimize away a
variable which isn't used for anything.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

In article <hjgg4j$mu3$1@news.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>Richard Riley wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> Without taking into account efficiency at a suitable early time you
>> would be unable to select the correct and most efficient tools even to
>> do the job. You might not get a data model which actually performs in
>> the real world and resulting in a total rewrite and business object re
>> implementation. So no. Efficiency is NOT something you leave to the very
>> end. It would be ludicrous to build a system without considering
>> efficiency.
>
>If efficiency is so important to you, then I suggest you forget all 
>other languages and only program assembler.  It's the most efficient 
>language around.
>
>There are many, many more factors to consider than speed.  You're just 
>falling into the trap of premature optimization.
>
>If there is a problem with speed, you find the problem and fix it.

I think you guys are talking past each other, each not realizing that the 
other is talking about a different aspect of performance. Jerry rightly points 
out that concern for performance at the micro level, while vital 40 years ago, 
is misguided now (and has been for quite a while) -- but it appears to me that 
that's not what Richard is talking about at all. He's looking at *macro* level 
performance, and quite correctly insisting that concern for performance at 
*that* level is necessary.

To illustrate with a concrete example, suppose your task is to search a large 
(1M+ rows) array in memory. At the *macro* level, performance is very much an 
issue here: it makes an enormous difference in execution speed whether you use 
serial or binary searches. Having made the sensible choice to use binary 
searches, however, *micro* level performance concerns such as attempting to 
find the most efficient binary search implementation possible are pointless.

To put it slightly differently: obsessing over optimal implementation of any 
particular algorithm, without having *first* determined if the algorithm 
*itself* is optimal, is insane. But so is ignoring the difference, and failing 
to make that determination due to a mistaken belief that "performance" is 
unimportant.

Doug Miller wrote:
> In article <hjgg4j$mu3$1@news.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>> Richard Riley wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>> Without taking into account efficiency at a suitable early time you
>>> would be unable to select the correct and most efficient tools even to
>>> do the job. You might not get a data model which actually performs in
>>> the real world and resulting in a total rewrite and business object re
>>> implementation. So no. Efficiency is NOT something you leave to the very
>>> end. It would be ludicrous to build a system without considering
>>> efficiency.
>> If efficiency is so important to you, then I suggest you forget all 
>> other languages and only program assembler.  It's the most efficient 
>> language around.
>>
>> There are many, many more factors to consider than speed.  You're just 
>> falling into the trap of premature optimization.
>>
>> If there is a problem with speed, you find the problem and fix it.
> 
> I think you guys are talking past each other, each not realizing that the 
> other is talking about a different aspect of performance. Jerry rightly points 
> out that concern for performance at the micro level, while vital 40 years ago, 
> is misguided now (and has been for quite a while) -- but it appears to me that 
> that's not what Richard is talking about at all. He's looking at *macro* level 
> performance, and quite correctly insisting that concern for performance at 
> *that* level is necessary.
> 
> To illustrate with a concrete example, suppose your task is to search a large 
> (1M+ rows) array in memory. At the *macro* level, performance is very much an 
> issue here: it makes an enormous difference in execution speed whether you use 
> serial or binary searches. Having made the sensible choice to use binary 
> searches, however, *micro* level performance concerns such as attempting to 
> find the most efficient binary search implementation possible are pointless.
>

A bit over simplified.

Is performance critical?  If this is something that's done 10x per 
second, then yes, it is.  But if it's done once a year, I would argue 
performance is not that critical.

Additionally, to do a binary search, you need the array to be sorted 
according to your search criteria.  If the incoming data is not sorted 
in the way you need, you either have to sort it or create an index. 
Either will take much longer than just doing a search on the data.

But your point is well taken.

> To put it slightly differently: obsessing over optimal implementation of any 
> particular algorithm, without having *first* determined if the algorithm 
> *itself* is optimal, is insane. But so is ignoring the difference, and failing 
> to make that determination due to a mistaken belief that "performance" is 
> unimportant.

Not necessarily, as I pointed out above.  And more often than not, there 
are issues more important than performance, especially when looking at 
one small section of the code.  Much more critical is code readability 
and maintainability, for instance.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Richard Riley meinte:

> It dos not make any sense to compare the speed of two languages? That is
> patently nonsense. An enquiring mind might want to know why certain
> languages do certain things faster in order to select a language for
> certain system components.
> 
> If I worked with a programmer who didn't give a hoot as to why one
> language took 100x longer sorting an array of integers than an another I
> would wonder if he should even be involved in that project.

Utter nonsense. You are not into programming, are you?
Otherwise you'd know, that there are many more other deciding factors. 
"Speed" (BTW *what* speed? The one "measured" in an ad-hoc "benchmark"?) 
being frequently of lesser interest, when considering maintainability, 
support, functionality, sheer availability, etc. Your programmer who 
doesn't give a hoot for the 100-times-faster-array-sorting-language and 
favors the one, he already has proven frameworks for, is a perfectly 
reasonable guy. (Besides, the application in question doesn't need to 
sort any arrays...)

> Indeed, that difference in performance could well influence the design
> of the system and the decisions on WHERE the processing of various
> business is done and how.

Definitely not in this case.

JS and PHP have *nothing* in common - apart from both being "programming 
languages".

Gregor

-- 
http://www.gregorkofler.com

Gregor Kofler wrote:
> Richard Riley meinte:
> 
>> It dos not make any sense to compare the speed of two languages? That is
>> patently nonsense. An enquiring mind might want to know why certain
>> languages do certain things faster in order to select a language for
>> certain system components.
>>
>> If I worked with a programmer who didn't give a hoot as to why one
>> language took 100x longer sorting an array of integers than an another I
>> would wonder if he should even be involved in that project.
> 
> Utter nonsense. You are not into programming, are you?
> Otherwise you'd know, that there are many more other deciding factors. 
> "Speed" (BTW *what* speed? The one "measured" in an ad-hoc "benchmark"?) 
> being frequently of lesser interest, when considering maintainability, 
> support, functionality, sheer availability, etc. Your programmer who 
> doesn't give a hoot for the 100-times-faster-array-sorting-language and 
> favors the one, he already has proven frameworks for, is a perfectly 
> reasonable guy. (Besides, the application in question doesn't need to 
> sort any arrays...)

speed is never an issue till speed is an issue.

Take the stuff I am developing

99% of it is speed limited by the bandwidth it runs over.

Especially if that's a  guy with just a modem. The app can stuff packets 
into the network faster than the guy can receive them. I don't give a 
hoot about PHP speed. Its an order better than I need, at least.

I ran into four speed issues.

One was the image download conundrum. I wrote php to rescale images to 
no bigger than they would ever be displayed at that point. huge speed 
improvement. Php can rescale an image ten times at least faster than it 
takes to download it even on super fast links.

On some massive pages where javascript was used to give faster access to 
data in between form updates, I compressed the HTML  Again php 
compresses at least ten times faster than the link download speeds, so 
overall a huge speed gain of about 5:1 there.

On one javascript implementation that searched the entire DOM to toggle 
visibility states, IE6 was dog slow. IE7 and Firefox adequately fast. I 
bit the bullet and maintained an array of elements to be toggled, that 
could be searched fastr than the DOM itself. Result, IE6 as fast as the 
rest.

Finally, some MySQL searches took a second or two. Solved by judicious 
addition of indices. Now in the 10ms range.

In no case did I contemplate a change of language: In every case its far 
more relevant to look at the special case and work out where the 
bottleneck was, and re-code to allow for the bottlenecks limitations.

So what does that prove in the context of the OPs argument?

that JavaScript as a language is most certainly implementation 
dependent, for one thing. Browsers differ wildly in their speed of SOME 
javascript functionality.

secondly, speed is not an issue till it's an issue. And mainly the issue 
comes when people are using 3rd party libraries and bloatware. 
Downloading half a meg of javascript library is a lot slower than just 
extracting the few functions you really need.

PHP doesn't suffer there, because its libraries are local.  It may 
suffer from heavy server loads and RAM limits though. But in general, 
its always quicker to do it in PHP than in javascript, simply because 
the code for JS has to be downloaded as well.

All of which makes the original tests curious and interesting, but not 
relevant in any real world situation I have yet experienced.

> 
>> Indeed, that difference in performance could well influence the design
>> of the system and the decisions on WHERE the processing of various
>> business is done and how.
> 
> Definitely not in this case.
> 
> JS and PHP have *nothing* in common - apart from both being "programming 
> languages".
> 

And ergo more or less crap in every way, but if it were that easy, we 
wouldn't need programmers.

Programmers should get their OWN algorithms right before offering 
opinions on the algorithms in the tools they write with.

There's a lot about JavaScript and PHP I dont like, but speed of 
execution is not generally one of them. Except the one case mentioned above.

On Sun, 24 Jan 2010 13:04:05 GMT, Doug Miller wrote:

> To put it slightly differently: obsessing over optimal implementation
> of any particular algorithm, without having *first* determined if
> the algorithm *itself* is optimal, is insane. But so is ignoring the
> difference, and failing to make that determination due to a mistaken
> belief that "performance" is unimportant.

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil" -- Donald Knuth

-- 
15. I will never employ any device with a digital countdown. If I find
   that such a device is absolutely unavoidable, I will set it to 
   activate when the counter reaches 117 and the hero is just putting 
   his plan into action.  --Peter Anspach's Evil Overlord list

On Jan 23, 9:31=A0pm, "Richard" <root@localhost> wrote:
> "Richard Riley" <rileyrg...@gmail.com> wrote in message
>
> news:hjgbbh$vr6$2@news.eternal-september.org...
>
>
>
> > "Richard" <root@localhost> writes:
>
> >> "yawnmoth" <terra1...@yahoo.com> wrote in message
> >>news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com.=
...
> >>> <?php
> >>> $size =3D 10000000;
> >>> $start =3D microtime(true);
> >>> for ($i =3D 0; $i < $size; $i++);
> >>> $elapsed =3D microtime(true) - $start;
> >>> ?>
>
> >>> <script>
> >>> start =3D (new Date()).getTime();
> >>> for (i =3D 0; i < <?php echo $size; ?>; i++);
> >>> elapsed =3D ((new Date()).getTime() - start) / 1000;
> >>> document.open();
> >>> document.writeln("javascript took " + elapsed + " seconds<br />");
> >>> document.writeln("php took <?php echo $elapsed; ?> seconds");
> >>> document.close();
> >>> </script>
>
> >>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> >>> Javascript takes about 0.05 seconds. =A0Why is Javascript so much
> >>> faster?
>
> >> My Porsche is even faster! ;)
> >> If you compare the speed of JS and PHP, then the comparison with my
> >> car is just as valid. ;)
>
> >> R.
>
> > How silly. One can explain the difference between your Porsche and
> > another car.
>
> > I too would wonder why two languages are apparently so hugely
> > different
> > doing pretty much the same thing. But to look at it properly,
> > clearly one
> > has to take into account all factors and try and keep a much common
> > between the test cases in order to evaluate the relative efficiency
> > of
> > core language constructs between the two languages.
>
> > --
> > Google Talk : rileyrg...@googlemail.com =A0http://www.google.com/talk
> > ASCII ribbon campaign ( )
> > - against HTML email =A0X
> > =A0 =A0 =A0 =A0 =A0 =A0 & vCards / \
>
> Ah,
> these two languages are so different, it simply makes no sense to
> compare (of all things...) _speed_.
> They dont DO the same things, run in totally different environments,
> serve a totally different purpose.

My javascript and PHP for loops do the same thing (loop to 10000000)
and serve the same purpose (benchmarking).  Sure, PHP doesn't really
have anything like alert() and javascript doesn't have anything like
PHP's echo, but I'm not benchmarking those, either - I was
benchmarking for loops, which, last I checked, do do the same thing
and do serve the same purpose in both languages.

yawnmoth wrote:
> On Jan 23, 9:31 pm, "Richard" <root@localhost> wrote:
>> "Richard Riley" <rileyrg...@gmail.com> wrote in message
>>
>> news:hjgbbh$vr6$2@news.eternal-september.org...
>>
>>
>>
>>> "Richard" <root@localhost> writes:
>>>> "yawnmoth" <terra1...@yahoo.com> wrote in message
>>>> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>>>>> <?php
>>>>> $size = 10000000;
>>>>> $start = microtime(true);
>>>>> for ($i = 0; $i < $size; $i++);
>>>>> $elapsed = microtime(true) - $start;
>>>>> ?>
>>>>> <script>
>>>>> start = (new Date()).getTime();
>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>> document.open();
>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>> document.close();
>>>>> </script>
>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much
>>>>> faster?
>>>> My Porsche is even faster! ;)
>>>> If you compare the speed of JS and PHP, then the comparison with my
>>>> car is just as valid. ;)
>>>> R.
>>> How silly. One can explain the difference between your Porsche and
>>> another car.
>>> I too would wonder why two languages are apparently so hugely
>>> different
>>> doing pretty much the same thing. But to look at it properly,
>>> clearly one
>>> has to take into account all factors and try and keep a much common
>>> between the test cases in order to evaluate the relative efficiency
>>> of
>>> core language constructs between the two languages.
>>> --
>>> Google Talk : rileyrg...@googlemail.com  http://www.google.com/talk
>>> ASCII ribbon campaign ( )
>>> - against HTML email  X
>>>             & vCards / \
>> Ah,
>> these two languages are so different, it simply makes no sense to
>> compare (of all things...) _speed_.
>> They dont DO the same things, run in totally different environments,
>> serve a totally different purpose.
> 
> My javascript and PHP for loops do the same thing (loop to 10000000)
> and serve the same purpose (benchmarking).  Sure, PHP doesn't really
> have anything like alert() and javascript doesn't have anything like
> PHP's echo, but I'm not benchmarking those, either - I was
> benchmarking for loops, which, last I checked, do do the same thing
> and do serve the same purpose in both languages.

As you've been told by several people, the languages themselves are not 
comparable, therefore any comparison between them is meaningless.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

In article <hjhiec$8kg$1@news.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>Doug Miller wrote:
>> In article <hjgg4j$mu3$1@news.eternal-september.org>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
>>> Richard Riley wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>> Without taking into account efficiency at a suitable early time you
>>>> would be unable to select the correct and most efficient tools even to
>>>> do the job. You might not get a data model which actually performs in
>>>> the real world and resulting in a total rewrite and business object re
>>>> implementation. So no. Efficiency is NOT something you leave to the very
>>>> end. It would be ludicrous to build a system without considering
>>>> efficiency.
>>> If efficiency is so important to you, then I suggest you forget all 
>>> other languages and only program assembler.  It's the most efficient 
>>> language around.
>>>
>>> There are many, many more factors to consider than speed.  You're just 
>>> falling into the trap of premature optimization.
>>>
>>> If there is a problem with speed, you find the problem and fix it.
>> 
>> I think you guys are talking past each other, each not realizing that the 
>> other is talking about a different aspect of performance. Jerry rightly
> points 
>> out that concern for performance at the micro level, while vital 40 years
> ago, 
>> is misguided now (and has been for quite a while) -- but it appears to me
> that 
>> that's not what Richard is talking about at all. He's looking at *macro*
> level 
>> performance, and quite correctly insisting that concern for performance at 
>> *that* level is necessary.
>> 
>> To illustrate with a concrete example, suppose your task is to search a large
> 
>> (1M+ rows) array in memory. At the *macro* level, performance is very much an
> 
>> issue here: it makes an enormous difference in execution speed whether you
> use 
>> serial or binary searches. Having made the sensible choice to use binary 
>> searches, however, *micro* level performance concerns such as attempting to 
>> find the most efficient binary search implementation possible are pointless.
>>
>
>A bit over simplified.

Well, yes, of course. I wanted to keep the example simple enough that the 
details of the example did not obscure the point I wanted to make. :-)
>
>Is performance critical?  If this is something that's done 10x per 
>second, then yes, it is.  But if it's done once a year, I would argue 
>performance is not that critical.
>
>Additionally, to do a binary search, you need the array to be sorted 
>according to your search criteria.  If the incoming data is not sorted 
>in the way you need, you either have to sort it or create an index. 

True, but those operations need to be done only once.

>Either will take much longer than just doing a search on the data.

Sorry, that's not correct, except in cases of very small data sets, or those 
are rarely searched.

Sorting is, typically, an O(n log(n)) algorithm. 
Binary searching is O(log(n)).
Sequential searching is O(n).

Sorting needs to be done only once -- ever. Any subsequent changes to the data 
can be accomplished by means of a binary search to identify the proper 
location for insertion, deletion, or updating -- again, O(log(n)).

With a data set of non-trivial size, even a handful of sequential searches is 
*much* more expensive than one sort.
>
>But your point is well taken.
>
>> To put it slightly differently: obsessing over optimal implementation of any 
>> particular algorithm, without having *first* determined if the algorithm 
>> *itself* is optimal, is insane. But so is ignoring the difference, and failing 
>> to make that determination due to a mistaken belief that "performance" is 
>> unimportant.
>
>Not necessarily, as I pointed out above.  And more often than not, there 
>are issues more important than performance, especially when looking at 
>one small section of the code.  Much more critical is code readability 
>and maintainability, for instance.

In general, I think I'd agree with you there: we passed the tipping point, 
*long* ago, when the programmer's time became more valuable than the 
machine's. That's not to say it's *always* more valuable, though: replacing 
(as I did about 20 years ago) an O(n^2) algorithm in *one program* that *by 
itself* accounted for ten percent of the total CPU time consumed in an 
8-processor OLTP cluster, with an O(n log(n)) algorithm that consumed an order 
of magnitude less time, was amply justified despite the added complexity. That 
particular procedure had a comments-to-code ratio of around 5:1 by the time I 
was finished.

And of course there are sometimes performance issues so severe that they 
prevent the program from functioning. I once had a, ummmm, disagreement :-) 
with a developer over the need for indexes in a SQL query he was trying to 
run, but couldn't, because the sysadmin (me) aborted it every Monday morning 
at 7:30 because it had been running all weekend without producing any results. 
Without indexes, it consisted of the Cartesian product of two tables, each 
with approximately 1.2M rows; given some reasonable estimates for cache hit 
rates and physical IO times, I computed the theoretical time to completion at 
37 years. This is clearly unacceptable for a query intended to be run once a 
day. Indexing one of the tables reduced the time required to around 20 
minutes.

In article <slrnhlp2q5.l3k.hellsop@abyss.ninehells.com>, "Peter H. Coffin" <hellsop@ninehells.com> wrote:
>On Sun, 24 Jan 2010 13:04:05 GMT, Doug Miller wrote:
>
>> To put it slightly differently: obsessing over optimal implementation
>> of any particular algorithm, without having *first* determined if
>> the algorithm *itself* is optimal, is insane. But so is ignoring the
>> difference, and failing to make that determination due to a mistaken
>> belief that "performance" is unimportant.
>
>"We should forget about small efficiencies, say about 97% of the time:
>premature optimization is the root of all evil" -- Donald Knuth
>
As much respect as I have for Dr. Knuth, I'm afraid I have to disagree. 
Replace "all evil" with "much evil" and I concur.

Doug Miller wrote:
> In article <hjhiec$8kg$1@news.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>> Doug Miller wrote:
>>> In article <hjgg4j$mu3$1@news.eternal-september.org>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>>>> Richard Riley wrote:
>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>> Without taking into account efficiency at a suitable early time you
>>>>> would be unable to select the correct and most efficient tools even to
>>>>> do the job. You might not get a data model which actually performs in
>>>>> the real world and resulting in a total rewrite and business object re
>>>>> implementation. So no. Efficiency is NOT something you leave to the very
>>>>> end. It would be ludicrous to build a system without considering
>>>>> efficiency.
>>>> If efficiency is so important to you, then I suggest you forget all 
>>>> other languages and only program assembler.  It's the most efficient 
>>>> language around.
>>>>
>>>> There are many, many more factors to consider than speed.  You're just 
>>>> falling into the trap of premature optimization.
>>>>
>>>> If there is a problem with speed, you find the problem and fix it.
>>> I think you guys are talking past each other, each not realizing that the 
>>> other is talking about a different aspect of performance. Jerry rightly
>> points 
>>> out that concern for performance at the micro level, while vital 40 years
>> ago, 
>>> is misguided now (and has been for quite a while) -- but it appears to me
>> that 
>>> that's not what Richard is talking about at all. He's looking at *macro*
>> level 
>>> performance, and quite correctly insisting that concern for performance at 
>>> *that* level is necessary.
>>>
>>> To illustrate with a concrete example, suppose your task is to search a large
>>> (1M+ rows) array in memory. At the *macro* level, performance is very much an
>>> issue here: it makes an enormous difference in execution speed whether you
>> use 
>>> serial or binary searches. Having made the sensible choice to use binary 
>>> searches, however, *micro* level performance concerns such as attempting to 
>>> find the most efficient binary search implementation possible are pointless.
>>>
>> A bit over simplified.
> 
> Well, yes, of course. I wanted to keep the example simple enough that the 
> details of the example did not obscure the point I wanted to make. :-)
>> Is performance critical?  If this is something that's done 10x per 
>> second, then yes, it is.  But if it's done once a year, I would argue 
>> performance is not that critical.
>>
>> Additionally, to do a binary search, you need the array to be sorted 
>> according to your search criteria.  If the incoming data is not sorted 
>> in the way you need, you either have to sort it or create an index. 
> 
> True, but those operations need to be done only once.
> 

If the data is always accessed only by that criteria, which is almost 
never the case.

>> Either will take much longer than just doing a search on the data.
> 
> Sorry, that's not correct, except in cases of very small data sets, or those 
> are rarely searched.
>
> Sorting is, typically, an O(n log(n)) algorithm. 
> Binary searching is O(log(n)).
> Sequential searching is O(n).
>

Incorrect.  To oversimplify, a sort requires you to look at every 
element of the array.  Then you must determine where it should reside 
and move it to that location.  This usually requires moving other 
records to make room.   This is a much longer process than simply 
looking at the record to see if it meets certain criteria.

Building an index requires a similar operation, examining every element 
of the array and inserting items in the index.  The only difference 
between this and the above is the index elements are typically smaller.

> Sorting needs to be done only once -- ever. Any subsequent changes to the data 
> can be accomplished by means of a binary search to identify the proper 
> location for insertion, deletion, or updating -- again, O(log(n)).
> 

Which makes inserting a new item much more time consuming than keeping 
the data in an unsorted array.  If this array is only searched once a 
year, the overhead of maintaining that sort order may well overshadow a 
simple search of the table.

> With a data set of non-trivial size, even a handful of sequential searches is 
> *much* more expensive than one sort.

Again, only if you are always searching on the same criteria.  And the 
more different criteria you need to use, the more indexes you need to 
create, and the more overhead on every add/delete/update of that data.

>> But your point is well taken.
>>
>>> To put it slightly differently: obsessing over optimal implementation of any 
>>> particular algorithm, without having *first* determined if the algorithm 
>>> *itself* is optimal, is insane. But so is ignoring the difference, and failing 
>>> to make that determination due to a mistaken belief that "performance" is 
>>> unimportant.
>> Not necessarily, as I pointed out above.  And more often than not, there 
>> are issues more important than performance, especially when looking at 
>> one small section of the code.  Much more critical is code readability 
>> and maintainability, for instance.
> 
> In general, I think I'd agree with you there: we passed the tipping point, 
> *long* ago, when the programmer's time became more valuable than the 
> machine's. That's not to say it's *always* more valuable, though: replacing 
> (as I did about 20 years ago) an O(n^2) algorithm in *one program* that *by 
> itself* accounted for ten percent of the total CPU time consumed in an 
> 8-processor OLTP cluster, with an O(n log(n)) algorithm that consumed an order 
> of magnitude less time, was amply justified despite the added complexity. That 
> particular procedure had a comments-to-code ratio of around 5:1 by the time I 
> was finished.
>

Even 30 years ago, readability/maintainability was more important.  When 
I started, mainframes had 4,000 (not 4K!) bytes of storage. A disk held 
  around 400K.  The processor would do less than 200K 8 bit additions 
per *minute*.  The code had to be short and concise; no space could be 
wasted in data storage.

Now, if there is a performance problem, you find that problem and fix 
it.  You don't worry about performance prematurely.

> And of course there are sometimes performance issues so severe that they 
> prevent the program from functioning. I once had a, ummmm, disagreement :-) 
> with a developer over the need for indexes in a SQL query he was trying to 
> run, but couldn't, because the sysadmin (me) aborted it every Monday morning 
> at 7:30 because it had been running all weekend without producing any results. 
> Without indexes, it consisted of the Cartesian product of two tables, each 
> with approximately 1.2M rows; given some reasonable estimates for cache hit 
> rates and physical IO times, I computed the theoretical time to completion at 
> 37 years. This is clearly unacceptable for a query intended to be run once a 
> day. Indexing one of the tables reduced the time required to around 20 
> minutes.

As I said - when there is a problem, you fix it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Jan 24, 1:53=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> yawnmoth wrote:
> > On Jan 23, 9:31 pm, "Richard" <root@localhost> wrote:
> >> "Richard Riley" <rileyrg...@gmail.com> wrote in message
>
> >>news:hjgbbh$vr6$2@news.eternal-september.org...
>
> >>> "Richard" <root@localhost> writes:
> >>>> "yawnmoth" <terra1...@yahoo.com> wrote in message
> >>>>news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.co=
m...
> >>>>> <?php
> >>>>> $size =3D 10000000;
> >>>>> $start =3D microtime(true);
> >>>>> for ($i =3D 0; $i < $size; $i++);
> >>>>> $elapsed =3D microtime(true) - $start;
> >>>>> ?>
> >>>>> <script>
> >>>>> start =3D (new Date()).getTime();
> >>>>> for (i =3D 0; i < <?php echo $size; ?>; i++);
> >>>>> elapsed =3D ((new Date()).getTime() - start) / 1000;
> >>>>> document.open();
> >>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
> >>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
> >>>>> document.close();
> >>>>> </script>
> >>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> >>>>> Javascript takes about 0.05 seconds. =A0Why is Javascript so much
> >>>>> faster?
> >>>> My Porsche is even faster! ;)
> >>>> If you compare the speed of JS and PHP, then the comparison with my
> >>>> car is just as valid. ;)
> >>>> R.
> >>> How silly. One can explain the difference between your Porsche and
> >>> another car.
> >>> I too would wonder why two languages are apparently so hugely
> >>> different
> >>> doing pretty much the same thing. But to look at it properly,
> >>> clearly one
> >>> has to take into account all factors and try and keep a much common
> >>> between the test cases in order to evaluate the relative efficiency
> >>> of
> >>> core language constructs between the two languages.
> >>> --
> >>> Google Talk : rileyrg...@googlemail.com =A0http://www.google.com/talk
> >>> ASCII ribbon campaign ( )
> >>> - against HTML email =A0X
> >>> =A0 =A0 =A0 =A0 =A0 =A0 & vCards / \
> >> Ah,
> >> these two languages are so different, it simply makes no sense to
> >> compare (of all things...) _speed_.
> >> They dont DO the same things, run in totally different environments,
> >> serve a totally different purpose.
>
> > My javascript and PHP for loops do the same thing (loop to 10000000)
> > and serve the same purpose (benchmarking). =A0Sure, PHP doesn't really
> > have anything like alert() and javascript doesn't have anything like
> > PHP's echo, but I'm not benchmarking those, either - I was
> > benchmarking for loops, which, last I checked, do do the same thing
> > and do serve the same purpose in both languages.
>
> As you've been told by several people, the languages themselves are not
> comparable, therefore any comparison between them is meaningless.

So if I liken preg_match('/../', $varname) to varname.match(/../),
that's a meaningless comparison?  If I liken chr() to
String.fromCharCode(), that's a meaningless comparison?  What's next?
Since PHP's echo and PHP's print aren't exactly the same thing maybe
we should say that they're not comparable, either!

The fact that there are differences does not mean they're not
comparable.  Indeed, even apples and oranges are comparable, to an
extent.  Though they may taste differently, they're both sphere shaped
and they're both fruits, among other things.  If a fruity scientist
tried to figure out why they're differently colored should other
scientists call them out simply because "they're different and that's
all there is too it"?  Maybe physicists should stop trying to unify
all four fundamental forces of the universe into a Grand Unified
Theory and just accept the fact that all four forces are different and
that that's all there is to it?

In article <hjib95$15v$1@news.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>Doug Miller wrote:
>> In article <hjhiec$8kg$1@news.eternal-september.org>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
>>> Doug Miller wrote:
>>>> In article <hjgg4j$mu3$1@news.eternal-september.org>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>>> Richard Riley wrote:
>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>>> Without taking into account efficiency at a suitable early time you
>>>>>> would be unable to select the correct and most efficient tools even to
>>>>>> do the job. You might not get a data model which actually performs in
>>>>>> the real world and resulting in a total rewrite and business object re
>>>>>> implementation. So no. Efficiency is NOT something you leave to the very
>>>>>> end. It would be ludicrous to build a system without considering
>>>>>> efficiency.
>>>>> If efficiency is so important to you, then I suggest you forget all 
>>>>> other languages and only program assembler.  It's the most efficient 
>>>>> language around.
>>>>>
>>>>> There are many, many more factors to consider than speed.  You're just 
>>>>> falling into the trap of premature optimization.
>>>>>
>>>>> If there is a problem with speed, you find the problem and fix it.
>>>> I think you guys are talking past each other, each not realizing that the 
>>>> other is talking about a different aspect of performance. Jerry rightly
>>> points 
>>>> out that concern for performance at the micro level, while vital 40 years
>>> ago, 
>>>> is misguided now (and has been for quite a while) -- but it appears to me
>>> that 
>>>> that's not what Richard is talking about at all. He's looking at *macro*
>>> level 
>>>> performance, and quite correctly insisting that concern for performance at 
>>>> *that* level is necessary.
>>>>
>>>> To illustrate with a concrete example, suppose your task is to search a
> large
>>>> (1M+ rows) array in memory. At the *macro* level, performance is very much
> an
>>>> issue here: it makes an enormous difference in execution speed whether you
>>> use 
>>>> serial or binary searches. Having made the sensible choice to use binary 
>>>> searches, however, *micro* level performance concerns such as attempting to
> 
>>>> find the most efficient binary search implementation possible are
> pointless.
>>>>
>>> A bit over simplified.
>> 
>> Well, yes, of course. I wanted to keep the example simple enough that the 
>> details of the example did not obscure the point I wanted to make. :-)
>>> Is performance critical?  If this is something that's done 10x per 
>>> second, then yes, it is.  But if it's done once a year, I would argue 
>>> performance is not that critical.
>>>
>>> Additionally, to do a binary search, you need the array to be sorted 
>>> according to your search criteria.  If the incoming data is not sorted 
>>> in the way you need, you either have to sort it or create an index. 
>> 
>> True, but those operations need to be done only once.
>> 
>
>If the data is always accessed only by that criteria, which is almost 
>never the case.

That depends *entirely* on what the data is used for; it's not a bit uncommon 
for such arrays to be constructed specifically to be searched on only that one 
criterion.
>
>>> Either will take much longer than just doing a search on the data.
>> 
>> Sorry, that's not correct, except in cases of very small data sets, or those 
>> are rarely searched.
>>
>> Sorting is, typically, an O(n log(n)) algorithm. 
>> Binary searching is O(log(n)).
>> Sequential searching is O(n).
>>
>
>Incorrect.  To oversimplify, a sort requires you to look at every 
>element of the array.  Then you must determine where it should reside 
>and move it to that location.  This usually requires moving other 
>records to make room.

That depends on the choice of data structure.

>   This is a much longer process than simply 
>looking at the record to see if it meets certain criteria.

You overlook the fact that it needs to be done only once.
>
>Building an index requires a similar operation, examining every element 
>of the array and inserting items in the index.  The only difference 
>between this and the above is the index elements are typically smaller.
>
>> Sorting needs to be done only once -- ever. Any subsequent changes to the data 
>> can be accomplished by means of a binary search to identify the proper 
>> location for insertion, deletion, or updating -- again, O(log(n)).
>> 
>
>Which makes inserting a new item much more time consuming than keeping 
>the data in an unsorted array. 

True, but for an array of a million rows, insertion into a binary tree 
requires on average only 20 comparisons anyway. That's insignificant.

> If this array is only searched once a 
>year, the overhead of maintaining that sort order may well overshadow a 
>simple search of the table.

As I said -- for data sets that are rarely searched, sorting is more expensive 
than sequential searching.
>
>> With a data set of non-trivial size, even a handful of sequential searches is 
>> *much* more expensive than one sort.
>
>Again, only if you are always searching on the same criteria.  And the 
>more different criteria you need to use, the more indexes you need to 
>create, and the more overhead on every add/delete/update of that data.

Agreed.
>
>>> But your point is well taken.
>>>
>>>> To put it slightly differently: obsessing over optimal implementation of any 
>>>> particular algorithm, without having *first* determined if the algorithm 
>>>> *itself* is optimal, is insane. But so is ignoring the difference, and failing 
>>>> to make that determination due to a mistaken belief that "performance" is 
>>>> unimportant.
>>> Not necessarily, as I pointed out above.  And more often than not, there 
>>> are issues more important than performance, especially when looking at 
>>> one small section of the code.  Much more critical is code readability 
>>> and maintainability, for instance.
>> 
>> In general, I think I'd agree with you there: we passed the tipping point, 
>> *long* ago, when the programmer's time became more valuable than the 
>> machine's. That's not to say it's *always* more valuable, though: replacing 
>> (as I did about 20 years ago) an O(n^2) algorithm in *one program* that *by 
>> itself* accounted for ten percent of the total CPU time consumed in an 
>> 8-processor OLTP cluster, with an O(n log(n)) algorithm that consumed an order 
>> of magnitude less time, was amply justified despite the added complexity. That 
>> particular procedure had a comments-to-code ratio of around 5:1 by the time I  
>> was finished.
>>
>
>Even 30 years ago, readability/maintainability was more important. 

Not more important than order-of-magnitude performance differences.

> When 
>I started, mainframes had 4,000 (not 4K!) bytes of storage. A disk held 
>  around 400K.  The processor would do less than 200K 8 bit additions 
>per *minute*.  The code had to be short and concise; no space could be 
>wasted in data storage.
>
>Now, if there is a performance problem, you find that problem and fix 
>it.  You don't worry about performance prematurely.

Agreed.
>
>> And of course there are sometimes performance issues so severe that they 
>> prevent the program from functioning. I once had a, ummmm, disagreement :-) 
>> with a developer over the need for indexes in a SQL query he was trying to 
>> run, but couldn't, because the sysadmin (me) aborted it every Monday morning 
>> at 7:30 because it had been running all weekend without producing any results. 
>> Without indexes, it consisted of the Cartesian product of two tables, each 
>> with approximately 1.2M rows; given some reasonable estimates for cache hit 
>> rates and physical IO times, I computed the theoretical time to completion at
>> 37 years. This is clearly unacceptable for a query intended to be run once a 
>> day. Indexing one of the tables reduced the time required to around 20 
>> minutes.
>
>As I said - when there is a problem, you fix it.

Yep.

yawnmoth wrote:
> On Jan 24, 1:53 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> yawnmoth wrote:
>>> On Jan 23, 9:31 pm, "Richard" <root@localhost> wrote:
>>>> "Richard Riley" <rileyrg...@gmail.com> wrote in message
>>>> news:hjgbbh$vr6$2@news.eternal-september.org...
>>>>> "Richard" <root@localhost> writes:
>>>>>> "yawnmoth" <terra1...@yahoo.com> wrote in message
>>>>>> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>>>>>>> <?php
>>>>>>> $size = 10000000;
>>>>>>> $start = microtime(true);
>>>>>>> for ($i = 0; $i < $size; $i++);
>>>>>>> $elapsed = microtime(true) - $start;
>>>>>>> ?>
>>>>>>> <script>
>>>>>>> start = (new Date()).getTime();
>>>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>>>> document.open();
>>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>>>> document.close();
>>>>>>> </script>
>>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much
>>>>>>> faster?
>>>>>> My Porsche is even faster! ;)
>>>>>> If you compare the speed of JS and PHP, then the comparison with my
>>>>>> car is just as valid. ;)
>>>>>> R.
>>>>> How silly. One can explain the difference between your Porsche and
>>>>> another car.
>>>>> I too would wonder why two languages are apparently so hugely
>>>>> different
>>>>> doing pretty much the same thing. But to look at it properly,
>>>>> clearly one
>>>>> has to take into account all factors and try and keep a much common
>>>>> between the test cases in order to evaluate the relative efficiency
>>>>> of
>>>>> core language constructs between the two languages.
>>>>> --
>>>>> Google Talk : rileyrg...@googlemail.com  http://www.google.com/talk
>>>>> ASCII ribbon campaign ( )
>>>>> - against HTML email  X
>>>>>             & vCards / \
>>>> Ah,
>>>> these two languages are so different, it simply makes no sense to
>>>> compare (of all things...) _speed_.
>>>> They dont DO the same things, run in totally different environments,
>>>> serve a totally different purpose.
>>> My javascript and PHP for loops do the same thing (loop to 10000000)
>>> and serve the same purpose (benchmarking).  Sure, PHP doesn't really
>>> have anything like alert() and javascript doesn't have anything like
>>> PHP's echo, but I'm not benchmarking those, either - I was
>>> benchmarking for loops, which, last I checked, do do the same thing
>>> and do serve the same purpose in both languages.
>> As you've been told by several people, the languages themselves are not
>> comparable, therefore any comparison between them is meaningless.
> 
> So if I liken preg_match('/../', $varname) to varname.match(/../),
> that's a meaningless comparison?  If I liken chr() to
> String.fromCharCode(), that's a meaningless comparison?  What's next?
> Since PHP's echo and PHP's print aren't exactly the same thing maybe
> we should say that they're not comparable, either!
>

The two languages run in two entirely different environments and have 
two entirely different purposes.  One is an apple, the other is an 
orange.  And any comparison between them is meaningless.

PHP's echo and PHP's print are an entirely different comparison, within 
the same language.

> The fact that there are differences does not mean they're not
> comparable.  Indeed, even apples and oranges are comparable, to an
> extent.  Though they may taste differently, they're both sphere shaped
> and they're both fruits, among other things.  If a fruity scientist
> tried to figure out why they're differently colored should other
> scientists call them out simply because "they're different and that's
> all there is too it"?  Maybe physicists should stop trying to unify
> all four fundamental forces of the universe into a Grand Unified
> Theory and just accept the fact that all four forces are different and
> that that's all there is to it?

Now you're really going off the deep end. You just fail to understand a 
simple concept like the differences between js and PHP make ANY 
performance comparisons meaningless.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(Richard Riley)

>"Richard" <root@localhost> writes:
>
>> Ah,
>> these two languages are so different, it simply makes no sense to 
>> compare (of all things...) _speed_.
>> They dont DO the same things, run in totally different environments, 
>> serve a totally different purpose.
>
>It dos not make any sense to compare the speed of two languages?

No. If you want a comparison, you have to take into account the way the
programs are executed. Just because they do the same according to the
written sources doesn't mean that the CPU performs the same micro ops.

In fact even the same language can lead to totally different results,
dependent on how and where the code is run. For example PHP is usually
executed by the webserver. The code is compiled to some bytecode first,
then interpreted. But there are also tools which compile PHP to native
machine code, which will most likely outperform all interpreted scripts.
So even PHP itself can be faster than PHP. Or think about PHP 4 and 5 -
it's the same language, but a completely different engine. You'll get
different execution times and memory usage.

Heck, even the very same engine might lead to different results, for
example dependent on whether it's compiled just for the generic i386
platform or optimized for your specific CPU.

>That is
>patently nonsense. An enquiring mind might want to know why certain
>languages do certain things faster in order to select a language for
>certain system components.

It's not the language that's faster than another, but the execution
environment. And many things affect the execution speed: native code or
bytecode, virtual machine or not, how much and what optimizations, etc.

Even JS can be run in various environments, even on the server if you
like. There you might compare its speed to PHP, but still you have to
know much more details about how the interpreters work internally and
how the code is actually executed.

>> One machine can give decent performance for one language, but be 
>> horrible for the other.
>
>Obviously.  But clearly I am referring to comparing performance of
>similar processing on similar HW.

A native library on the server is still a totally different thing than a
sandbox environment in a browser, even if both run on the same machine.
The code is prepared and executed in different ways, which can lead to
all kinds of different results. Test the same JS code in three different
browsers and you'll most likely get three different results because of
their different JS engines. Then run the scripts again and you might get
even more differences, now because of caching issues for example.

Micha

yawnmoth meinte:

> My javascript and PHP for loops do the same thing (loop to 10000000)
> and serve the same purpose (benchmarking).

Again: Running your JS in my browser console doesn't take 0.05secs (or 
whatever), but more than 10secs. And you cannot have 200times more 
capable hardware, that's for sure.

> Sure, PHP doesn't really
> have anything like alert() and javascript doesn't have anything like
> PHP's echo, but I'm not benchmarking those, either - I was
> benchmarking for loops, which, last I checked, do do the same thing
> and do serve the same purpose in both languages.

I'm not a 100% positive whether I still get the syntax right, but

move.d d0, 10000000;
loop:
djnz d0, label;

might be even faster - on a 68k-based system...

Anyway, since both PHP and various browsers and their JS implementations 
are open source, you can just check how the loops are implemented.

Gregor


-- 
http://www.gregorkofler.com

On Jan 24, 3:15=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> yawnmoth wrote:
> > On Jan 24, 1:53 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> yawnmoth wrote:
> >>> On Jan 23, 9:31 pm, "Richard" <root@localhost> wrote:
> >>>> "Richard Riley" <rileyrg...@gmail.com> wrote in message
> >>>>news:hjgbbh$vr6$2@news.eternal-september.org...
> >>>>> "Richard" <root@localhost> writes:
> >>>>>> "yawnmoth" <terra1...@yahoo.com> wrote in message
> >>>>>>news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.=
com...
> >>>>>>> <?php
> >>>>>>> $size =3D 10000000;
> >>>>>>> $start =3D microtime(true);
> >>>>>>> for ($i =3D 0; $i < $size; $i++);
> >>>>>>> $elapsed =3D microtime(true) - $start;
> >>>>>>> ?>
> >>>>>>> <script>
> >>>>>>> start =3D (new Date()).getTime();
> >>>>>>> for (i =3D 0; i < <?php echo $size; ?>; i++);
> >>>>>>> elapsed =3D ((new Date()).getTime() - start) / 1000;
> >>>>>>> document.open();
> >>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />")=
;
> >>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
> >>>>>>> document.close();
> >>>>>>> </script>
> >>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> >>>>>>> Javascript takes about 0.05 seconds. =A0Why is Javascript so much
> >>>>>>> faster?
> >>>>>> My Porsche is even faster! ;)
> >>>>>> If you compare the speed of JS and PHP, then the comparison with m=
y
> >>>>>> car is just as valid. ;)
> >>>>>> R.
> >>>>> How silly. One can explain the difference between your Porsche and
> >>>>> another car.
> >>>>> I too would wonder why two languages are apparently so hugely
> >>>>> different
> >>>>> doing pretty much the same thing. But to look at it properly,
> >>>>> clearly one
> >>>>> has to take into account all factors and try and keep a much common
> >>>>> between the test cases in order to evaluate the relative efficiency
> >>>>> of
> >>>>> core language constructs between the two languages.
> >>>>> --
> >>>>> Google Talk : rileyrg...@googlemail.com =A0http://www.google.com/ta=
lk
> >>>>> ASCII ribbon campaign ( )
> >>>>> - against HTML email =A0X
> >>>>> =A0 =A0 =A0 =A0 =A0 =A0 & vCards / \
> >>>> Ah,
> >>>> these two languages are so different, it simply makes no sense to
> >>>> compare (of all things...) _speed_.
> >>>> They dont DO the same things, run in totally different environments,
> >>>> serve a totally different purpose.
> >>> My javascript and PHP for loops do the same thing (loop to 10000000)
> >>> and serve the same purpose (benchmarking). =A0Sure, PHP doesn't reall=
y
> >>> have anything like alert() and javascript doesn't have anything like
> >>> PHP's echo, but I'm not benchmarking those, either - I was
> >>> benchmarking for loops, which, last I checked, do do the same thing
> >>> and do serve the same purpose in both languages.
> >> As you've been told by several people, the languages themselves are no=
t
> >> comparable, therefore any comparison between them is meaningless.
>
> > So if I liken preg_match('/../', $varname) to varname.match(/../),
> > that's a meaningless comparison? =A0If I liken chr() to
> > String.fromCharCode(), that's a meaningless comparison? =A0What's next?
> > Since PHP's echo and PHP's print aren't exactly the same thing maybe
> > we should say that they're not comparable, either!
>
> The two languages run in two entirely different environments and have
> two entirely different purposes. =A0One is an apple, the other is an
> orange. =A0And any comparison between them is meaningless.

So if someone asked if there was a javascript analogue to PHP's ord(),
you'd tell them "nope - analogues between PHP and javascript are
impossible - they're entirely different languages and comparisons
between them are meaningless!" even though, for all essential
purposes, String.fromCharCode() does the same thing?

Certainly a javascript developer ought not think in the same terms
that a PHP developer would.  In PHP, you build a page whereas in
javascript you edit the contents of an existing page.  And sure, ord()
and String.fromCharCode() may not do the exact same thing (the latte
is unicode sensitive whereas the former is not and you can pass an
arbitrary number of parameters to the latter whereas the former only
accepts one) but at that point you're just mincing words.  The
differences between those two functions is skin deep and likely not
going to matter to most people.  And by that same token, a for loop is
a for loop, regardless of the language.

On Jan 23, 7:46=A0pm, "Richard" <root@localhost> wrote:
> "yawnmoth" <terra1...@yahoo.com> wrote in message
>
> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>
>
>
> > <?php
> > $size =3D 10000000;
> > $start =3D microtime(true);
> > for ($i =3D 0; $i < $size; $i++);
> > $elapsed =3D microtime(true) - $start;
> > ?>
>
> > <script>
> > start =3D (new Date()).getTime();
> > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > document.open();
> > document.writeln("javascript took " + elapsed + " seconds<br />");
> > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > document.close();
> > </script>
>
> > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > Javascript takes about 0.05 seconds. =A0Why is Javascript so much
> > faster?
>
> My Porsche is even faster! ;)
> If you compare the speed of JS and PHP, then the comparison with my
> car is just as valid. ;)

How do you do for loops in "My Porsche"?  A for loop in javascript
(and java and C++) looks like this:

for (i =3D 0; i < 10000000; i++);

A for loop in PHP (and Perl) looks like this:

for ($i =3D 0; $i < 10000000; $i++);

A for loop in VBscript looks like this:

For i =3D 0 to 10000000 Next

How do you do a for loop in "My Porsche"?  And if they're totally not
comparable then I'd be very interesting in knowing what those for
loops do on your system?  Certainly they couldn't be doing the same
thing in those languages that they do in PHP because languages can't
possibly be compared!

Maybe the VBscript example actually prints out, on the screen, "hello
world!"?  Certainly that'd make since given how totally fundamentally
different all languages are from one another!

yawnmoth <terra1024@yahoo.com> wrote:
> How do you do for loops in "My Porsche"?

http://www.youtube.com/watch?v=ZJKf5DZA0iU

I agree it is not very fast, but doing it the fast way would be like this:

http://www.youtube.com/watch?v=L5aP3GBk0tw

and we wouldn't like to do that with a Porsche, would we?

> A for loop in javascript
> (and java and C++) looks like this:

Different languages sooner or later ends up in machine code when executed.
What you are comparing is which language is making the most efficient
machine code. The efficience could differ because some store their
variables in RAM, others in registers. There are also other ways to
optimize the code. One trivial optimization of your code would be to
simply replace your loop with:

i := 10000000;

as it would give exactly the same result as your code.

> And if they're totally not comparable then I'd be very interesting in
> knowing what those for loops do on your system?  Certainly they couldn't
> be doing the same thing in those languages that they do in PHP because
> languages can't possibly be compared!

The fact that you can compare the time to cross a river with a boat and
the time to drive around a river with a Porsche does not mean that the
comparision is meaningful for any other purpose than crossing the river.

Your comparision with a loop doing nothing is meaningful for exactly
nothing. If you are considering to do a task and think about which
language to use you should compare the time it takes to do that task. You
should then loop over those caclulations, database accesses or whatever
your task requires instead of looping over nothing. With such a benchmark
you might find which language is fastest for your task, but still, that
benchmark would only apply to your specific task. Even with that knowledge
the performance of a language might not be the reason to choose that
language.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

..oO(yawnmoth)

>How do you do for loops in "My Porsche"?  A for loop in javascript
>(and java and C++) looks like this:
>
>for (i = 0; i < 10000000; i++);
>
>A for loop in PHP (and Perl) looks like this:
>
>for ($i = 0; $i < 10000000; $i++);
>
>A for loop in VBscript looks like this:
>
>For i = 0 to 10000000 Next
>
>How do you do a for loop in "My Porsche"?  And if they're totally not
>comparable then I'd be very interesting in knowing what those for
>loops do on your system?  Certainly they couldn't be doing the same
>thing in those languages that they do in PHP because languages can't
>possibly be compared!
>
>Maybe the VBscript example actually prints out, on the screen, "hello
>world!"?  Certainly that'd make since given how totally fundamentally
>different all languages are from one another!

You're kidding. Of course these loops do the same on the level of the
used language, but how's the code executed internally? What steps are
taken in order to parse, prepare and run the code? That's where the
difference in running time come from.

Of course you can compare code and what it's supposed to do, but it's
hard to do any comparisons performance-wise, because there are way too
many variables in each environment.

As said in another post - try the same code in different PHP versions or
in different browsers: Even there you'll get different results because
of totally different PHP/JS engines.

Micha

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/01/10 19:00, yawnmoth wrote:
> <?php
> $size = 10000000;
> $start = microtime(true);
> for ($i = 0; $i < $size; $i++);
> $elapsed = microtime(true) - $start;
> ?>
> 
> <script>
> start = (new Date()).getTime();
> for (i = 0; i < <?php echo $size; ?>; i++);
> elapsed = ((new Date()).getTime() - start) / 1000;
> document.open();
> document.writeln("javascript took " + elapsed + " seconds<br />");
> document.writeln("php took <?php echo $elapsed; ?> seconds");
> document.close();
> </script>
> 
> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?

Please don't stop.

My popcorn isn't empty yet, and I've enjoyed it so far !


Jesus, why can't ppl needs to discuss stuff they can't change ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAktdUnkACgkQE++2Zdc7EtdIMACggP5qlvs3ZueS6ouMoXSpwu+r
5QAAnjtS1VvPwd9MmK/ynE0SzFYUIyMu
=Q+vz
-----END PGP SIGNATURE-----

yawnmoth wrote:
> On Jan 24, 3:15 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> yawnmoth wrote:
>>> On Jan 24, 1:53 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> yawnmoth wrote:
>>>>> On Jan 23, 9:31 pm, "Richard" <root@localhost> wrote:
>>>>>> "Richard Riley" <rileyrg...@gmail.com> wrote in message
>>>>>> news:hjgbbh$vr6$2@news.eternal-september.org...
>>>>>>> "Richard" <root@localhost> writes:
>>>>>>>> "yawnmoth" <terra1...@yahoo.com> wrote in message
>>>>>>>> news:6f05c2d9-5919-434d-b4ec-9fed69b57b9c@l11g2000yqb.googlegroups.com...
>>>>>>>>> <?php
>>>>>>>>> $size = 10000000;
>>>>>>>>> $start = microtime(true);
>>>>>>>>> for ($i = 0; $i < $size; $i++);
>>>>>>>>> $elapsed = microtime(true) - $start;
>>>>>>>>> ?>
>>>>>>>>> <script>
>>>>>>>>> start = (new Date()).getTime();
>>>>>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>>>>>> document.open();
>>>>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>>>>>> document.close();
>>>>>>>>> </script>
>>>>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much
>>>>>>>>> faster?
>>>>>>>> My Porsche is even faster! ;)
>>>>>>>> If you compare the speed of JS and PHP, then the comparison with my
>>>>>>>> car is just as valid. ;)
>>>>>>>> R.
>>>>>>> How silly. One can explain the difference between your Porsche and
>>>>>>> another car.
>>>>>>> I too would wonder why two languages are apparently so hugely
>>>>>>> different
>>>>>>> doing pretty much the same thing. But to look at it properly,
>>>>>>> clearly one
>>>>>>> has to take into account all factors and try and keep a much common
>>>>>>> between the test cases in order to evaluate the relative efficiency
>>>>>>> of
>>>>>>> core language constructs between the two languages.
>>>>>>> --
>>>>>>> Google Talk : rileyrg...@googlemail.com  http://www.google.com/talk
>>>>>>> ASCII ribbon campaign ( )
>>>>>>> - against HTML email  X
>>>>>>>             & vCards / \
>>>>>> Ah,
>>>>>> these two languages are so different, it simply makes no sense to
>>>>>> compare (of all things...) _speed_.
>>>>>> They dont DO the same things, run in totally different environments,
>>>>>> serve a totally different purpose.
>>>>> My javascript and PHP for loops do the same thing (loop to 10000000)
>>>>> and serve the same purpose (benchmarking).  Sure, PHP doesn't really
>>>>> have anything like alert() and javascript doesn't have anything like
>>>>> PHP's echo, but I'm not benchmarking those, either - I was
>>>>> benchmarking for loops, which, last I checked, do do the same thing
>>>>> and do serve the same purpose in both languages.
>>>> As you've been told by several people, the languages themselves are not
>>>> comparable, therefore any comparison between them is meaningless.
>>> So if I liken preg_match('/../', $varname) to varname.match(/../),
>>> that's a meaningless comparison?  If I liken chr() to
>>> String.fromCharCode(), that's a meaningless comparison?  What's next?
>>> Since PHP's echo and PHP's print aren't exactly the same thing maybe
>>> we should say that they're not comparable, either!
>> The two languages run in two entirely different environments and have
>> two entirely different purposes.  One is an apple, the other is an
>> orange.  And any comparison between them is meaningless.
> 
> So if someone asked if there was a javascript analogue to PHP's ord(),
> you'd tell them "nope - analogues between PHP and javascript are
> impossible - they're entirely different languages and comparisons
> between them are meaningless!" even though, for all essential
> purposes, String.fromCharCode() does the same thing?
> 
> Certainly a javascript developer ought not think in the same terms
> that a PHP developer would.  In PHP, you build a page whereas in
> javascript you edit the contents of an existing page.  And sure, ord()
> and String.fromCharCode() may not do the exact same thing (the latte
> is unicode sensitive whereas the former is not and you can pass an
> arbitrary number of parameters to the latter whereas the former only
> accepts one) but at that point you're just mincing words.  The
> differences between those two functions is skin deep and likely not
> going to matter to most people.  And by that same token, a for loop is
> a for loop, regardless of the language.

You really are dense, aren't you?  Oh, no, I get it now.  You're just 
trolling.

Go away, troll.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

yawnmoth wrote:
>
> How do you do for loops in "My Porsche"? 

Stamp on the brakes, then turn sharply and stamp on the throttle

Simples!!

On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
> <?php
> $size =3D 10000000;
> $start =3D microtime(true);
> for ($i =3D 0; $i < $size; $i++);
> $elapsed =3D microtime(true) - $start;
> ?>
>
> <script>
> start =3D (new Date()).getTime();
> for (i =3D 0; i < <?php echo $size; ?>; i++);
> elapsed =3D ((new Date()).getTime() - start) / 1000;
> document.open();
> document.writeln("javascript took " + elapsed + " seconds<br />");
> document.writeln("php took <?php echo $elapsed; ?> seconds");
> document.close();
> </script>
>
> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> Javascript takes about 0.05 seconds. =A0Why is Javascript so much faster?

Sounds similar to "Which is heavier, oil or water?"

In article <pan.2010.01.24.09.53.54.919985@deadspam.com>,
 Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:

> In the best case whe might be measuring what time it takes to increment a
> loop variable, but it is rather trivial for a language to optimize away a
> variable which isn't used for anything.

How about the first 30 (say) Fibonacci numbers? The last 5 are pretty 
big.

JS (using Spidermonkey's js cli):
-----
function fib(n){
    return n<2?n:fib(n-1)+fib(n-2);                                                                                                                    
}

for(i=0; i<=30; i++)
    print(fib(i)); //js inserts a line break
-----

PHP (using cli 5.3):
-----
<?php                                                                                                                                                  
function fib($n) {
    return $n<2?$n:fib($n-1) + fib($n-2);  
}                                                                                                                                                       

for ($i = 0; $i<=30; $i++) {
   echo fib($i) . "\n";
}       
-----         

I didn't time them, but PHP seems to win here (Mac Pro quad Zeon, lots 
of RAM).
-- 
Very old woody beets will never cook tender.
  -- Fannie Farmer

On Jan 25, 1:37=A0am, Michael Fesser <neti...@gmx.de> wrote:
> .oO(yawnmoth)
>
>
>
> >How do you do for loops in "My Porsche"? =A0A for loop in javascript
> >(and java and C++) looks like this:
>
> >for (i =3D 0; i < 10000000; i++);
>
> >A for loop in PHP (and Perl) looks like this:
>
> >for ($i =3D 0; $i < 10000000; $i++);
>
> >A for loop in VBscript looks like this:
>
> >For i =3D 0 to 10000000 Next
>
> >How do you do a for loop in "My Porsche"? =A0And if they're totally not
> >comparable then I'd be very interesting in knowing what those for
> >loops do on your system? =A0Certainly they couldn't be doing the same
> >thing in those languages that they do in PHP because languages can't
> >possibly be compared!
>
> >Maybe the VBscript example actually prints out, on the screen, "hello
> >world!"? =A0Certainly that'd make since given how totally fundamentally
> >different all languages are from one another!
>
> You're kidding. Of course these loops do the same on the level of the
> used language, but how's the code executed internally? What steps are
> taken in order to parse, prepare and run the code? That's where the
> difference in running time come from.
>
> Of course you can compare code and what it's supposed to do, but it's
> hard to do any comparisons performance-wise, because there are way too
> many variables in each environment.
>
> As said in another post - try the same code in different PHP versions or
> in different browsers: Even there you'll get different results because
> of totally different PHP/JS engines.

I'm not denying that.  Indeed, I already proposed something similar:

http://groups.google.com/group/comp.lang.php/msg/12e1b4786084c623

To quote from that post, "maybe FF3.5's javascript engine is able to
recognize that the for loop isn't doing anything and is just skipping
to the end".  Or maybe it's doing something else.  Presumably most of
the things it could be doing PHP could do, as well.  Whether or not it
should is another matter entirely.

What I just find ludicrous is the whole "they're different and that's
all there is too it!" attitude.  Why are they different?  Oh, wait -
they're different because they're different!  Wheee!  What did the PHP
core development team do to make PHP5 faster than PHP4?  I could
always say "I don't know what they did - here are the SVN repos for
both - maybe you can look and find out" but nah - I'll just say "My
Porsche is faster than PHP4 and you're a dense idiot of a troll for
asking!"  Wheee!

On Jan 25, 6:30=A0am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
>
>
>
> > <?php
> > $size =3D 10000000;
> > $start =3D microtime(true);
> > for ($i =3D 0; $i < $size; $i++);
> > $elapsed =3D microtime(true) - $start;
> > ?>
>
> > <script>
> > start =3D (new Date()).getTime();
> > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > document.open();
> > document.writeln("javascript took " + elapsed + " seconds<br />");
> > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > document.close();
> > </script>
>
> > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > Javascript takes about 0.05 seconds. =A0Why is Javascript so much faste=
r?
>
> Sounds similar to "Which is heavier, oil or water?"

http://www.google.com/search?q=3DWhich+is+heavier%2C+oil+or+water%3F

I wonder why no one has responded with anything as flippant as "My PHP
program is heavier than water!"...

On Jan 25, 5:30=A0pm, yawnmoth <terra1...@yahoo.com> wrote:
> On Jan 25, 6:30=A0am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
>
>
> > On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > <?php
> > > $size =3D 10000000;
> > > $start =3D microtime(true);
> > > for ($i =3D 0; $i < $size; $i++);
> > > $elapsed =3D microtime(true) - $start;
> > > ?>
>
> > > <script>
> > > start =3D (new Date()).getTime();
> > > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > > document.open();
> > > document.writeln("javascript took " + elapsed + " seconds<br />");
> > > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > > document.close();
> > > </script>
>
> > > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > > Javascript takes about 0.05 seconds. =A0Why is Javascript so much fas=
ter?
>
> > Sounds similar to "Which is heavier, oil or water?"
>
> http://www.google.com/search?q=3DWhich+is+heavier%2C+oil+or+water%3F
>
> I wonder why no one has responded with anything as flippant as "My PHP
> program is heavier than water!"...

Most of the links in those search results are of course wrong.

On Jan 25, 5:14=A0pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On Jan 25, 5:30=A0pm, yawnmoth <terra1...@yahoo.com> wrote:
>
>
>
> > On Jan 25, 6:30=A0am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > > <?php
> > > > $size =3D 10000000;
> > > > $start =3D microtime(true);
> > > > for ($i =3D 0; $i < $size; $i++);
> > > > $elapsed =3D microtime(true) - $start;
> > > > ?>
>
> > > > <script>
> > > > start =3D (new Date()).getTime();
> > > > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > > > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > > > document.open();
> > > > document.writeln("javascript took " + elapsed + " seconds<br />");
> > > > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > > > document.close();
> > > > </script>
>
> > > > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > > > Javascript takes about 0.05 seconds. =A0Why is Javascript so much f=
aster?
>
> > > Sounds similar to "Which is heavier, oil or water?"
>
> >http://www.google.com/search?q=3DWhich+is+heavier%2C+oil+or+water%3F
>
> > I wonder why no one has responded with anything as flippant as "My PHP
> > program is heavier than water!"...
>
> Most of the links in those search results are of course wrong.

I'm confused.  Most of the links imply it's lighter, which it is?
It's less dense (which is why it floats on water) and, if you have an
equal volume of water and oil, the water will weigh more?

On 25 Jan 2010, yawnmoth <terra1024@yahoo.com> wrote:

> On Jan 25, 1:37�am, Michael Fesser <neti...@gmx.de> wrote:
>> .oO(yawnmoth)
>> 
>>> How do you do for loops in "My Porsche"? �A for loop in
>>> javascript (and java and C++) looks like this:

<snip loops>

>>> How do you do a for loop in "My Porsche"? �And if they're
>>> totally not comparable then I'd be very interesting in knowing
>>> what those for loops do on your system? �Certainly they
>>> couldn't be doing the same thing in those languages that they
>>> do in PHP because languages can't possibly be compared!
>> 
>>> Maybe the VBscript example actually prints out, on the screen,
>>> "hello world!"? �Certainly that'd make since given how totally
>>> fundamentally different all languages are from one another!
>> 
>> You're kidding. Of course these loops do the same on the level
>> of the used language, but how's the code executed internally?
>> What steps are taken in order to parse, prepare and run the
>> code? That's where the difference in running time come from.
>> 
>> Of course you can compare code and what it's supposed to do,
>> but it's hard to do any comparisons performance-wise, because
>> there are way too many variables in each environment.
>> 
>> As said in another post - try the same code in different PHP
>> versions or in different browsers: Even there you'll get
>> different results because of totally different PHP/JS engines.
> 
> I'm not denying that.  Indeed, I already proposed something
> similar: 
> 
> http://groups.google.com/group/comp.lang.php/msg/12e1b4786084c623
> 
> To quote from that post, "maybe FF3.5's javascript engine is
> able to recognize that the for loop isn't doing anything and is
> just skipping to the end".  Or maybe it's doing something else. 
> Presumably most of the things it could be doing PHP could do, as
> well.  Whether or not it should is another matter entirely.
> 
> What I just find ludicrous is the whole "they're different and
> that's all there is too it!" attitude.  Why are they different? 
> Oh, wait - they're different because they're different!  Wheee! 

If you genuinely want help, you might consider dropping the 
sarcastic retorts.

The amount of research it would take to get any meaningful answer 
isn't worth it.  Do you expect someone to comb through the source 
code from a half-dozen ECMAScript implementations (and at varying 
versions), as well as various versions of PHP source code?  But now 
you have to consider the different systems on which the code would 
be run, since the results of your benchmark aren't necessarily 
governed by the implementations themselves.

I can understand why you'd be curious, but a far better approach 
would be to learn more about language parsing and code generation.  
I recommend purchasing _Compilers: Principles, Techniques, and 
Tools_ (The Dragon Book).  These topics, by themselves, are OT here.

> What did the PHP core development team do to make PHP5 faster
> than PHP4?

What makes you think they necessarily changed for-loops in this 
regard?  That's just the point people have been making, the 
differing results might be caused by a number of factors, even 
outside PHP.  However, expending the effort in trying to find out 
why it's different yields no practical gain.

> I could always say "I don't know what they did -
> here are the SVN repos for both - maybe you can look and find
> out" but nah - I'll just say "My Porsche is faster than PHP4 and
> you're a dense idiot of a troll for asking!"  Wheee!

Okay, so you already had an idea about how to investigate.  Since 
you're the one who's curious, why don't you do your own research?

-- 
Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

On Jan 25, 7:43=A0pm, Curtis Dyer <dye...@gmail.com> wrote:
> On 25 Jan 2010, yawnmoth <terra1...@yahoo.com> wrote:
>
> > On Jan 25, 1:37=A0am, Michael Fesser <neti...@gmx.de> wrote:
> >> .oO(yawnmoth)
>
> >>> How do you do for loops in "My Porsche"? =A0A for loop in
> >>> javascript (and java and C++) looks like this:
>
> <snip loops>
>
>
>
> >>> How do you do a for loop in "My Porsche"? =A0And if they're
> >>> totally not comparable then I'd be very interesting in knowing
> >>> what those for loops do on your system? =A0Certainly they
> >>> couldn't be doing the same thing in those languages that they
> >>> do in PHP because languages can't possibly be compared!
>
> >>> Maybe the VBscript example actually prints out, on the screen,
> >>> "hello world!"? =A0Certainly that'd make since given how totally
> >>> fundamentally different all languages are from one another!
>
> >> You're kidding. Of course these loops do the same on the level
> >> of the used language, but how's the code executed internally?
> >> What steps are taken in order to parse, prepare and run the
> >> code? That's where the difference in running time come from.
>
> >> Of course you can compare code and what it's supposed to do,
> >> but it's hard to do any comparisons performance-wise, because
> >> there are way too many variables in each environment.
>
> >> As said in another post - try the same code in different PHP
> >> versions or in different browsers: Even there you'll get
> >> different results because of totally different PHP/JS engines.
>
> > I'm not denying that. =A0Indeed, I already proposed something
> > similar:
>
> >http://groups.google.com/group/comp.lang.php/msg/12e1b4786084c623
>
> > To quote from that post, "maybe FF3.5's javascript engine is
> > able to recognize that the for loop isn't doing anything and is
> > just skipping to the end". =A0Or maybe it's doing something else.
> > Presumably most of the things it could be doing PHP could do, as
> > well. =A0Whether or not it should is another matter entirely.
>
> > What I just find ludicrous is the whole "they're different and
> > that's all there is too it!" attitude. =A0Why are they different?
> > Oh, wait - they're different because they're different! =A0Wheee!
>
> If you genuinely want help, you might consider dropping the
> sarcastic retorts.
>
> The amount of research it would take to get any meaningful answer
> isn't worth it. =A0Do you expect someone to comb through the source
> code from a half-dozen ECMAScript implementations (and at varying
> versions), as well as various versions of PHP source code?

No - I don't.  To be honest, at the time I made my post, it didn't
occur to me to test on other browsers.  I just sorta assumed that all
Javascript engines would perform similarly.  It was definitely a dumb
assumption as subsequent posts would demonstrate when they posted
their benchmarks and I can only hope that I won't make similarly dumb
assumptions in the future.

As for my subsequent posts...  well, imho, this thread stopped being
discussion about benchmarks quite some time ago and more of a
"yawnmoth is stupid for even asking" thread and I don't agree with
that.  Yes, my initial assumption was a bad one, but given that I
*did* have it, I don't see the question as being a bad one.  Indeed,
as you observed, I can still pursue it and such pursuit wouldn't make
me an idiot.  That it's not something you or anyone else would chose
to pursue does not mean it's a fundamentally flawed pursuit even
though that's the message I get from some of the posts that have been
made here.  And people who do think that, imho, do deserve derision.

On Jan 25, 7:43=A0pm, Curtis Dyer <dye...@gmail.com> wrote:
> On 25 Jan 2010, yawnmoth <terra1...@yahoo.com> wrote:
>
> > On Jan 25, 1:37=A0am, Michael Fesser <neti...@gmx.de> wrote:
> >> .oO(yawnmoth)
>
> >>> How do you do for loops in "My Porsche"? =A0A for loop in
> >>> javascript (and java and C++) looks like this:
>
> <snip loops>
>
>
>
> >>> How do you do a for loop in "My Porsche"? =A0And if they're
> >>> totally not comparable then I'd be very interesting in knowing
> >>> what those for loops do on your system? =A0Certainly they
> >>> couldn't be doing the same thing in those languages that they
> >>> do in PHP because languages can't possibly be compared!
>
> >>> Maybe the VBscript example actually prints out, on the screen,
> >>> "hello world!"? =A0Certainly that'd make since given how totally
> >>> fundamentally different all languages are from one another!
>
> >> You're kidding. Of course these loops do the same on the level
> >> of the used language, but how's the code executed internally?
> >> What steps are taken in order to parse, prepare and run the
> >> code? That's where the difference in running time come from.
>
> >> Of course you can compare code and what it's supposed to do,
> >> but it's hard to do any comparisons performance-wise, because
> >> there are way too many variables in each environment.
>
> >> As said in another post - try the same code in different PHP
> >> versions or in different browsers: Even there you'll get
> >> different results because of totally different PHP/JS engines.
>
> > I'm not denying that. =A0Indeed, I already proposed something
> > similar:
>
> >http://groups.google.com/group/comp.lang.php/msg/12e1b4786084c623
>
> > To quote from that post, "maybe FF3.5's javascript engine is
> > able to recognize that the for loop isn't doing anything and is
> > just skipping to the end". =A0Or maybe it's doing something else.
> > Presumably most of the things it could be doing PHP could do, as
> > well. =A0Whether or not it should is another matter entirely.
>
> > What I just find ludicrous is the whole "they're different and
> > that's all there is too it!" attitude. =A0Why are they different?
> > Oh, wait - they're different because they're different! =A0Wheee!
>
> If you genuinely want help, you might consider dropping the
> sarcastic retorts.
>
> The amount of research it would take to get any meaningful answer
> isn't worth it. =A0Do you expect someone to comb through the source
> code from a half-dozen ECMAScript implementations (and at varying
> versions), as well as various versions of PHP source code? =A0But now
> you have to consider the different systems on which the code would
> be run, since the results of your benchmark aren't necessarily
> governed by the implementations themselves.
>
> I can understand why you'd be curious, but a far better approach
> would be to learn more about language parsing and code generation. =A0
> I recommend purchasing _Compilers: Principles, Techniques, and
> Tools_ (The Dragon Book). =A0These topics, by themselves, are OT here.
>
> > What did the PHP core development team do to make PHP5 faster
> > than PHP4?
>
> What makes you think they necessarily changed for-loops in this
> regard? =A0That's just the point people have been making, the
> differing results might be caused by a number of factors, even
> outside PHP. =A0However, expending the effort in trying to find out
> why it's different yields no practical gain.

Also, when I made my PHP4 vs. PHP5 comment, I wasn't talking about for
loops.  I was talking about in general.  In general, PHP4 is faster
than PHP5.  At least by some methods of benchmarking.

And as for the for loops in FF3.5 (for me) and in PHP5.3...  if
javascript was 1.9 seconds and PHP was 2.0 seconds, I'd attribute that
to just random chance.  Maybe Thunderbird was busy checking an SMTP
server during one of the trials or something.  But that's not what the
difference was.  It was 0.05 seconds vs. 2 seconds.  And it was 0.05
seconds vs. 2 seconds consistently across multiple trials.  That's not
chance.  Another possibility (in addition to the one I proposed):
maybe the browser just operates with a higher priority than PHP does.
I'm willing to concede that maybe it has nothing to do with the
Javascript engine and that maybe it has to do with something else, but
what else might it be?  Although I don't care enough to devote much
time and effort to finding out it would be interesting to know.  And
indeed, that's why I made my initial post.

I wasn't asking for people to spend hours and hours and hours digging
into Firefox's internals and PHP's - I was asking in case anyone knew
*of the top of their head*.  And if it was (as I had idiotically
assumed) consistent across all browsers maybe it's something that
someone may have read about in a book or something.  Maybe there was a
quick and easy explanation that I was simply unaware of.  And now I
know that there isn't but what would you have proposed I do instead?
Not make dumb assumptions?  Well, forgive me for saying so, but you
learn by doing.  You learn *by* making dumb assumptions and being
called out on it, which I suppose is what happened.  Mind you, people
could have just said "you're operating on bad assumptions" rather then
engaging in what amounts to name calling.

On Jan 26, 1:32=A0am, yawnmoth <terra1...@yahoo.com> wrote:
> On Jan 25, 5:14=A0pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
>
>
> > On Jan 25, 5:30=A0pm, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > On Jan 25, 6:30=A0am, Captain Paralytic <paul_laut...@yahoo.com> wrot=
e:
>
> > > > On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > > > <?php
> > > > > $size =3D 10000000;
> > > > > $start =3D microtime(true);
> > > > > for ($i =3D 0; $i < $size; $i++);
> > > > > $elapsed =3D microtime(true) - $start;
> > > > > ?>
>
> > > > > <script>
> > > > > start =3D (new Date()).getTime();
> > > > > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > > > > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > > > > document.open();
> > > > > document.writeln("javascript took " + elapsed + " seconds<br />")=
;
> > > > > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > > > > document.close();
> > > > > </script>
>
> > > > > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > > > > Javascript takes about 0.05 seconds. =A0Why is Javascript so much=
 faster?
>
> > > > Sounds similar to "Which is heavier, oil or water?"
>
> > >http://www.google.com/search?q=3DWhich+is+heavier%2C+oil+or+water%3F
>
> > > I wonder why no one has responded with anything as flippant as "My PH=
P
> > > program is heavier than water!"...
>
> > Most of the links in those search results are of course wrong.
>
> I'm confused. =A0Most of the links imply it's lighter, which it is?
> It's less dense (which is why it floats on water) and, if you have an
> equal volume of water and oil, the water will weigh more?

It is indeed "less dense", but the question "Which is heavier, oil or
water?", is a nonsense question. 200g of oil is heavier than 100g of
water.

On Jan 26, 11:42=A0am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On Jan 26, 1:32=A0am, yawnmoth <terra1...@yahoo.com> wrote:
>
>
>
> > On Jan 25, 5:14=A0pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > On Jan 25, 5:30=A0pm, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > > On Jan 25, 6:30=A0am, Captain Paralytic <paul_laut...@yahoo.com> wr=
ote:
>
> > > > > On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > > > > <?php
> > > > > > $size =3D 10000000;
> > > > > > $start =3D microtime(true);
> > > > > > for ($i =3D 0; $i < $size; $i++);
> > > > > > $elapsed =3D microtime(true) - $start;
> > > > > > ?>
>
> > > > > > <script>
> > > > > > start =3D (new Date()).getTime();
> > > > > > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > > > > > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > > > > > document.open();
> > > > > > document.writeln("javascript took " + elapsed + " seconds<br />=
");
> > > > > > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > > > > > document.close();
> > > > > > </script>
>
> > > > > > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > > > > > Javascript takes about 0.05 seconds. =A0Why is Javascript so mu=
ch faster?
>
> > > > > Sounds similar to "Which is heavier, oil or water?"
>
> > > >http://www.google.com/search?q=3DWhich+is+heavier%2C+oil+or+water%3F
>
> > > > I wonder why no one has responded with anything as flippant as "My =
PHP
> > > > program is heavier than water!"...
>
> > > Most of the links in those search results are of course wrong.
>
> > I'm confused. =A0Most of the links imply it's lighter, which it is?
> > It's less dense (which is why it floats on water) and, if you have an
> > equal volume of water and oil, the water will weigh more?
>
> It is indeed "less dense", but the question "Which is heavier, oil or
> water?", is a nonsense question. 200g of oil is heavier than 100g of
> water.

If you are going to be that pedantic you should get the units right.
Grams is a measure of mass not weight.

100g of water on the earth weighs more than 200g of oil on the
moon. ;)

Mark Smith schreef:
> On Jan 26, 11:42 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>> On Jan 26, 1:32 am, yawnmoth <terra1...@yahoo.com> wrote:
>>
>>
>>
>>> On Jan 25, 5:14 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>>>> On Jan 25, 5:30 pm, yawnmoth <terra1...@yahoo.com> wrote:
>>>>> On Jan 25, 6:30 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>>>>>> On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
>>>>>>> <?php
>>>>>>> $size = 10000000;
>>>>>>> $start = microtime(true);
>>>>>>> for ($i = 0; $i < $size; $i++);
>>>>>>> $elapsed = microtime(true) - $start;
>>>>>>> ?>
>>>>>>> <script>
>>>>>>> start = (new Date()).getTime();
>>>>>>> for (i = 0; i < <?php echo $size; ?>; i++);
>>>>>>> elapsed = ((new Date()).getTime() - start) / 1000;
>>>>>>> document.open();
>>>>>>> document.writeln("javascript took " + elapsed + " seconds<br />");
>>>>>>> document.writeln("php took <?php echo $elapsed; ?> seconds");
>>>>>>> document.close();
>>>>>>> </script>
>>>>>>> On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
>>>>>>> Javascript takes about 0.05 seconds.  Why is Javascript so much faster?
>>>>>> Sounds similar to "Which is heavier, oil or water?"
>>>>> http://www.google.com/search?q=Which+is+heavier%2C+oil+or+water%3F
>>>>> I wonder why no one has responded with anything as flippant as "My PHP
>>>>> program is heavier than water!"...
>>>> Most of the links in those search results are of course wrong.
>>> I'm confused.  Most of the links imply it's lighter, which it is?
>>> It's less dense (which is why it floats on water) and, if you have an
>>> equal volume of water and oil, the water will weigh more?
>> It is indeed "less dense", but the question "Which is heavier, oil or
>> water?", is a nonsense question. 200g of oil is heavier than 100g of
>> water.
> 
> If you are going to be that pedantic you should get the units right.
> Grams is a measure of mass not weight.
> 
> 100g of water on the earth weighs more than 200g of oil on the
> moon. ;)
> 

Reminds me of a fun story of that great, now gone, Richard Feynman.

When studying physics the teacher decided to tease the class, filled 
with freshmen, a little with a (famous) trickquestion:
"What weights more: A kilogram of iron or a kilogram of feathers?"

The smarter students smiled and answered: "They weight the same, since 
you say they both have a mass of 1 kilogram."
The teacher was of course happy and wanted to continue his lesson.

Then Feynman said: "Well, it is not that simple. If I put a kilogram of 
feathers on a balance it will show less weight than for a kilogram of 
iron.".
The teacher smiled knowingly, and started to explain it to that slow 
student.
But Feynman was right. :-)

Feynman: "Look, A kilogram is a kilogram, no discussion there, so they 
have the same mass. But you all seem to forget that a kilogram of 
feathers displaces more air because it occupies a greater volume, so it 
  experiences more upward presure, like a baloon held under water. Iron 
displaces much less volume. So the kilogram of iron weights more. If you 
put them both on an accurate balance you will see that a kilogram of 
feather weights slightly less."

I wonder how that teacher reacted. :-)

As with many stories about Feynman, you  can never be sure if it 
actually happened.

Did I stray off-topic here? ;-)

Regards,
Erwin Moller

-- 
"There are two ways of constructing a software design: One way is to 
make it so simple that there are obviously no deficiencies, and the 
other way is to make it so complicated that there are no obvious 
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

On Tue, 26 Jan 2010 16:32:33 +0100, Erwin Moller wrote:
> Reminds me of a fun story of that great, now gone, Richard Feynman.
>
> When studying physics the teacher decided to tease the class, filled 
> with freshmen, a little with a (famous) trickquestion:
> "What weights more: A kilogram of iron or a kilogram of feathers?"
>
> The smarter students smiled and answered: "They weight the same, since 
> you say they both have a mass of 1 kilogram."
> The teacher was of course happy and wanted to continue his lesson.
>
> Then Feynman said: "Well, it is not that simple. If I put a kilogram of 
> feathers on a balance it will show less weight than for a kilogram of 
> iron.".
> The teacher smiled knowingly, and started to explain it to that slow 
> student.
> But Feynman was right. :-)
>
> Feynman: "Look, A kilogram is a kilogram, no discussion there, so they 
> have the same mass. But you all seem to forget that a kilogram of 
> feathers displaces more air because it occupies a greater volume, so it 
>   experiences more upward presure, like a baloon held under water. Iron 
> displaces much less volume. So the kilogram of iron weights more. If you 
> put them both on an accurate balance you will see that a kilogram of 
> feather weights slightly less."
>
> I wonder how that teacher reacted. :-)
>
> As with many stories about Feynman, you  can never be sure if it 
> actually happened.

I'd hope it didn't, because it's wrong. It would be correct if the space
in the volume of feathers was filled with helium. But the balloon needs
to be held under water because it's filled with air, not water.

-- 
83. If I'm eating dinner with the hero, put poison in his goblet, then 
    have to leave the table for any reason, I will order new drinks for
    both of us instead of trying to decide whether or not to switch 
    with him. --Peter Anspach's list of things to do as an Evil Overlord

On Jan 26, 5:42=A0am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On Jan 26, 1:32=A0am, yawnmoth <terra1...@yahoo.com> wrote:
>
>
>
> > On Jan 25, 5:14=A0pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > On Jan 25, 5:30=A0pm, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > > On Jan 25, 6:30=A0am, Captain Paralytic <paul_laut...@yahoo.com> wr=
ote:
>
> > > > > On 23 Jan, 18:00, yawnmoth <terra1...@yahoo.com> wrote:
>
> > > > > > <?php
> > > > > > $size =3D 10000000;
> > > > > > $start =3D microtime(true);
> > > > > > for ($i =3D 0; $i < $size; $i++);
> > > > > > $elapsed =3D microtime(true) - $start;
> > > > > > ?>
>
> > > > > > <script>
> > > > > > start =3D (new Date()).getTime();
> > > > > > for (i =3D 0; i < <?php echo $size; ?>; i++);
> > > > > > elapsed =3D ((new Date()).getTime() - start) / 1000;
> > > > > > document.open();
> > > > > > document.writeln("javascript took " + elapsed + " seconds<br />=
");
> > > > > > document.writeln("php took <?php echo $elapsed; ?> seconds");
> > > > > > document.close();
> > > > > > </script>
>
> > > > > > On my Windows XP system, PHP 5.3.1 takes around 1.3 seconds and
> > > > > > Javascript takes about 0.05 seconds. =A0Why is Javascript so mu=
ch faster?
>
> > > > > Sounds similar to "Which is heavier, oil or water?"
>
> > > >http://www.google.com/search?q=3DWhich+is+heavier%2C+oil+or+water%3F
>
> > > > I wonder why no one has responded with anything as flippant as "My =
PHP
> > > > program is heavier than water!"...
>
> > > Most of the links in those search results are of course wrong.
>
> > I'm confused. =A0Most of the links imply it's lighter, which it is?
> > It's less dense (which is why it floats on water) and, if you have an
> > equal volume of water and oil, the water will weigh more?
>
> It is indeed "less dense", but the question "Which is heavier, oil or
> water?", is a nonsense question. 200g of oil is heavier than 100g of
> water.

It's an incomplete question, I'll grant that, but nonsense?  If you
assume you have the same amount of oil and water *by weight* the
answer is different then if you assume you have the same amount of oil
and water *by volume*.  And personally, it seems to me that volume is
implied, since the question's kinda pointless if you know the weights
in advance.

I mean, you can fill in the blanks any way you like.  eg.

"Which is heavier, [100L] oil or [100L] water?"

....or...

"Which is heavier, [100 newtons] oil or [100 newtons] water?"

Peter H. Coffin schreef:
> On Tue, 26 Jan 2010 16:32:33 +0100, Erwin Moller wrote:
>> Reminds me of a fun story of that great, now gone, Richard Feynman.
>>
>> When studying physics the teacher decided to tease the class, filled 
>> with freshmen, a little with a (famous) trickquestion:
>> "What weights more: A kilogram of iron or a kilogram of feathers?"
>>
>> The smarter students smiled and answered: "They weight the same, since 
>> you say they both have a mass of 1 kilogram."
>> The teacher was of course happy and wanted to continue his lesson.
>>
>> Then Feynman said: "Well, it is not that simple. If I put a kilogram of 
>> feathers on a balance it will show less weight than for a kilogram of 
>> iron.".
>> The teacher smiled knowingly, and started to explain it to that slow 
>> student.
>> But Feynman was right. :-)
>>
>> Feynman: "Look, A kilogram is a kilogram, no discussion there, so they 
>> have the same mass. But you all seem to forget that a kilogram of 
>> feathers displaces more air because it occupies a greater volume, so it 
>>   experiences more upward presure, like a baloon held under water. Iron 
>> displaces much less volume. So the kilogram of iron weights more. If you 
>> put them both on an accurate balance you will see that a kilogram of 
>> feather weights slightly less."
>>
>> I wonder how that teacher reacted. :-)
>>
>> As with many stories about Feynman, you  can never be sure if it 
>> actually happened.
> 
> I'd hope it didn't, because it's wrong. It would be correct if the space
> in the volume of feathers was filled with helium. But the balloon needs
> to be held under water because it's filled with air, not water.
> 

Helium?
Erm no, that has little to do with it.
It is all about volume displacement and thus the density (eg gram/liter) 
of the matter matters.
The density of feathers is lower than that of iron, it displaces more 
volume (air), which has weight too,  hence more upper pressure.

You should find the same effect in a room filled with only helium, or 
only hydrogen, or only plain air.
The upper pressure happens anywhere where there is gas. It is only more 
obvious when you try to hold down a baloon under water.

Try to measure the weight of a ballon filled with hydrogen on a balance, 
and you will see that the effect is real. :-) The bloody thing would 
float up instead of pressing the balance down, but still it has mass.

(I expect that serious weighting of an object on a scale should happen 
in vacuum to avoid this effect. Or correct for it by knowing the volume 
of the object.)

Regards,
Erwin Moller

-- 
"There are two ways of constructing a software design: One way is to 
make it so simple that there are obviously no deficiencies, and the 
other way is to make it so complicated that there are no obvious 
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

On Tue, 26 Jan 2010 17:45:27 +0100, Erwin Moller wrote:
> Peter H. Coffin schreef:
>> On Tue, 26 Jan 2010 16:32:33 +0100, Erwin Moller wrote:
>>> Reminds me of a fun story of that great, now gone, Richard Feynman.
>>>
>>> When studying physics the teacher decided to tease the class, filled 
>>> with freshmen, a little with a (famous) trickquestion:
>>> "What weights more: A kilogram of iron or a kilogram of feathers?"
>>>
>>> The smarter students smiled and answered: "They weight the same, since 
>>> you say they both have a mass of 1 kilogram."
>>> The teacher was of course happy and wanted to continue his lesson.
>>>
>>> Then Feynman said: "Well, it is not that simple. If I put a kilogram of 
>>> feathers on a balance it will show less weight than for a kilogram of 
>>> iron.".
>>> The teacher smiled knowingly, and started to explain it to that slow 
>>> student.
>>> But Feynman was right. :-)
>>>
>>> Feynman: "Look, A kilogram is a kilogram, no discussion there, so they 
>>> have the same mass. But you all seem to forget that a kilogram of 
>>> feathers displaces more air because it occupies a greater volume, so it 
>>>   experiences more upward presure, like a baloon held under water. Iron 
>>> displaces much less volume. So the kilogram of iron weights more. If you 
>>> put them both on an accurate balance you will see that a kilogram of 
>>> feather weights slightly less."
>>>
>>> I wonder how that teacher reacted. :-)
>>>
>>> As with many stories about Feynman, you  can never be sure if it 
>>> actually happened.
>> 
>> I'd hope it didn't, because it's wrong. It would be correct if the space
>> in the volume of feathers was filled with helium. But the balloon needs
>> to be held under water because it's filled with air, not water.
>> 
>
> Helium?
> Erm no, that has little to do with it.
> It is all about volume displacement and thus the density (eg gram/liter) 
> of the matter matters.
> The density of feathers is lower than that of iron, it displaces more 
> volume (air), which has weight too,  hence more upper pressure.

It displace air, WITH AIR, which weighs the same as what it is
displacing.

> You should find the same effect in a room filled with only helium, or 
> only hydrogen, or only plain air.
> The upper pressure happens anywhere where there is gas. It is only more 
> obvious when you try to hold down a baloon under water.

There isn't any "upper pressure" unless you've got something lighter
than the medium it's in. Feathers are not lighter than air, ergo there
is no "upper pressure". AIR is not lighter than air, ergo there is no
"upper pressure". The entire "upper pressure" is a description of
buoyancy and only works when whatever is buoyant is trapped. Otherwise
it all rapidly escapes until it reaches a level at which it is no longer
buoyant. Feathers don't trap air in any meaningful way, especially not
IN AIR, so no buoyancy issue obtains. 

> Try to measure the weight of a ballon filled with hydrogen on a balance, 
> and you will see that the effect is real. :-) The bloody thing would 
> float up instead of pressing the balance down, but still it has mass.
>
> (I expect that serious weighting of an object on a scale should happen 
> in vacuum to avoid this effect. Or correct for it by knowing the volume 
> of the object.)

A pile of feathers will both mass the same and weigh the same in an
atmosphere or in a vacuum.

-- 
81. If I am fighting with the hero atop a moving platform, have 
    disarmed him, and am about to finish him off and he glances behind 
    me and drops flat, I too will drop flat instead of quizzically 
    turning around to find out what he saw.  --Evil Overlord list

Peter H. Coffin wrote:
> On Tue, 26 Jan 2010 16:32:33 +0100, Erwin Moller wrote:
>> Reminds me of a fun story of that great, now gone, Richard Feynman.
>>
>> When studying physics the teacher decided to tease the class, filled 
>> with freshmen, a little with a (famous) trickquestion:
>> "What weights more: A kilogram of iron or a kilogram of feathers?"
>>
>> The smarter students smiled and answered: "They weight the same, since 
>> you say they both have a mass of 1 kilogram."
>> The teacher was of course happy and wanted to continue his lesson.
>>
>> Then Feynman said: "Well, it is not that simple. If I put a kilogram of 
>> feathers on a balance it will show less weight than for a kilogram of 
>> iron.".
>> The teacher smiled knowingly, and started to explain it to that slow 
>> student.
>> But Feynman was right. :-)
>>
>> Feynman: "Look, A kilogram is a kilogram, no discussion there, so they 
>> have the same mass. But you all seem to forget that a kilogram of 
>> feathers displaces more air because it occupies a greater volume, so it 
>>   experiences more upward presure, like a baloon held under water. Iron 
>> displaces much less volume. So the kilogram of iron weights more. If you 
>> put them both on an accurate balance you will see that a kilogram of 
>> feather weights slightly less."
>>
>> I wonder how that teacher reacted. :-)
>>
>> As with many stories about Feynman, you  can never be sure if it 
>> actually happened.
> 
> I'd hope it didn't, because it's wrong. It would be correct if the space
> in the volume of feathers was filled with helium. But the balloon needs
> to be held under water because it's filled with air, not water.
> 

Actually, Feynman was correct.  The weight on the scale includes the 
pressure of a column of air from the tray all the way to the 
stratosphere (and beyond).  If the displacement is the same, the weight 
of that column of air is the same and the scale balances.

However, in this case, the feathers displace more air than the lead, so 
there is slightly less downward pressure from the air (more upward 
pressure).  The difference is slight, but the scale would not balance.

Now, in a vacuum or a sealed container, you are correct - the scale 
would balance.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Peter H. Coffin" <hellsop@ninehells.com> wrote:

>On Tue, 26 Jan 2010 17:45:27 +0100, Erwin Moller wrote:
>> The density of feathers is lower than that of iron, it displaces more
>> volume (air), which has weight too,  hence more upper pressure.
 
> It displace air, WITH AIR, which weighs the same as what it is
> displacing.

So now we are really comparing 3 different things:

1 kg of iron
1 kg of air
1 kg of feathers (which might partly consist of air or surrond air
                  depending on how you look on it.)

> There isn't any "upper pressure" unless you've got something lighter
> than the medium it's in.

There is allways pressure in every direction. The pressure from above is
lower than the upper pressure from below as the atmospheric pressure as
well as water pressure increases with depth. As a sum you will get an
"upper pressure" which may or may not be bigger than the downward force
coming from the mass.

> Feathers are not lighter than air, ergo there is no "upper pressure".

The force upward from the "upper pressure" minus the "downward pressure"
is less than the force downward from the mass.

> A pile of feathers will both mass the same and weigh the same in an
> atmosphere or in a vacuum.

What would happen if you in air select 1 kg of air above one scale of
balance and place 1 kg of iron above another scale of balance? I bet
that in air the scales of balance would indicate a bigger weight for the
iron. What if you placed a feather in your 1 kg of air? Even though this
same volume will have a mass of more than 1 kg it probably still seems to
weigh less than your 1 kg of iron. What about 1 kg of feathers replacing
some of your 1 kg of air? It probably still weighs less than the iron.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Erwin Moller wrote:
> Peter H. Coffin schreef:
>> On Tue, 26 Jan 2010 16:32:33 +0100, Erwin Moller wrote:
>>> Reminds me of a fun story of that great, now gone, Richard Feynman.
>>>
>>> When studying physics the teacher decided to tease the class, filled 
>>> with freshmen, a little with a (famous) trickquestion:
>>> "What weights more: A kilogram of iron or a kilogram of feathers?"
>>>
>>> The smarter students smiled and answered: "They weight the same, 
>>> since you say they both have a mass of 1 kilogram."
>>> The teacher was of course happy and wanted to continue his lesson.
>>>
>>> Then Feynman said: "Well, it is not that simple. If I put a kilogram 
>>> of feathers on a balance it will show less weight than for a kilogram 
>>> of iron.".
>>> The teacher smiled knowingly, and started to explain it to that slow 
>>> student.
>>> But Feynman was right. :-)
>>>
>>> Feynman: "Look, A kilogram is a kilogram, no discussion there, so 
>>> they have the same mass. But you all seem to forget that a kilogram 
>>> of feathers displaces more air because it occupies a greater volume, 
>>> so it   experiences more upward presure, like a baloon held under 
>>> water. Iron displaces much less volume. So the kilogram of iron 
>>> weights more. If you put them both on an accurate balance you will 
>>> see that a kilogram of feather weights slightly less."
>>>
>>> I wonder how that teacher reacted. :-)
>>>
>>> As with many stories about Feynman, you  can never be sure if it 
>>> actually happened.
>>
>> I'd hope it didn't, because it's wrong. It would be correct if the space
>> in the volume of feathers was filled with helium. But the balloon needs
>> to be held under water because it's filled with air, not water.
>>
> 
> Helium?
> Erm no, that has little to do with it.
> It is all about volume displacement and thus the density (eg gram/liter) 
> of the matter matters.
> The density of feathers is lower than that of iron, it displaces more 
> volume (air), which has weight too,  hence more upper pressure.
> 
> You should find the same effect in a room filled with only helium, or 
> only hydrogen, or only plain air.
> The upper pressure happens anywhere where there is gas. It is only more 
> obvious when you try to hold down a baloon under water.
> 
> Try to measure the weight of a ballon filled with hydrogen on a balance, 
> and you will see that the effect is real. :-) The bloody thing would 
> float up instead of pressing the balance down, but still it has mass.
> 
> (I expect that serious weighting of an object on a scale should happen 
> in vacuum to avoid this effect. Or correct for it by knowing the volume 
> of the object.)
> 
> Regards,
> Erwin Moller
> 

Indeed. the thought experiment is to see whether a kilo of wood weights 
more than a kilo of stone, under water.

Peter H. Coffin wrote:
>
>> The density of feathers is lower than that of iron, it displaces more 
>> volume (air), which has weight too,  hence more upper pressure.
> 
> It displace air, WITH AIR, which weighs the same as what it is
> displacing.
> 
Unlike the other which displaces air with *something heavier*.

>

Peter H. Coffin wrote:

> There isn't any "upper pressure" unless you've got something lighter
> than the medium it's in. 

try weighing a lump of metal in the bath then

Perhaps neither? ... try http://rubyonrails.org server-side.

Jerry Stuckle schreef:

<snip>

> However, in this case, the feathers displace more air than the lead, so 
> there is slightly less downward pressure from the air (more upward 
> pressure).  The difference is slight, but the scale would not balance.
> 

Hi Jerry,

I was having a hard time finding the english word for "upper pressure" 
and translated it literally from Dutch (Opwaartse kracht).
I guess the right word was "upward pressure". Right?

Regards,
Erwin Moller





-- 
"There are two ways of constructing a software design: One way is to 
make it so simple that there are obviously no deficiencies, and the 
other way is to make it so complicated that there are no obvious 
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

Erwin Moller wrote:
> Jerry Stuckle schreef:
> 
> <snip>
> 
>> However, in this case, the feathers displace more air than the lead, 
>> so there is slightly less downward pressure from the air (more upward 
>> pressure).  The difference is slight, but the scale would not balance.
>>
> 
> Hi Jerry,
> 
> I was having a hard time finding the english word for "upper pressure" 
> and translated it literally from Dutch (Opwaartse kracht).
> I guess the right word was "upward pressure". Right?
> 
> Regards,
> Erwin Moller
> 
> 
> 
> 
> 

Yep, it would, Erwin.  I guess the best way to describe it would be: 
"Upward" would be the direction in which the pressure is directed, while 
"upper" would be the location of the pressure.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

In article <slrnhlu8bj.l3k.hellsop@abyss.ninehells.com>,
 "Peter H. Coffin" <hellsop@ninehells.com> wrote:

> There isn't any "upper pressure" unless you've got something lighter
> than the medium it's in. Feathers are not lighter than air, ergo there
> is no "upper pressure". AIR is not lighter than air, ergo there is no
> "upper pressure". The entire "upper pressure" is a description of
> buoyancy and only works when whatever is buoyant is trapped. Otherwise
> it all rapidly escapes until it reaches a level at which it is no longer
> buoyant. Feathers don't trap air in any meaningful way, especially not
> IN AIR, so no buoyancy issue obtains.

The trapping or otherwise of air is not the point.

> > Try to measure the weight of a ballon filled with hydrogen on a balance, 
> > and you will see that the effect is real. :-) The bloody thing would 
> > float up instead of pressing the balance down, but still it has mass.
> >
> > (I expect that serious weighting of an object on a scale should happen 
> > in vacuum to avoid this effect. Or correct for it by knowing the volume 
> > of the object.)
> 
> A pile of feathers will both mass the same and weigh the same in an
> atmosphere or in a vacuum.

You really haven't understood this at all, have you? The basic principle 
is that if you have a substance immersed in a fluid, *in a gravitational 
field* (and that was the important point), then it will experience an 
upward force equal to the weight (not mass) of fluid displaced. Note 
that the substance can itself be a fluid (a good example of this is salt 
water sinking in fresh water).

The above is true whatever the densities of the fluid and the substance 
involved. If the substance is lower density than the fluid, it will rise 
within the fluid (i.e. have negative weight), or float when it reaches 
the top. Otherwise, it will sink.

It might help to think of a kg (mass) of aluminium, and a kg of say 
gold. The kg of gold will be much smaller than the kg of aluminium, as 
it's much denser. So it will displace much less air. The kg of 
aluminium, being much larger, will displace more air and will experience 
a larger upward force. So it will weigh less in air.

The feathers are a red herring - they are probably made of keratin (like 
your finger nails), which I think is heavier than water (not sure about 
that though). Feathers just look light and bulky - but then they are 
designed to.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Tim Streater wrote:
>
> 
> The feathers are a red herring - they are probably made of keratin (like 
> your finger nails), which I think is heavier than water (not sure about 
> that though). Feathers just look light and bulky - but then they are 
> designed to.
> 
they contain a lot of air inside. Check a quill.

So which weighs more, a 1oz plastic ball that  is hollow, and  the same 
amount volume of the same plastic making a ball that is hollow but with 
holes in in as well.

And will it stay the same weight as it gets hotter?

..oO(yawnmoth)

>Also, when I made my PHP4 vs. PHP5 comment, I wasn't talking about for
>loops.  I was talking about in general.  In general, PHP4 is faster
>than PHP5.  At least by some methods of benchmarking.

Yes, 'some'. Maybe. If at all. But without more details such comparisons
don't mean anything, as said earlier. PHP 5 got a completely new engine,
there's not much left over from PHP 4. Additionally some years ago a new
memory management was introduced, which also increased the performance.
Then there are new extensions to cache the bytecode and many more things
that didn't exist in PHP 4.

So even without any benchmarking I think it's safe to assume that PHP 5
is faster than 4, not the other way round.

Micha

On Jan 27, 1:55=A0pm, Tim Streater <timstrea...@waitrose.com> wrote:
> In article <slrnhlu8bj.l3k.hell...@abyss.ninehells.com>,
> =A0"Peter H. Coffin" <hell...@ninehells.com> wrote:
>
> > There isn't any "upper pressure" unless you've got something lighter
> > than the medium it's in. Feathers are not lighter than air, ergo there
> > is no "upper pressure". AIR is not lighter than air, ergo there is no
> > "upper pressure". The entire "upper pressure" is a description of
> > buoyancy and only works when whatever is buoyant is trapped. Otherwise
> > it all rapidly escapes until it reaches a level at which it is no longe=
r
> > buoyant. Feathers don't trap air in any meaningful way, especially not
> > IN AIR, so no buoyancy issue obtains.
>
> The trapping or otherwise of air is not the point.
>
> > > Try to measure the weight of a ballon filled with hydrogen on a balan=
ce,
> > > and you will see that the effect is real. :-) The bloody thing would
> > > float up instead of pressing the balance down, but still it has mass.
>
> > > (I expect that serious weighting of an object on a scale should happe=
n
> > > in vacuum to avoid this effect. Or correct for it by knowing the volu=
me
> > > of the object.)
>
> > A pile of feathers will both mass the same and weigh the same in an
> > atmosphere or in a vacuum.
>
> You really haven't understood this at all, have you? The basic principle
> is that if you have a substance immersed in a fluid, *in a gravitational
> field* (and that was the important point), then it will experience an
> upward force equal to the weight (not mass) of fluid displaced. Note
> that the substance can itself be a fluid (a good example of this is salt
> water sinking in fresh water).
>
> The above is true whatever the densities of the fluid and the substance
> involved. If the substance is lower density than the fluid, it will rise
> within the fluid (i.e. have negative weight), or float when it reaches
> the top. Otherwise, it will sink.
>
> It might help to think of a kg (mass) of aluminium, and a kg of say
> gold. The kg of gold will be much smaller than the kg of aluminium, as
> it's much denser. So it will displace much less air. The kg of
> aluminium, being much larger, will displace more air and will experience
> a larger upward force. So it will weigh less in air.
>
> The feathers are a red herring - they are probably made of keratin (like
> your finger nails), which I think is heavier than water (not sure about
> that though). Feathers just look light and bulky - but then they are
> designed to.
>

So... Which is denser, php or javascript?

On 27/01/2010 14:37, The Natural Philosopher wrote:
> Tim Streater wrote:
>>
>>
>> The feathers are a red herring - they are probably made of keratin
>> (like your finger nails), which I think is heavier than water (not
>> sure about that though). Feathers just look light and bulky - but then
>> they are designed to.
>>
> they contain a lot of air inside. Check a quill.

So?

> So which weighs more, a 1oz plastic ball that is hollow, and the same
> amount volume of the same plastic making a ball that is hollow but with
> holes in in as well.

By hollow, do you mean there's a vacuum inside? If there's air inside, 
then it's gonna depend on whether it's at the same pressure as outside 
or not. If the pressure's the same, it's the same as the holed ball. If 
it's greater, then it's heavier and vice versa (if you like your vice 
versa).

> And will it stay the same weight as it gets hotter?

As what gets hotter?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

Mark Smith wrote:
> On Jan 27, 1:55 pm, Tim Streater <timstrea...@waitrose.com> wrote:
>> In article <slrnhlu8bj.l3k.hell...@abyss.ninehells.com>,
>>  "Peter H. Coffin" <hell...@ninehells.com> wrote:
>>
>>> There isn't any "upper pressure" unless you've got something lighter
>>> than the medium it's in. Feathers are not lighter than air, ergo there
>>> is no "upper pressure". AIR is not lighter than air, ergo there is no
>>> "upper pressure". The entire "upper pressure" is a description of
>>> buoyancy and only works when whatever is buoyant is trapped. Otherwise
>>> it all rapidly escapes until it reaches a level at which it is no longer
>>> buoyant. Feathers don't trap air in any meaningful way, especially not
>>> IN AIR, so no buoyancy issue obtains.
>> The trapping or otherwise of air is not the point.
>>
>>>> Try to measure the weight of a ballon filled with hydrogen on a balance,
>>>> and you will see that the effect is real. :-) The bloody thing would
>>>> float up instead of pressing the balance down, but still it has mass.
>>>> (I expect that serious weighting of an object on a scale should happen
>>>> in vacuum to avoid this effect. Or correct for it by knowing the volume
>>>> of the object.)
>>> A pile of feathers will both mass the same and weigh the same in an
>>> atmosphere or in a vacuum.
>> You really haven't understood this at all, have you? The basic principle
>> is that if you have a substance immersed in a fluid, *in a gravitational
>> field* (and that was the important point), then it will experience an
>> upward force equal to the weight (not mass) of fluid displaced. Note
>> that the substance can itself be a fluid (a good example of this is salt
>> water sinking in fresh water).
>>
>> The above is true whatever the densities of the fluid and the substance
>> involved. If the substance is lower density than the fluid, it will rise
>> within the fluid (i.e. have negative weight), or float when it reaches
>> the top. Otherwise, it will sink.
>>
>> It might help to think of a kg (mass) of aluminium, and a kg of say
>> gold. The kg of gold will be much smaller than the kg of aluminium, as
>> it's much denser. So it will displace much less air. The kg of
>> aluminium, being much larger, will displace more air and will experience
>> a larger upward force. So it will weigh less in air.
>>
>> The feathers are a red herring - they are probably made of keratin (like
>> your finger nails), which I think is heavier than water (not sure about
>> that though). Feathers just look light and bulky - but then they are
>> designed to.
>>
> 
> So... Which is denser, php or javascript?
I was going to say javascript, but its full of hot air..

Tim Streater wrote:
> On 27/01/2010 14:37, The Natural Philosopher wrote:
>> Tim Streater wrote:
>>>
>>>
>>> The feathers are a red herring - they are probably made of keratin
>>> (like your finger nails), which I think is heavier than water (not
>>> sure about that though). Feathers just look light and bulky - but then
>>> they are designed to.
>>>
>> they contain a lot of air inside. Check a quill.
> 
> So?
> 
>> So which weighs more, a 1oz plastic ball that is hollow, and the same
>> amount volume of the same plastic making a ball that is hollow but with
>> holes in in as well.
> 
> By hollow, do you mean there's a vacuum inside? If there's air inside, 
> then it's gonna depend on whether it's at the same pressure as outside 
> or not. If the pressure's the same, it's the same as the holed ball. If 
> it's greater, then it's heavier and vice versa (if you like your vice 
> versa).
> 

Ah. So if I put it in water and its made of say aluminium., both will float?

>> And will it stay the same weight as it gets hotter?
> 
> As what gets hotter?
> 
The ball.

On 27/01/2010 22:14, The Natural Philosopher wrote:
> Tim Streater wrote:
>> On 27/01/2010 14:37, The Natural Philosopher wrote:
>>> Tim Streater wrote:
>>>>
>>>>
>>>> The feathers are a red herring - they are probably made of keratin
>>>> (like your finger nails), which I think is heavier than water (not
>>>> sure about that though). Feathers just look light and bulky - but then
>>>> they are designed to.
>>>>
>>> they contain a lot of air inside. Check a quill.
>>
>> So?
>>
>>> So which weighs more, a 1oz plastic ball that is hollow, and the same
>>> amount volume of the same plastic making a ball that is hollow but with
>>> holes in in as well.
>>
>> By hollow, do you mean there's a vacuum inside? If there's air inside,
>> then it's gonna depend on whether it's at the same pressure as outside
>> or not. If the pressure's the same, it's the same as the holed ball.
>> If it's greater, then it's heavier and vice versa (if you like your
>> vice versa).
>>
>
> Ah. So if I put it in water and its made of say aluminium., both will
> float?

Such a shining wit. If you put both in water, one will have air in it 
and the other will have water in it. You can deduce the rest for yourself.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

Tim Streater wrote:
> On 27/01/2010 22:14, The Natural Philosopher wrote:
>> Tim Streater wrote:
>>> On 27/01/2010 14:37, The Natural Philosopher wrote:
>>>> Tim Streater wrote:
>>>>>
>>>>>
>>>>> The feathers are a red herring - they are probably made of keratin
>>>>> (like your finger nails), which I think is heavier than water (not
>>>>> sure about that though). Feathers just look light and bulky - but then
>>>>> they are designed to.
>>>>>
>>>> they contain a lot of air inside. Check a quill.
>>>
>>> So?
>>>
>>>> So which weighs more, a 1oz plastic ball that is hollow, and the same
>>>> amount volume of the same plastic making a ball that is hollow but with
>>>> holes in in as well.
>>>
>>> By hollow, do you mean there's a vacuum inside? If there's air inside,
>>> then it's gonna depend on whether it's at the same pressure as outside
>>> or not. If the pressure's the same, it's the same as the holed ball.
>>> If it's greater, then it's heavier and vice versa (if you like your
>>> vice versa).
>>>
>>
>> Ah. So if I put it in water and its made of say aluminium., both will
>> float?
> 
> Such a shining wit. If you put both in water, one will have air in it 
> and the other will have water in it. You can deduce the rest for yourself.
> 
you still don't get it do you?

On Jan 26, 12:37=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Peter H. Coffin wrote:
> > On Tue, 26 Jan 2010 16:32:33 +0100, Erwin Moller wrote:
> >> Reminds me of a fun story of that great, now gone, Richard Feynman.
>
> >> When studying physics the teacher decided to tease the class, filled
> >> with freshmen, a little with a (famous) trickquestion:
> >> "What weights more: A kilogram of iron or a kilogram of feathers?"
>
> >> The smarter students smiled and answered: "They weight the same, since
> >> you say they both have a mass of 1 kilogram."
> >> The teacher was of course happy and wanted to continue his lesson.
>
> >> Then Feynman said: "Well, it is not that simple. If I put a kilogram o=
f
> >> feathers on a balance it will show less weight than for a kilogram of
> >> iron.".
> >> The teacher smiled knowingly, and started to explain it to that slow
> >> student.
> >> But Feynman was right. :-)
>
> >> Feynman: "Look, A kilogram is a kilogram, no discussion there, so they
> >> have the same mass. But you all seem to forget that a kilogram of
> >> feathers displaces more air because it occupies a greater volume, so i=
t
> >> =A0 experiences more upward presure, like a baloon held under water. I=
ron
> >> displaces much less volume. So the kilogram of iron weights more. If y=
ou
> >> put them both on an accurate balance you will see that a kilogram of
> >> feather weights slightly less."
>
> >> I wonder how that teacher reacted. :-)
>
> >> As with many stories about Feynman, you =A0can never be sure if it
> >> actually happened.
>
> > I'd hope it didn't, because it's wrong. It would be correct if the spac=
e
> > in the volume of feathers was filled with helium. But the balloon needs
> > to be held under water because it's filled with air, not water.
>
> Actually, Feynman was correct. =A0The weight on the scale includes the
> pressure of a column of air from the tray all the way to the
> stratosphere (and beyond). =A0If the displacement is the same, the weight
> of that column of air is the same and the scale balances.
>
> However, in this case, the feathers displace more air than the lead, so
> there is slightly less downward pressure from the air (more upward
> pressure). =A0The difference is slight, but the scale would not balance.

So, does this mean that they would weigh the same if the feathers were
distributed to have the same average height--ie, the volume of air per
square inch above and below the feathers is the same as the iron?

I have some vague inclination that this relates to the one thing I
retained from fluid dynamics: Given two water columns of equal height
and different diameters, the water pressure will be the same at any
given depth....

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/01/10 01:43, matt wrote:
> On Jan 26, 12:37 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Peter H. Coffin wrote:
>>> On Tue, 26 Jan 2010 16:32:33 +0100, Erwin Moller wrote:
>>>> Reminds me of a fun story of that great, now gone, Richard Feynman.
>>
>>>> When studying physics the teacher decided to tease the class, filled
>>>> with freshmen, a little with a (famous) trickquestion:
>>>> "What weights more: A kilogram of iron or a kilogram of feathers?"
>>
>>>> The smarter students smiled and answered: "They weight the same, since
>>>> you say they both have a mass of 1 kilogram."
>>>> The teacher was of course happy and wanted to continue his lesson.
>>
>>>> Then Feynman said: "Well, it is not that simple. If I put a kilogram of
>>>> feathers on a balance it will show less weight than for a kilogram of
>>>> iron.".
>>>> The teacher smiled knowingly, and started to explain it to that slow
>>>> student.
>>>> But Feynman was right. :-)
>>
>>>> Feynman: "Look, A kilogram is a kilogram, no discussion there, so they
>>>> have the same mass. But you all seem to forget that a kilogram of
>>>> feathers displaces more air because it occupies a greater volume, so it
>>>>   experiences more upward presure, like a baloon held under water. Iron
>>>> displaces much less volume. So the kilogram of iron weights more. If you
>>>> put them both on an accurate balance you will see that a kilogram of
>>>> feather weights slightly less."
>>
>>>> I wonder how that teacher reacted. :-)
>>
>>>> As with many stories about Feynman, you  can never be sure if it
>>>> actually happened.
>>
>>> I'd hope it didn't, because it's wrong. It would be correct if the space
>>> in the volume of feathers was filled with helium. But the balloon needs
>>> to be held under water because it's filled with air, not water.
>>
>> Actually, Feynman was correct.  The weight on the scale includes the
>> pressure of a column of air from the tray all the way to the
>> stratosphere (and beyond).  If the displacement is the same, the weight
>> of that column of air is the same and the scale balances.
>>
>> However, in this case, the feathers displace more air than the lead, so
>> there is slightly less downward pressure from the air (more upward
>> pressure).  The difference is slight, but the scale would not balance.
> 
> So, does this mean that they would weigh the same if the feathers were
> distributed to have the same average height--ie, the volume of air per
> square inch above and below the feathers is the same as the iron?

If you remove the air completely, then yes.

> 
> I have some vague inclination that this relates to the one thing I
> retained from fluid dynamics: Given two water columns of equal height
> and different diameters, the water pressure will be the same at any
> given depth....
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkthOJ8ACgkQE++2Zdc7EteRkACfbRqcz3eYctqeRJrssE7H/AKA
degAoKCGHlxbKR5l10WjdN9BxKzodOhY
=jHqi
-----END PGP SIGNATURE-----

Johannes Ke�ler <mail@bananas-playground.net> wrote:
>> So, does this mean that they would weigh the same if the feathers were
>> distributed to have the same average height--ie, the volume of air per
>> square inch above and below the feathers is the same as the iron?
> 
> If you remove the air completely, then yes.

Only removing the air in the feathers would probably not be enogh. My
guess is that some more kind of compression would be necessary to make the
same mass of feathers fit into the same volume as iron with said mass.

What we are really talking about is compression of feathers to give them
the same density as iron. That is the sum of the mass of all the molecules
in the feathers should equal the sum of the mass of all iron molecules
within the same volume. I don't know exactly what kind of molecules
feathers are built of, but I don't think it would be possible to compress
them that much. For more info about molecular mass and molar mass see
http://en.wikipedia.org/wiki/Molecular_mass
and
http://en.wikipedia.org/wiki/Molar_mass

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

On 28/01/2010 07:30, Henrik Carlqvist wrote:
> Johannes Ke�ler<mail@bananas-playground.net>  wrote:
>>> So, does this mean that they would weigh the same if the feathers were
>>> distributed to have the same average height--ie, the volume of air per
>>> square inch above and below the feathers is the same as the iron?
>>
>> If you remove the air completely, then yes.
>
> Only removing the air in the feathers would probably not be enogh. My
> guess is that some more kind of compression would be necessary to make the
> same mass of feathers fit into the same volume as iron with said mass.
>
> What we are really talking about is compression of feathers to give them
> the same density as iron. That is the sum of the mass of all the molecules
> in the feathers should equal the sum of the mass of all iron molecules
> within the same volume. I don't know exactly what kind of molecules
> feathers are built of, but I don't think it would be possible to compress
> them that much.

The fact that feathers seem to occupy a large volume of have lots of air 
associated with them, is irrelevant. What counts is what they are made 
of, which will be a protein like chitin or keratin. These have a density 
*much* *less* that iron, so you will *never* be able to compress them to 
have the same density (outside a black hole or similar, that is) as iron.

The question above about "distributing the feathers to have the same 
average height" is meaningless.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

On Jan 28, 6:00=A0am, Tim Streater <timstrea...@waitrose.com> wrote:
> On 28/01/2010 07:30, Henrik Carlqvist wrote:
>
>
>
> > Johannes Ke=DFler<m...@bananas-playground.net> =A0wrote:
> >>> So, does this mean that they would weigh the same if the feathers wer=
e
> >>> distributed to have the same average height--ie, the volume of air pe=
r
> >>> square inch above and below the feathers is the same as the iron?
>
> >> If you remove the air completely, then yes.
>
> > Only removing the air in the feathers would probably not be enogh. My
> > guess is that some more kind of compression would be necessary to make =
the
> > same mass of feathers fit into the same volume as iron with said mass.
>
> > What we are really talking about is compression of feathers to give the=
m
> > the same density as iron. That is the sum of the mass of all the molecu=
les
> > in the feathers should equal the sum of the mass of all iron molecules
> > within the same volume. I don't know exactly what kind of molecules
> > feathers are built of, but I don't think it would be possible to compre=
ss
> > them that much.
>
> The fact that feathers seem to occupy a large volume of have lots of air
> associated with them, is irrelevant. What counts is what they are made
> of, which will be a protein like chitin or keratin. These have a density
> *much* *less* that iron, so you will *never* be able to compress them to
> have the same density (outside a black hole or similar, that is) as iron.
>
> The question above about "distributing the feathers to have the same
> average height" is meaningless.

Tim, can you expand on this?  I was under the impression that the
feathers would be lighter mostly because they displace the air above
them (ie, less downward pressure).  If the feathers are exposed to the
same average atmospheric pressure above and below them as the iron,
that would seem to negate the theory of air displacement.

You could rephrase my question as such: which is heavier, a 400 ft
iron rod lying flat, or the same rod standing on end?  Now, it's not a
question of displacement of air (as the same rod clearly displaces the
same quantity), but rather whether or not the lower pressure at 400 ft
affects the equation.

From another angle, in either example--disregarding for a moment my
equal height proposal, if the center of mass of one object is further
from the center of the earth, wouldn't the gravitational effect of the
"taller" object be slightly less?

On a more personal note, I'd appreciate you not dismissing my question
offhand as "meaningless."  I don't claim to be a physicist, and I was
asking a legitimate question based on the arguments presented--not
attempting in any way to claim a truism.  These things interest me and
like most people here, I'm here to learn.  If I ask a question that
doesn't have merit, please do me the courtesy of explaining why or say
nothing at all.  Thanks.

I certainly wasn't talking about compressing the feathers to the same
density (ergo volume) as the iron--which clearly would have to occur
on a molecular level.  Not sure how my question tangent'ed off in that
direction...

matt wrote:
> On Jan 28, 6:00 am, Tim Streater <timstrea...@waitrose.com> wrote:
>> On 28/01/2010 07:30, Henrik Carlqvist wrote:
>>
>>
>>
>>> Johannes Keßler<m...@bananas-playground.net>  wrote:
>>>>> So, does this mean that they would weigh the same if the feathers were
>>>>> distributed to have the same average height--ie, the volume of air per
>>>>> square inch above and below the feathers is the same as the iron?
>>>> If you remove the air completely, then yes.
>>> Only removing the air in the feathers would probably not be enogh. My
>>> guess is that some more kind of compression would be necessary to make the
>>> same mass of feathers fit into the same volume as iron with said mass.
>>> What we are really talking about is compression of feathers to give them
>>> the same density as iron. That is the sum of the mass of all the molecules
>>> in the feathers should equal the sum of the mass of all iron molecules
>>> within the same volume. I don't know exactly what kind of molecules
>>> feathers are built of, but I don't think it would be possible to compress
>>> them that much.
>> The fact that feathers seem to occupy a large volume of have lots of air
>> associated with them, is irrelevant. What counts is what they are made
>> of, which will be a protein like chitin or keratin. These have a density
>> *much* *less* that iron, so you will *never* be able to compress them to
>> have the same density (outside a black hole or similar, that is) as iron.
>>
>> The question above about "distributing the feathers to have the same
>> average height" is meaningless.
> 
> Tim, can you expand on this?  I was under the impression that the
> feathers would be lighter mostly because they displace the air above
> them (ie, less downward pressure).  If the feathers are exposed to the
> same average atmospheric pressure above and below them as the iron,
> that would seem to negate the theory of air displacement.
> 
buoyancy is an upward force which is equal to the net weight of gas or 
fluid displaced. Which takes care of air density variations with height. 
Its the weight of the air at that height.

In the case of a feather, if we weigh it in vacuo, then any air trapped 
inside it, is also weighed,ergo the air constitutes as much to the mass 
of the feather as the keratin.

Therefore it will lighten by and amount equal to the total volume 
displaced if it is put in air. In the limit, if the keratin is next to 
bugger all compared with the weight of air, it will be almost 
weightless. A bubble of air floats in air. If it could contain perfect 
vacuum without collapsing, it might be lighter than air.

Arguably its correct to take the air as 'part of the feather' because to 
accelerate it, you need to accelerate the air inside as well. So in the 
limit, mass being define by acceleration without recourse to gravity, 
the feather weighs in vacuo, its keratin plus its air, and acquires a 
buoyancy of its TOTAL volume when placed in air.

A helium filled airship weighs less than zero. BUT it for sure has mass. 
so which weighs more, 400 tons of helium filled airship, or 400 tons of 
steel?

Its a clear decoupling of mass, as defined by inertial systems, and 
weight, as measured on a typical scale.

scales don't measure mass, they measure force. Force depends on the 
buoyancy of the object, the and the putative local gravitational field.

And mass is not constant either, hot objects are imperceptibly more 
massive than cold ones.E=mc^2 etc etc. A fully charged battery is a 
femto-gram heavier than a discharged one.


To answer your question a 400ft rod on end will weigh slightly more than 
one on its side, there being very slightly less air to displace 400ft up.

I remember a demonstration at a radio observatory than runs radar dishes 
along rails. Dead straight flat rails. But put a spirit level on one end 
of the rail, and its out 'We need to effectively raise each end of the 
track 1/4" to allow for the Earth's curvature'. Small, but measurable.

On Thu, 28 Jan 2010 13:30:35 +0000, The Natural Philosopher wrote:
> matt wrote:
>> On Jan 28, 6:00 am, Tim Streater <timstrea...@waitrose.com> wrote:
>>> On 28/01/2010 07:30, Henrik Carlqvist wrote:
>>>
>>>
>>>
>>>> Johannes Ke�ler<m...@bananas-playground.net>  wrote:
>>>>>> So, does this mean that they would weigh the same if the feathers were
>>>>>> distributed to have the same average height--ie, the volume of air per
>>>>>> square inch above and below the feathers is the same as the iron?
>>>>> If you remove the air completely, then yes.
>>>> Only removing the air in the feathers would probably not be enogh. My
>>>> guess is that some more kind of compression would be necessary to make the
>>>> same mass of feathers fit into the same volume as iron with said mass.
>>>> What we are really talking about is compression of feathers to give them
>>>> the same density as iron. That is the sum of the mass of all the molecules
>>>> in the feathers should equal the sum of the mass of all iron molecules
>>>> within the same volume. I don't know exactly what kind of molecules
>>>> feathers are built of, but I don't think it would be possible to compress
>>>> them that much.
>>> The fact that feathers seem to occupy a large volume of have lots of air
>>> associated with them, is irrelevant. What counts is what they are made
>>> of, which will be a protein like chitin or keratin. These have a density
>>> *much* *less* that iron, so you will *never* be able to compress them to
>>> have the same density (outside a black hole or similar, that is) as iron.
>>>
>>> The question above about "distributing the feathers to have the same
>>> average height" is meaningless.
>> 
>> Tim, can you expand on this?  I was under the impression that the
>> feathers would be lighter mostly because they displace the air above
>> them (ie, less downward pressure).  If the feathers are exposed to the
>> same average atmospheric pressure above and below them as the iron,
>> that would seem to negate the theory of air displacement.
>> 
> buoyancy is an upward force which is equal to the net weight of gas or 
> fluid displaced. Which takes care of air density variations with height. 
> Its the weight of the air at that height.
>
> In the case of a feather, if we weigh it in vacuo, then any air trapped 
> inside it, is also weighed,ergo the air constitutes as much to the mass 
> of the feather as the keratin.
>
> Therefore it will lighten by and amount equal to the total volume 
> displaced if it is put in air. In the limit, if the keratin is next to 
> bugger all compared with the weight of air, it will be almost 
> weightless. A bubble of air floats in air. If it could contain perfect 
> vacuum without collapsing, it might be lighter than air.
>
> Arguably its correct to take the air as 'part of the feather' because to 
> accelerate it, you need to accelerate the air inside as well. So in the 
> limit, mass being define by acceleration without recourse to gravity, 
> the feather weighs in vacuo, its keratin plus its air, and acquires a 
> buoyancy of its TOTAL volume when placed in air.
>
> A helium filled airship weighs less than zero. BUT it for sure has mass. 
> so which weighs more, 400 tons of helium filled airship, or 400 tons of 
> steel?
>
> Its a clear decoupling of mass, as defined by inertial systems, and 
> weight, as measured on a typical scale.
>
> scales don't measure mass, they measure force. Force depends on the 
> buoyancy of the object, the and the putative local gravitational field.
>
> And mass is not constant either, hot objects are imperceptibly more 
> massive than cold ones.E=mc^2 etc etc. A fully charged battery is a 
> femto-gram heavier than a discharged one.

Exactly. You've got to measure it, in a way that's relevant to what
you're testing. Or (I suppose) *not* relevant to what you're testing.

In the case of hte experiment, either the two things are being measured
essentially similarly to how they're being done IN the experiment
(STP-ish, balanced against calibration), in which case the weight are
going to be equal because the thing that's being hypothesized to make a
difference is already factored in, or they're being measured some other
way and we've got no way of knowing how those unknown conditions will
affect our conclusion. Maybe the feathers were massed out on a balance
in an argon atmosphere, in which case the pile of feathers would be
HEAVIER than the iron once moved to normal air. So either they're the
same, or the answer isn't knowable as-is. 

-- 
64. I will see a competent psychiatrist and get cured of all extremely 
    unusual phobias and bizarre compulsive habits which could prove to 
    be a disadvantage.
	--Peter Anspach's list of things to do as an Evil Overlord

On 28/01/2010 12:30, matt wrote:
> On Jan 28, 6:00 am, Tim Streater<timstrea...@waitrose.com>  wrote:
>> On 28/01/2010 07:30, Henrik Carlqvist wrote:
>>
>>
>>
>>> Johannes Ke�ler<m...@bananas-playground.net>    wrote:
>>>>> So, does this mean that they would weigh the same if the feathers were
>>>>> distributed to have the same average height--ie, the volume of air per
>>>>> square inch above and below the feathers is the same as the iron?
>>
>>>> If you remove the air completely, then yes.
>>
>>> Only removing the air in the feathers would probably not be enogh. My
>>> guess is that some more kind of compression would be necessary to make the
>>> same mass of feathers fit into the same volume as iron with said mass.
>>
>>> What we are really talking about is compression of feathers to give them
>>> the same density as iron. That is the sum of the mass of all the molecules
>>> in the feathers should equal the sum of the mass of all iron molecules
>>> within the same volume. I don't know exactly what kind of molecules
>>> feathers are built of, but I don't think it would be possible to compress
>>> them that much.
>>
>> The fact that feathers seem to occupy a large volume of have lots of air
>> associated with them, is irrelevant. What counts is what they are made
>> of, which will be a protein like chitin or keratin. These have a density
>> *much* *less* that iron, so you will *never* be able to compress them to
>> have the same density (outside a black hole or similar, that is) as iron.
>>
>> The question above about "distributing the feathers to have the same
>> average height" is meaningless.
>
> Tim, can you expand on this?  I was under the impression that the
> feathers would be lighter mostly because they displace the air above
> them (ie, less downward pressure).  If the feathers are exposed to the
> same average atmospheric pressure above and below them as the iron,
> that would seem to negate the theory of air displacement.
>
> You could rephrase my question as such: which is heavier, a 400 ft
> iron rod lying flat, or the same rod standing on end?  Now, it's not a
> question of displacement of air (as the same rod clearly displaces the
> same quantity), but rather whether or not the lower pressure at 400 ft
> affects the equation.

OK - I see what you're getting at. For the examples we have all been 
looking at, say a kg of iron vs. a kg of feathers, the altitude issue, 
while valid, is much smaller. Certainly, if your iron rod was 400ft long 
or better still a mile long :-) then at whatever orientation it 
displaces the same volume, but a different weight of air. However, you 
then have to take into account that parts of the iron rod are further 
from the centre of the earth as you point out below.

And, it gets worse :-) as there is also the fact that the top of the 
vertical mile-long rod will be spinning round the centre of the earth 
faster than the bottom - and so there will be an outward force due to 
the centripetal force (you weigh less at the equator than the poles for 
that reason - not because you're a mile high but that you are spinning 
faster).

I think the best way to grasp the principles is to keep the example 
simple and just take small amounts of different materials at the same 
altitude. The same mass of iron and feathers displace different amounts 
of air, quite simply. The fact that the feathers may contain air won't 
affect that if the air is at the same pressure as the outside.

(I'm not convinced, anyway, that the tubes in feathers are airtight 
(need a biologist here), because that might cause problems for 
high-flying birds - there are some birds whose migration path takes them 
over the Himalayas.)

Feathers only seem "light" because they form a low-density mass with a 
large surface area. A feather falls slowly because of its large surface 
area which gives it a low terminal velocity. If you compress all the air 
out, including that inside the feather shafts, then you have a solid 
mass of keratin which is just another lowish-density substance. But that 
compressed mass will displace just as much air as the original feathers.

If you get into a full bath, the water will overflow to allow you to, 
however gently you do it. In a less full bath, the resulting water level 
will be higher - you've moved some water "uphill". Gravity is trying to 
pull it downhill again - which is the origin of the upwards force on you.

> From another angle, in either example--disregarding for a moment my
> equal height proposal, if the center of mass of one object is further
> from the center of the earth, wouldn't the gravitational effect of the
> "taller" object be slightly less?
>
> On a more personal note, I'd appreciate you not dismissing my question
> offhand as "meaningless."  I don't claim to be a physicist, and I was
> asking a legitimate question based on the arguments presented--not
> attempting in any way to claim a truism.  These things interest me and
> like most people here, I'm here to learn.  If I ask a question that
> doesn't have merit, please do me the courtesy of explaining why or say
> nothing at all.  Thanks.

Yes, I'm sorry about that. Funnily enough, my first reaction was ruder 
but then I decided that was inappropriate, but it still came out hasher 
than I intended.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

On 28/01/2010 13:30, The Natural Philosopher wrote:
> matt wrote:
>> On Jan 28, 6:00 am, Tim Streater <timstrea...@waitrose.com> wrote:
>>> On 28/01/2010 07:30, Henrik Carlqvist wrote:
>>>
>>>
>>>
>>>> Johannes Keßler<m...@bananas-playground.net> wrote:
>>>>>> So, does this mean that they would weigh the same if the feathers
>>>>>> were
>>>>>> distributed to have the same average height--ie, the volume of air
>>>>>> per
>>>>>> square inch above and below the feathers is the same as the iron?
>>>>> If you remove the air completely, then yes.
>>>> Only removing the air in the feathers would probably not be enogh. My
>>>> guess is that some more kind of compression would be necessary to
>>>> make the
>>>> same mass of feathers fit into the same volume as iron with said mass.
>>>> What we are really talking about is compression of feathers to give
>>>> them
>>>> the same density as iron. That is the sum of the mass of all the
>>>> molecules
>>>> in the feathers should equal the sum of the mass of all iron molecules
>>>> within the same volume. I don't know exactly what kind of molecules
>>>> feathers are built of, but I don't think it would be possible to
>>>> compress
>>>> them that much.
>>> The fact that feathers seem to occupy a large volume of have lots of air
>>> associated with them, is irrelevant. What counts is what they are made
>>> of, which will be a protein like chitin or keratin. These have a density
>>> *much* *less* that iron, so you will *never* be able to compress them to
>>> have the same density (outside a black hole or similar, that is) as
>>> iron.
>>>
>>> The question above about "distributing the feathers to have the same
>>> average height" is meaningless.
>>
>> Tim, can you expand on this? I was under the impression that the
>> feathers would be lighter mostly because they displace the air above
>> them (ie, less downward pressure). If the feathers are exposed to the
>> same average atmospheric pressure above and below them as the iron,
>> that would seem to negate the theory of air displacement.
>>
> buoyancy is an upward force which is equal to the net weight of gas or
> fluid displaced. Which takes care of air density variations with height.
> Its the weight of the air at that height.

Yes.

> In the case of a feather, if we weigh it in vacuo, then any air trapped
> inside it, is also weighed, ergo the air constitutes as much to the mass
> of the feather as the keratin.

Yes, if the feather has airtight compartments (in the feather shaft, 
say). I'm not convinced about that aspect but perhaps a biologist could 
comment (a quick look at the entry for feather in Wikipedia didn't 
elucidate).

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

The Natural Philosopher <tnp@invalid.invalid> wrote:
> To answer your question a 400ft rod on end will weigh slightly more than 
> one on its side, there being very slightly less air to displace 400ft up.

That answer might be true for some other reasons like gravity distances
and centrifugal forces.

However the fact that there is less air 400ft up only affects the air
pressure. The air pressure is a linear function of height, or rather
depth. The difference in air pressure between the upper side and the lower
side of the rod only depends upon the difference in height of the upper
side and the lower side. This difference becomes a constant if you are
moving the rod up and down within the atmosphere.

Now if the rod is standing the difference is big but the areas affected by
the pressure is small. If the rod is laying the difference is small but
the area is big. If you multiply the difference in pressure with the area
affected you will find that it becomes a constant. Simple multiplication
might not be possible for a horizontal round rod, you might have to
integrate the function of pressure over the horizontal area, but still it
will be a constant.

You could also think of it this way: What would happen if you cut the rod
into two halfes and moved the rods to different heights? As long as we are
only concerned about air pressure their weights will be the same and the
sum of the halves weights will equal the weight of the entire rod. This is
also true if one rod is placed in a horisontal position.

However if we start thinking about gravity distances and centrifugal
forces the weight will be affected by the height and the position on earth.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

On 28/01/2010 22:56, Henrik Carlqvist wrote:
> The Natural Philosopher<tnp@invalid.invalid>  wrote:
>> To answer your question a 400ft rod on end will weigh slightly more than
>> one on its side, there being very slightly less air to displace 400ft up.
>
> That answer might be true for some other reasons like gravity distances
> and centrifugal forces.
>
> However the fact that there is less air 400ft up only affects the air
> pressure. The air pressure is a linear function of height, or rather
> depth. The difference in air pressure between the upper side and the lower
> side of the rod only depends upon the difference in height of the upper
> side and the lower side. This difference becomes a constant if you are
> moving the rod up and down within the atmosphere.

Air pressure is not a linear function of height, it's probably 
exponential. And this whole business is not to do with the pressure 
difference between the upper and lower sides.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

Tim Streater <timstreater@waitrose.com> wrote:
> Air pressure is not a linear function of height,

Whoops, you are right, the barometric formula is not a linear function. My
linear approach only applies to liquids.

I stand corrected, please forget everything I said about constant
pressure forces and pressure integration in air.

> And this whole business is not to do with the pressure 
> difference between the upper and lower sides.

The difference in pressure is part of the explanation why two different
materials with equal mass has different weights because of different
density and volume.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

On Jan 27, 9:25=A0am, Michael Fesser <neti...@gmx.de> wrote:
> .oO(yawnmoth)
>
> >Also, when I made my PHP4 vs. PHP5 comment, I wasn't talking about for
> >loops. =A0I was talking about in general. =A0In general, PHP4 is faster
> >than PHP5. =A0At least by some methods of benchmarking.
>
> Yes, 'some'. Maybe. If at all. But without more details such comparisons
> don't mean anything, as said earlier. PHP 5 got a completely new engine,
> there's not much left over from PHP 4. Additionally some years ago a new
> memory management was introduced, which also increased the performance.
> Then there are new extensions to cache the bytecode and many more things
> that didn't exist in PHP 4.
>
> So even without any benchmarking I think it's safe to assume that PHP 5
> is faster than 4, not the other way round.

Errr...  you're right.  I misspoke.  I know of no benchmarks that
would suggest that PHP4 is faster than PHP5.  Even the one I initially
posted in this thread is faster in PHP5 than it is in PHP4.

I wonder what other typos I'll be making in 2009...

Warren Oates wrote:

> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> In the best case whe might be measuring what time it takes to increment
>> a loop variable, but it is rather trivial for a language to optimize
>> away a variable which isn't used for anything.
> 
> How about the first 30 (say) Fibonacci numbers? The last 5 are pretty
> big.
> 
> JS (using Spidermonkey's js cli):
> -----
> function fib(n){
>     return n<2?n:fib(n-1)+fib(n-2);
> }
> 
> for(i=0; i<=30; i++)
>     print(fib(i)); //js inserts a line break
> -----
> 
> PHP (using cli 5.3):
> -----
> <?php
> function fib($n) {
>     return $n<2?$n:fib($n-1) + fib($n-2);
> }
> 
> for ($i = 0; $i<=30; $i++) {
>    echo fib($i) . "\n";
> }
> -----
> 
> I didn't time them, but PHP seems to win here (Mac Pro quad Zeon, lots
> of RAM).

By which you have not considered that ECMAScript implementations support 
closures which allow for accumulator values which allow them to solve the 
problem in a lot more efficient way than programmed here.

You have tested only one of many ECMAScript implementations anyway.

It's still apples and oranges, really.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann