Will PHP ever "grow up" and have threading?
in [General]
|
From: "larry on 24 Mar 2010 15:45 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 24 Mar 2010 15:45 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 24 Mar 2010 15:47 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 24 Mar 2010 15:50 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 24 Mar 2010 15:59
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 |