From: "larry on
On 3/24/10 2:33 PM, Rene Veerman wrote:

>> It's a debate. The dev team consider proposals and weigh in on the merits. I
>> was a proponent for goto support during the development of PHP 5. We now
>> have it. If you arguments are valid and there's no technical issue
>> preventing it, and there's someone with time and skill to created the
>> functionality, then it will happen. If not then it won't. I've seen many
>> things added to PHP and I've watched and participated in the threads on
>> internals that have lead to many new features. This is open source, opinions
>> matter, but personal attacks and poor argument do not really make the cut.
>>
>
> hahaha... you dismiss what i believe to be valid explanations without
> any counter-argument besides "more sql hardware!", not just by me but
> by all advocates of threading&shared memory in php.
>
> for some reason, which is still not clear to me, you nay-sayers refuse
> to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat")
> evolve to stay useful, relevant even, in a changing market.
>
> and you're blatantly telling me to use a different kind of "hammer",
> one that would force me to rewrite large sections of my existing
> code-base, and one that i have told you i would find for many other
> _valid_ reasons not optimal.

And what you seem to be missing is that making PHP userspace threaded is
such a major change to the underlying code base and architecture that it
would essentially be a total and complete rewrite, and would require
people to rewrite large portions of their existing PHP userspace code.

So it's either you adjust your code to fit the paradigm that PHP is
built for from the ground up, or the entire rest of the world adjusts
its code to fit the paradigm that you think you want to have.

> basically, you're determining my choice of options without me ever
> having forced you to do something a certain way..
>
> so you'll have to excuse my strong language.
> it's just letting you know that you shouldn't butt into other peoples
> business when it doesn't really affect you.

Except having to rewrite all of my code to be thread safe would affect me.

If you didn't want to have a discussion, which by nature has differing
view points, you shouldn't be on a discussion list.

--Larry Garfield
From: Robert Cummings on
Rene Veerman wrote:
> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert(a)interjinn.com> wrote:
>>
>> Rene Veerman wrote:
>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings <robert(a)interjinn.com>
>>> wrote:
>>>> Rene Veerman wrote:
>>>>> php is not a hammer, its a programming language.
>>>> It's hard to discuss anything with someone who doesn't comprehend a
>>>> metaphor.
>>> haha. "comprehend". you mean "accept".
>>> that metaphor is stretched to breaking point as far as i'm concerned.
>>>
>>>>> one that i feel needs to stay ahead of the computing trend if it is to
>>>>> be considered a language for large scale applications.
>>>> Personification of PHP doesn't make your argument any more salient. PHP
>>>> isn't trying to stay ahead of anything. People are using it to solve
>>>> problems, not to meet some phantom ideal of a "computing trend"
>>>> threshold.
>>>>
>>>>> but you nay-sayers here have convinced me; i'll be shopping for
>>>>> another language with which to serve my applications and the weboutput
>>>>> they produce..
>>>>>
>>>>> thanks for opening my eyes and telling to abandon ship in time.
>>>> Obviously we didn't open your eyes.
>>>>
>>> Well excuse me for not dumping 50-100k lines of my own cms code
>>> instantly now that i realize that in order to scale it, i could really
>>> use features like threading and shared memory.
>> Actually, you are th eone suggesting dumping your code since you said you
>> were jumping ship. Many of us suggested that your problems can almost
>> certainly be mitigated without threading.
>>
>
> "almost certainly". at least you're acknowledging that you might be wrong.

I'm certianly not right all the time. once I thought I was but I was wrong.

