Will PHP ever "grow up" and have threading?
in [General]
|
From: Robert Cummings on 24 Mar 2010 16:21 Rene Veerman wrote: > 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. It is up to date. You mean make it have all the features you want. PHP is by it's very existence and ongoing development "up to date". Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Paul M Foster on 24 Mar 2010 16:21 On Wed, Mar 24, 2010 at 09:50:15PM +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert(a)interjinn.com> > wrote: <snip> > > > 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. Rene: You've been told you have two choices. Handle this with the PHP developers, or use a different language. Clearly, you're not making any converts on *this* list, and no one here can help you. Everyone else: Rene is baiting you, and drawing out the "discussion". He's simply thrashing about, trying to make you wrong for disagreeing with him. There is no more blood to be gained from the turnip of this thread. If you'd like to see it ended sometime this century, stop replying to him (in this and his other thread) and let him go bother the PHP developers, or use some other language. Paul -- Paul M. Foster
From: Robert Cummings on 24 Mar 2010 16:22 Rene Veerman wrote: > On Wed, Mar 24, 2010 at 9:45 PM, larry(a)garfieldtech.com > <larry(a)garfieldtech.com> wrote: >> 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. > > > ehm, my newsscraper does threading via a fopen($threadURLonOwnServer) > -> fread(threads,2048)+check for feof($thread) + usleep(50ms) -> if > feof($thread) process($threadResults). > > so with a hack, you can let apache handle the threading, today. > > i suppose i could write something for shared memory in C++ but doing > so would also be a hack that has to be installed on each server, > rather than having it neatly as part of php. See PECL. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Robert Cummings on 24 Mar 2010 16:24 Tommy Pham wrote: > 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. Are you suggesting that you need to be a guru in C to write threaded C code? I think the word you're looking for is competent. > * 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+? Are you suggesting cross platform thread libraries don't exist? I wonder how Apache does it... or MySQL... or any number of open source cross-platform systems. If they implement their own, then by the virtue of the source being open, you can feel free to incorporate. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Ashley Sheridan on 24 Mar 2010 16:19
On Wed, 2010-03-24 at 22:15 +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:05 PM, Ashley Sheridan > <ash(a)ashleysheridan.co.uk>wrote: > > > > > > > So you're basically saying that you'd discount anyone who opposes you > > purely because you think you know best? > > > > Nice attitude. > > > > I ain't saying that at all, nor did i intend to imply it. > > In fact it's the anti-threading/shared-mem camp that thinks they know > everything best with their instistance that "throw more hardware at it, more > sql servers, more programming languages in a single project" will solve all > software design / growth problems with enough efficiency. They're offering the alternative. You keep disagreeing with their viewpoint because you seem to think you know best on this matter and won't even concede on a point. > > In this case, you still haven't given me any other reason to oppose the > evolution of php with the market trend Do you have any proof of this 'market trend'? I suggested a vote, but you 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly know as much as you do. > , other than that it would cost > php-dev team time that can be spent on other things. > you (that camp) haven't even told me what features you want 'm to spend time > on instead. There are no new features that *I* can think of that *I* need in PHP, which is not to say that there aren't any that *other* people want. Again, I did suggest some sort of vote on this, which would give the internals team an idea of how keen people were to see this in the near future, but you said that too many people would oppose it. This comes round to the fact again that you seem to know best, and if the majority of people oppose your suggestion then they must be wrong, so any vote wouldn't count. I wouldn't say I belonged to any particular camp at the start of this thread, but now, having read what my betters have said, I'm inclined to agree that threading isn't the magic wand that you seem to think it is. I personally see one of the largest sites in the world running on PHP without needing threading and without insulting half the list to attempt to get it. Thanks, Ash http://www.ashleysheridan.co.uk |