Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
Hi! The filesystem issues are mostly due to what we do in TS mode, way too much pointless operations, even if the real cache helps a little bit here (take this comment with a bit of salt: as in delta with the cache between TS and NTS). What we do in TS mode with filesystem that could explain the difference to Linux? The filesystem problem is just that something like file_exists() (which a lot of apps use very extensively) takes a lot more time, and it's not cached by anything above the OS. And even with the OS cache on Windows such operation is significantly slower. However, thinking that you can get anything close to what we have on unix using processes is a sweet dream, which will become a nightmare once you realized that past the little usual tricks, nothing will help you to go further (and we are there already). Any windows developers know that windows is not designed to perform well using processes. No real surprise either that almost all apps able to compare with their unix equivalent uses threads (only or in critical parts). The only way we can be faster in threaded model if we don't do a full context switch (i.e., if we don't fully isolate one thread from another) - otherwise we'd be just emulating OS code doing the same thing but by slower user-level means (that's effectively what we do with ZTS because we have no choice there). I can't even begin to imagine how PHP engine could work without full thread isolation. I'm afraid if I think about it more I'd get nightmares. But if you think it's possible you are very welcome to try. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Tue, Feb 1, 2011 at 9:53 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The filesystem issues are mostly due to what we do in TS mode, way too much pointless operations, even if the real cache helps a little bit here (take this comment with a bit of salt: as in delta with the cache between TS and NTS). What we do in TS mode with filesystem that could explain the difference to Linux? No, but TS vs NTS as my comment said. The filesystem problem is just that something like file_exists() (which a lot of apps use very extensively) takes a lot more time, and it's not cached by anything above the OS. And even with the OS cache on Windows such operation is significantly slower. This delta has very little impact on real world apps except those doing exclusively such ops. The only way we can be faster in threaded model if we don't do a full context switch (i.e., if we don't fully isolate one thread from another) - otherwise we'd be just emulating OS code doing the same thing but by slower user-level means (that's effectively what we do with ZTS because we have no choice there). I can't even begin to imagine how PHP engine could work without full thread isolation. I'm afraid if I think about it more I'd get nightmares. But if you think it's possible you are very welcome to try. Most of what with do with EGco do not actually need thread isolation but thread local data (TLS). There are a couple of areas where we actually need locks but not necessary global locks as we do now. To be more clear, I'm not (hell not) talking abut parallelism, or sharing engine's data across threads but how we achieve thread safety for the shared data or which data we have to share or not, or TS APIs (*_r). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
It is a 2-step-migration step 1 - php 4 and 5.3 step 2 - only php 5.3 because there are various clients using that system. the development cycle cant stop with bug fixing and new features required by clients. no way to make a branch. We know that in the step 1 is a very horrible solution, but its necessary. Even with this compatible mode (php4 and 5.3) the system is getting 50% faster on php 5.3 On Tue, Feb 1, 2011 at 3:41 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 31.01.2011 21:08, schrieb Mathias Grimm: the constraint is that all need to run on php4.3.6 and 5.3 this need does not exist since php4 died a long time ago and now it's really time that some lazy people wake up everybody who has running php4 on prodcution servers has to be fired - remember php5.2 support is even ending and of course such stupid admins are tey one their servers get hacked and used for spambots and other nice things the world do not need
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
Hi! This delta has very little impact on real world apps except those doing exclusively such ops. The benchmarks I did suggest otherwise. Real world apps do huge number of file ops like file_exists(). And while many apps aggressively cache DB calls and such, filesystem calls are still there. Though, of course, maybe I'm wrong - what would you suggest is the problem then? I saw similar slowdowns on 1-process benchmarks as on multi-process server benchmarks - so I have hard time believing it has anything to do with threading vs. processes. more clear, I'm not (hell not) talking abut parallelism, or sharing engine's data across threads but how we achieve thread safety for the shared data or which data we have to share or not, or TS APIs (*_r). So what specifically do you think can be done better there? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Tue, Feb 1, 2011 at 10:23 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Though, of course, maybe I'm wrong - what would you suggest is the problem then? I saw similar slowdowns on 1-process benchmarks as on multi-process server benchmarks - so I have hard time believing it has anything to do with threading vs. processes. See what we do on each path in TS mode and what we do in NTS, and that's what I meant by tons of useless repetitive ops. more clear, I'm not (hell not) talking abut parallelism, or sharing engine's data across threads but how we achieve thread safety for the shared data or which data we have to share or not, or TS APIs (*_r). So what specifically do you think can be done better there? TLS is one part and then identify the part of the engine/exts that need TS and use better locking mechanism (rwlock-like). But my main point is, for windows, that process based application will never perform as well as they could with threads. And that's a fact, every windows developer knows that. But this discussion is a bit off topic :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
Am 01.02.2011 10:21, schrieb Mathias Grimm: It is a 2-step-migration nonsense step 1 - php 4 and 5.3 the best way to trash something beautiflul step 2 - only php 5.3 step 1 requires horrible code and so much work and with step 2 you have even more work to get the trash from step 1 clean because there are various clients using that system so let them run on a old machine with php 4 the development cycle cant stop with bug fixing and new features required by clients. the devleopment cycle will die because you trash too much time with nonsense work resulting in sleeping since years no way to make a branch. no way to get it without because if your code is so ugly that it will not run with PHP5 you have so much changes you can not do on live-systems - remind that all your changes to be backward compatible can have side-effects in PHP4 and PHP5 We migrated 5 years ago to php5 and it took 2 hours because we are running the highest error-reporting in production and so we seen deprecated warnings long before and made the code clean What you do is a migration over 3 major-versions Yes, 5.2-5.3 is in some cases the same as 4-5 and this is a path which does not really exist We know that in the step 1 is a very horrible solution, but its necessary. Even with this compatible mode (php4 and 5.3) the system is getting 50% faster on php 5.3 have fun but let me remember that if you do this so the chance to shoot all down and waste much more time as making a branch for 5.3 with code-cleanups outside production level and update after all is done On Tue, Feb 1, 2011 at 3:41 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 31.01.2011 21:08, schrieb Mathias Grimm: the constraint is that all need to run on php4.3.6 and 5.3 this need does not exist since php4 died a long time ago and now it's really time that some lazy people wake up everybody who has running php4 on prodcution servers has to be fired - remember php5.2 support is even ending and of course such stupid admins are tey one their servers get hacked and used for spambots and other nice things the world do not need signature.asc Description: OpenPGP digital signature
[PHP-DEV] size_t, casting and expression is always true (or false)
Hi.
I was looking at the cause for a test failing.
It came down to ...
size_t n;
if (n 0) {
// Code never reached as n is unsigned and cannot be negative.
}
I'm not a strong c developer, but from reading it seems that size_t is
always unsigned.
Using the windows compiler (and turning on all the warnings via /Wall
though /W4 should be enough), this warning reports as ...
xxx\yyy.c(nnn) : warning C4296: '=' : expression is always false
I then ran a full build and extracted all the C4926 warnings.
main\network.c(1175) : warning C4296: '=' : expression is always true
main\streams\filter.c(363) : warning C4296: '' : expression is always false
main\streams\streams.c(921) : warning C4296: '=' : expression is always true
ext\mysqlnd\mysqlnd.c(1006) : warning C4296: '=' : expression is always true
ext\mysqlnd\mysqlnd.c(1031) : warning C4296: '=' : expression is always true
ext\mysqlnd\mysqlnd_loaddata.c(215) : warning C4296: '' : expression
is always false
ext\mysqlnd\mysqlnd_loaddata.c(223) : warning C4296: '' : expression
is always false
ext\mysqlnd\mysqlnd_ps.c(1480) : warning C4296: '' : expression is always false
ext\mysqlnd\mysqlnd_ps.c(1620) : warning C4296: '' : expression is always false
ext\standard\ftp_fopen_wrapper.c(645) : warning C4296: '=' :
expression is always true
ext\standard\image.c(645) : warning C4296: '' : expression is always false
ext\standard\streamsfuncs.c(637) : warning C4296: '=' : expression is
always true
ext\standard\streamsfuncs.c(677) : warning C4296: '=' : expression is
always true
ext\standard\var.c(403) : warning C4296: '' : expression is always false
ext\pdo\pdo_stmt.c(463) : warning C4296: '' : expression is always false
ext\soap\php_encoding.c(2794) : warning C4296: '' : expression is always false
In the case of the bug [1], the incorrect type comparison resulted in
the suppression of an error which cased the test to fail, leading me
here.
I think other comparisons in the above list are also suppressing
errors (I think mysqlnd will fail to report a loss of connection
during mysqlnd_handle_local_infile() for example).
Regards,
Richard.
[1] http://bugs.php.net/bug.php?id=49072
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] size_t, casting and expression is always true (or false)
On 1 February 2011 15:07, Andrey Hristov p...@hristov.com wrote:
Hi Richard,
On 02/01/2011 02:35 PM, Richard Quadling wrote:
Hi.
I was looking at the cause for a test failing.
It came down to ...
size_t n;
if (n 0) {
// Code never reached as n is unsigned and cannot be negative.
}
I'm not a strong c developer, but from reading it seems that size_t is
always unsigned.
Using the windows compiler (and turning on all the warnings via /Wall
though /W4 should be enough), this warning reports as ...
xxx\yyy.c(nnn) : warning C4296: '=' : expression is always false
I then ran a full build and extracted all the C4926 warnings.
main\network.c(1175) : warning C4296: '=' : expression is always true
main\streams\filter.c(363) : warning C4296: '' : expression is always false
main\streams\streams.c(921) : warning C4296: '=' : expression is always true
ext\mysqlnd\mysqlnd.c(1006) : warning C4296: '=' : expression is always true
ext\mysqlnd\mysqlnd.c(1031) : warning C4296: '=' : expression is always true
ext\mysqlnd\mysqlnd_loaddata.c(215) : warning C4296: '' : expression
is always false
ext\mysqlnd\mysqlnd_loaddata.c(223) : warning C4296: '' : expression
is always false
ext\mysqlnd\mysqlnd_ps.c(1480) : warning C4296: '' : expression is always
false
ext\mysqlnd\mysqlnd_ps.c(1620) : warning C4296: '' : expression is always
false
ext\standard\ftp_fopen_wrapper.c(645) : warning C4296: '=' :
expression is always true
ext\standard\image.c(645) : warning C4296: '' : expression is always false
ext\standard\streamsfuncs.c(637) : warning C4296: '=' : expression is
always true
ext\standard\streamsfuncs.c(677) : warning C4296: '=' : expression is
always true
ext\standard\var.c(403) : warning C4296: '' : expression is always false
ext\pdo\pdo_stmt.c(463) : warning C4296: '' : expression is always false
ext\soap\php_encoding.c(2794) : warning C4296: '' : expression is always
false
which mysqlnd/PHP sources did you use in your build?
In the case of the bug [1], the incorrect type comparison resulted in
the suppression of an error which cased the test to fail, leading me
here.
I think other comparisons in the above list are also suppressing
errors (I think mysqlnd will fail to report a loss of connection
during mysqlnd_handle_local_infile() for example).
Regards,
Richard.
[1] http://bugs.php.net/bug.php?id=49072
Best,
Andrey
php-src/branches/PHP5_3/ext/mysqlnd
I've not run the code or any tests. I was just commenting on the
parallels between bug#49072 and the code that is being reported.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Tue, 2011-02-01 at 01:04 +0100, Pierre Joye wrote: On Mon, Jan 31, 2011 at 11:33 PM, Stas Malyshev smalys...@sugarcrm.com wrote: But I strongly believe in a threaded base solution for windows. That's the only way to get anywhere close to the performance we can see on other platforms (read: posix). My experience is that performance differnces between Windows and Linux has very little to do with server model, but much more to do with OS APIs (esp. filesystem, but not only). Also, threading PHP is generally slower than non-threading, so I don't see how threaded-base solution helps you there. Well, let say we don't have the same experiences. And the threaded model in php is not that good anyway (TLS will help here). I did not say a threaded model can be the perfect solution but it is the way to go. In case anybody was to play with optimizing the threaded model: There is a branch of PHP which has some optimizations in there on http://hg.genunix.org/php-experiment.hg The work was mostly done with Sun CMT machines (Niagara T-3 and such) in mind and most stuff in there is experimental but some of it might be interesting. But even with these patches TSRM emulates a feature operating systems already have, which is called process isolation. For making benefit from threaded environments we'd have to share more data over multiple threads ... which would make the engine way more complex. Maybe it's worth, maybe not ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] operator override
someone can help me to make the ZEND_ASSIGN operator overloading? i've looked de pecl operator extension but i dont have the necessary skills to do that.
Re: [PHP-DEV] Re: Zend mm
Thanks a lot, for all the help about zend mm guys, i'm very grateful. Thanks,A. --- On Sun, 1/30/11, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote: From: Ben Schmidt mail_ben_schm...@yahoo.com.au Subject: Re: [PHP-DEV] Re: Zend mm To: Adi Mutu adi_mut...@yahoo.com Cc: internals@lists.php.net, t...@daylessday.org Date: Sunday, January 30, 2011, 4:45 PM On 30/01/11 4:11 AM, Adi Mutu wrote: I have looked at the sources, but i'm only at the begining of analyzing the php sources.i've understand how to write extensions for example, but this memory manager seems more complicated to me. Yes, it is. Memory management is a low-level and subtle area. It takes a lot of careful thought to design and even to understand the algorithms involved. It is hard to debug, because an error caused in one place may not show itself until completely different code is executing. It is also an area which doesn't change much. Almost all the other code in the PHP interpreter, and therefore PHP scripts themselves, rely on the memory manager code doing its job unintrusively and correctly, so once it is working well, it tends to be left that way, except for fixing small bugs as they are found, or a big and careful development effort to address some limitation (e.g. improving the garbage collection to collect cycles, which was something done fairly recently). The bottom line is that this is not an area that is all that easy for beginners to get their teeth into. But it's also an area that isn't necessary for beginners to understand in much detail, either. Unless you have a particular project in mind that involves the memory manager, you probably don't need to touch it. I don't want to discourage you, but just point out that perhaps this is something you might look at later, or even not at all, as you may find there are many worthwhile projects that take up all your time before you ever get to understanding the memory manager fully. It would be useful if for example, could explain me the structures that are used in the Zend memory manager, how they're chained etc.and if you can tell me in words what do zend_mm_aloc_int() and zend_mm_free_int() basically do...Thank you for your time,Adrian I suspect these structures and functions are fairly easy to understand by someone familiar with the area of memory management, which is why you have been advised to consult the source code. So perhaps what you need to do is not learn about PHP's memory manager, but just learn about memory management in general. Then it should be fairly easy to understand what PHP's memory manager is doing from its code. I'm afraid I doubt the people here have the time to teach you this over email. :-) So here are some references which might be of use to you. - I believe the 'standard textbook' for learning about memory management is this one here: http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html - This page also mentions that a new edition is due out soon: http://c2.com/cgi/wiki?GarbageCollectionBook - You can also check out this site: http://www.memorymanagement.org/ - Relating this to, PHP: PHP is a garbage collected language which I believe uses reference counting and a clever collector to detect and free cycles. I haven't looked in detail into the implementation, but I know some documentation is available on the subject here: http://www.php.net/manual/en/features.gc.php Hope this helps! Ben.