> take this example, sorry for the crosspost;
>
> my main concern atm is my own cms (50-100k lines of my own); it's
> graphics-heavy, does fairly complicated db based logic, and if it ever
> is to be used for a site like facebook, it'll get large dataflows that
> have to be distributed over the servers used to generate html and
> accessoiries for end-users.
> i've built a layer into it that caches the output of oft-used pages
> (like articles and their comments).
> but adding many comments / minute to an article would result in quite
> a bit of overhead, to update the html for that page and distribute it
> (fast enough) to the relevant servers.
>
> i'm worried about php's single-threaded nature; each request has to
> fetch html updated in the last few seconds, or generate it from a list
> of comments. that's also a big query from a big table for every
> end-user.. :(
> i'd rather keep them comments for an article in shared memory.....

I think you'll find when you get even close to the size of facebook,
everything you think you know now about how it all stays running will be
thrown out the window. But then, I'm not a fan of early optimization of
this magnitude. A good design is usually flexible enough to allow
redesign without recoding everything. Baby steps to the moon IMHO.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
From: Robert Cummings on
Rene Veerman wrote:
> On Wed, Mar 24, 2010 at 9:41 PM, Robert Cummings <robert(a)interjinn.com> wrote:
>>
>> Rene Veerman wrote:
>>> On Wed, Mar 24, 2010 at 9:30 PM, Robert Cummings <robert(a)interjinn.com>
>>> wrote:
>>>> Rene Veerman wrote:
>>>>> On Wed, Mar 24, 2010 at 3:13 PM, Robert Cummings <robert(a)interjinn.com>
>>>>> wrote:
>>>>>> Rene Veerman wrote:
>>>>>>> talk to me about this some other time.
>>>>>>>
>>>>>>> atm i'm having an argument with per and his kind about their very very
>>>>>>> annoying behaviour of determining my toolset for me.
>>>>>>> keeping a thread on topic is also ettiquette from the mailinglist
>>>>>>> rules
>>>>>>> eh?
>>>>>>>
>>>>>>> you might wanna consider just how much it pisses me off to have
>>>>>>> strangers
>>>>>>> determining my toolset and/or lifestyle for me.
>>>>>>> that's why i got rude. no other reason.
>>>>>> Umm... you or your boss/client chose PHP. That means one of those two
>>>>>> determined your toolset. Maybe next time you might want to pony up for
>>>>>> a
>>>>>> requirements analysis to determine if the toolset is right for the job.
>>>>>>
>>>>> you've never heard of feature-creep, changing environments and
>>>>> requirements, etc?
>>>> Not usually, at the level of the language choice, is an about turn done
>>>> after a requirements analysis has been completed. Feature creep is a
>>>> management issue.
>>>>
>>> it's a managment issue only because it's a fact of life.
>> A billable one.
>>
> i prefer to reduce my headaches and bill size at the same time with
> up-to-date tools.

Your tools are up to date. Threading is in the future if at all... it's
certainly not in the present.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
From: Rene Veerman on
On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert(a)interjinn.com> wrote:
> Rene Veerman wrote:
>>
>> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert(a)interjinn.com>
>> wrote:
>>>
>>> Rene Veerman wrote:
>>>>
>>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings <robert(a)interjinn.com>
>>>> wrote:
>>>>>
>>>>> Rene Veerman wrote:
>>>>>>
>>>>>> php is not a hammer, its a programming language.
>>>>>
>>>>> It's hard to discuss anything with someone who doesn't comprehend a
>>>>> metaphor.
>>>>
>>>> haha. "comprehend". you mean "accept".
>>>> that metaphor is stretched to breaking point as far as i'm concerned.
>>>>
>>>>>> one that i feel needs to stay ahead of the computing trend if it is to
>>>>>> be considered a language for large scale applications.
>>>>>
>>>>> Personification of PHP doesn't make your argument any more salient. PHP
>>>>> isn't trying to stay ahead of anything. People are using it to solve
>>>>> problems, not to meet some phantom ideal of a "computing trend"
>>>>> threshold.
>>>>>
>>>>>> but you nay-sayers here have convinced me; i'll be shopping for
>>>>>> another language with which to serve my applications and the weboutput
>>>>>> they produce..
>>>>>>
>>>>>> thanks for opening my eyes and telling to abandon ship in time.
>>>>>
>>>>> Obviously we didn't open your eyes.
>>>>>
>>>> Well excuse me for not dumping 50-100k lines of my own cms code
>>>> instantly now that i realize that in order to scale it, i could really
>>>> use features like threading and shared memory.
>>>
>>> Actually, you are th eone suggesting dumping your code since you said you
>>> were jumping ship. Many of us suggested that your problems can almost
>>> certainly be mitigated without threading.
>>>
>>
>> "almost certainly". at least you're acknowledging that you might be wrong.
>
> I'm certianly not right all the time. once I thought I was but I was wrong.
>
>> take this example, sorry for the crosspost;
>>
>> my main concern atm is my own cms (50-100k lines of my own); it's
>> graphics-heavy, does fairly complicated db based logic, and if it ever
>> is to be used for a site like facebook, it'll get large dataflows that
>> have to be distributed over the servers used to generate html and
>> accessoiries for end-users.
>> i've built a layer into it that caches the output of oft-used pages
>> (like articles and their comments).
>> but adding many comments / minute to an article would result in quite
>> a bit of overhead, to update the html for that page and distribute it
>> (fast enough) to the relevant servers.
>>
>> i'm worried about php's single-threaded nature; each request has to
>> fetch html updated in the last few seconds, or generate it from a list
>> of comments. that's also a big query from a big table for every
>> end-user.. :(
>> i'd rather keep them comments for an article in shared memory.....
>
> I think you'll find when you get even close to the size of facebook,
> everything you think you know now about how it all stays running will be
> thrown out the window. But then, I'm not a fan of early optimization of this
> magnitude. A good design is usually flexible enough to allow redesign
> without recoding everything. Baby steps to the moon IMHO.
>
yea, well, if i'm going to keep using php i need a path towards
scalability, for this particular problem.

i'd like to code the kinds of applications with big dataflows.
call me a golddigger all you want, it's what i am ;)
just not in the sexual sense hehe..

>Your tools are up to date. Threading is in the future if at all... it's certainly not in the present.

True, lets _keep_ 'm up-to-date, please.

And you'd enable other uses of PHP besides helping this
real-time-web-scalability problem.
From: Tommy Pham on
On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen <per(a)computer.org> wrote:
> Tommy Pham wrote:
>
>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <per(a)computer.org> wrote:
>>> Tommy Pham wrote:
>>>
>>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <per(a)computer.org>
>>>> wrote:
>>>>> Tommy Pham wrote:
>>>>>
>>>>>> What I find funny is that one of opponents of PHP threads earlier
>>>>>> mentioned that how silly it would be to be using C in a web app.
>>>>>> Now I hear people mentioning C when they need "productivity" or
>>>>>> "speed"...
>>>>>>
>>>>>
>>>>> I think I was the one to mention the latter, but as I started out
>>>>> saying, and as others have said too, it's about the right tool for
>>>>> the right job.  When choosing a tool, there are a number of factors
>>>>> to consider - developer productivity, available skills, future
>>>>> maintenance, performance, scalability, portability, parallelism,
>>>>> performance etcetera.
>>>>>
>>>>
>>>> Funny you should mention all that.  Let's say that you're longer
>>>> with that company, either by direct employment or contract
>>>> consultant. You've implemented C because you need 'thread'.  Now
>>>> your replacement comes in and has no clue about C even though your
>>>> replacement is a PHP guru.  How much headache is maintenance gonna
>>>> be?  Scalability? Portability? wow....
>>>
>>> Who was the idi... who hired someone who wasn't suited for the job?
>>> Tommy, that's a moot argument.  You can't fit a square peg in a round
>>> hole.
>>>
>>> --
>>> Per Jessen, Zürich (12.5°C)
>>>
>>
>> Suited for the job?  You mean introduce more complexity to a problem
>> that what could be avoided to begin with if PHP has thread support?
>> hmmm....
>
> Tommy, it's perfectly simple:  in my company we hire people with C
> skills for C programming jobs. We hire people with database skills to
> be database administrators.  We hire people with Linux skills to work
> on Linux systems.  We explicitly do _not_ hire PHP web-programmers to
> maintain our C code.  And vice versa for that matter.  No problem, no
> complexity.
>
>
> --
> Per Jessen, Zürich (13.4°C)
>
>

That may just work out fine if you work directly for the company with
all the proper staffing. But some of us work as consultants or for
companies without the proper staffing. As such, let's dissect what
you mentioned:

1) PHP with internal thread support
2) PHP with external C/C++ thread support

* Performance - having external thread support, now you have to call
an extension (more memory usage and CPU cycles). If you happen to
have a C/C++ guru who can then code that thread support into PHP
extension, wouldn't it still perform better at the core vs as an
extension because it's not talking to a 'middle man'? Having said
that, not everyone has access to a C/C++ guru. Thus not mass
availability.
* Portability - if you're currently running PHP on Windows, but manage
to convince management to switch to *BSD/Linux, then you'd have to
rewrite that external thread support. But for us consultants, we may
have 1 project the runs on Windows, the next may be *BSD/Linux. PHP
code snippets goes a lot further versus your custom work around.
* Managability - should your need to upgrade PHP for either bug fix,
new features you'd want to implement to add more functionality to your
site, will that then break your custom external solution? How much
more manageable is it if it's done under 1 language versus 2+?

Regards,
Tommy