Critical Thinking

Yes, Apache does handle the multiptle PHP processess just fine for you, without needing it in the language. But like I said in the post, the world is increasingly moving towards things like Web services and other methods of getting information to be used on the page across a WAN link. In those scenarios, multithreading is extremely important. Why hold up all of your local processing while waiting on data from the WAN, when you can get your local processing done and then insert the data retreived remotely at the last minute?

J.Ja

Jaqui, I hate to say it, but you are complete off base here. Giving PHP developers multithreading, and allowing them to consume Web services on the server side is absolutely critical to avoiding AJAX, client side scripting, and usability issues. I know for a fact that you and I both support the same goals, with only a few small differences in this area of the world. It is infinitely better in my opinion, if you are going to draw data/information from a third party source, to do it server side and put it in a usable, JavaScript-free way in standard, accessable HTML than to hide it behind a million layers of clunky JavaScript, XmlHttpRequest, AJAX code. As such, it is crucial that PHP support multithreading - so that these third party vendors sources may be used in a non-AJAX way, without interfering with the processing of the rest of the page! To argue otherwise makes no sense.

More to the point, adding multithreading to PHP costs the language nearly nothing, yet opens it up to new uses on a very wide scale. Even if you are not going to pull data from a third party source, building a table, for example, in memory while waiting on a database request and then filling that table with data from a database on the WAN is often (depending on the query, table, etc.) better than waiting for the database results and then creating the table (just an example).

Usuablly I agree with you here, but I think you misunderstood my point. I like having things on the server as much as possible. Now that multicore CPUs are hitting all but the lowliest servers (I cannot imagine who buys a Celeron server to dish out Web pages though, unless it is a very low volume site...), with a simultaneous decrease in per-core clock, Web developers who are not able to multithread (either due to lack of knowledge or poor choices in language) are going to be unable to make the best use of their servers, and they are going to have a very hard time indeed explaining why keeping the processing on the server is preferable to AJAX.

J.Ja

Tony -

The point is well taken; that is one thing that Java and .Net have as an advantage. Yes, they are running within managed code environments, but it is still faster than a run time compile + dynamic interpretation. Do not even get me started on dynamic typing, which I will be writing about as soon as I am finished with multithreading.

That being said, the sad reality is that no one wants to be coding in C++/CGI. Is it lightning fast? It sure is! Scalable? A zillion times better than the usual Web development techniques. Feasible from a business standpoint? Not at all. Yes, the savings in hardware costs alone more than make up for the additional salary of a good C++ coder over a good Web developer. And yes, a great C++ coder can crank out usable, quality code in the same amount of time as a decent Web developer on a feature-per-day basis.

But the reality is, the number of great (and even good) C++ coders is simply not that high, and most of them are currently occupied working on things such as development tools, OS utilities, and other high level projects. To cope with the explosive demand for programmers, fueled by the significantly reduced cost and difficulty of writing Web applications as opposed to desktop applications, good C++ coders are becoming an increasingly rare commodity as a percentage of the total number of programmers out there.

While I am on the public record as stating that any big application (Web or otherwise) is actually cheaper to writing in well-written, compiled native code, the truth is, managed code environments and dynamic languages are growing much, much faster in usage with a corresponding growth in available programmers. For whatever reason, even company with a Web app with high scalability needs will probably end up developing in Java, PHP, or .Net, not native code, even though native code will pay for itself once you get beyond the first half rack or so worth of extra servers needed to run the less scalable code.

Reality being what it is, it is better to improve the systems that are actually being used, than to try to convince folks to start writing native code for Web apps.

J.Ja

A few quick points:

1. PHP is popular.

2. PHP is free

3. PHP runs on everything - choose your OS !!!

4. PHP has solid object-oriented constructs (Perl does not).

5. PHP plays well with the stable DBs - MySQL and PostGRE.

None of the other options combine these features and flexibilities.

I will stop here because I don't want to bother you. But, hey, you are welcome to wait for Judgement Day - many have waited ... but so far in vain.

As to Multithreading, there are two things that play a substantial role:

1. The cost of the developer - yes, you need someone who really understands threads.

2. The cost of the hardware - 2 1-U single processor servers are cheaper than one dual-Xeon-prosessor server (1-U or 2-U, regardless). So I would rather minimize my coding time by using PHP and have small cluster of 1-U servers than hire a high-end, high-salaried programmer to do the job and then pay him through the nose to maitain the application. Bacause you know how it is on the business side - requitements change, and so you must constantly up the applications to stay competitive.

Kovachevg -

None of the other options combine these features and flexibilities.

Ruby does, and I said so in my post. PHP is not unique. Except for the object orieted bit, Perl meets your list, and frankly, PHP's object oriented-ness is so clumsy, I do not consider PHP to be an object oriented language. It is certainly pretty crummy at model/view/controller development, N-Tier development, and event-driven development. Furthermore, as the world progresses and Web and desktop development get closer and closer (take a look at XAML if you do not beleive me!), developers need for the techiques to be as identical as possible, to allow for better code reuse, simplified testing, and skill usage. PHP is too tied to the Web model to be more than a bad Perl knockoff outside of handling a Web request. It does not support any modern programming methodologies in the slightest. In a nutshell, it is a dinosaur with a pretty bow around its neck.

1. The cost of the developer - yes, you need someone who really understands threads.

I agree. And within the next few years, a developer who does not understand threads will be a developer who is not employeed. Threads are approaching the "must have" point, thanks to the fact that nearly every up-to-date PC will be multi-core. Even low end PCs are dual core already.

2. The cost of the hardware - 2 1-U single processor servers are cheaper than one dual-Xeon-prosessor server (1-U or 2-U, regardless).

I do not know where you are getting you numbers from, but they are not accurate in the slightest. First of all, the Core 2 Duo (at least on the low end) chips are selling for less than the previous generation of CPUs already, and they are brand new. Second of all, the price differential between a dual-core Xeon server and a single core whatever server is not that great. Third of all, the TCO of 1 dual core Xeon (or Core 2 duo, or whatever your CPU of choice is) is substantially less than the TCO of 2 servers, all else being equal. The price difference in 1 chassis vs. 2 alone is probably 25% of the price difference in CPUs.

So I would rather minimize my coding time by using PHP and have small cluster of 1-U servers than hire a high-end, high-salaried programmer to do the job and then pay him through the nose to maitain the application. Bacause you know how it is on the business side - requitements change, and so you must constantly up the applications to stay competitive.

I agree with this, to a point. Yes, throwing hardware at poorly architechted software works, to a point. But if there are scalability problems there are scalability problems. More importantly, you still have not addressed how to best consume data from third party sources in an asyncronous I/O scenario (which is becoming increasingly common) without blocking the whole application. A Pentium II will put out a Web page as quickly as a T1 Niagara if they are both waiting 2 seconds on data across the WAN. Only multithreading can resolve this.

More to the point, a well written, multithreaded application, depending upon the usage of the threads, does not take significantly longer to developer and is not significantly more difficult to maintain, if the code is well written and the application is correctly designed. In an asyncronous I/O scenario, multithreading adds only a few minutes to a few hours worth of development time per function. That is a small fraction of the total development time, and can show substantial improvements in application response, while making better use of hardware, saving buckets of money.

I did not say that PHP stinks (which is an opinion I hold, but is outside the scope of this post). I said that it is doomed. Some great technologies and companies are (and have been) doomed. Novell, Borland, Delphi (I know, Borland two times in a row), the internal combustion engine... the list goes on. As you point out, requirements change. And if PHP does not get multithreading support, it simply cannot win, let alone continue to exist.

J.Ja

I agree with you. I'm recently migrated to Ruby and Python; so tired of writing thousand lines of code in PHP vs. hundred lines (or less) in Ruby.
The support of Object Oriented Programming is better in Ruby than in Java, and thousand miles away from PHP 5.

I'm only disagree when you say that PHP lacks IDE's and Debugger. Zend Studio is very easy to install and use, and it's an excellent editor, with PHPDocumentor and CVS (or Subversion) integrated, by example. And it has a debugger, too.

Doug -

While that article's points were valid at the time (and they still are factually correct), the conclusion is dead wrong. PHP has only been a real contender when open source vs. closed source is taken into account. Even when that article was written, PHP's competition had all of those features - and a lot more. And the editors the author mentioned are not open source projects, they cost real money. PHP's advantage is that it is easy to edit in a plain text editor, and editing .Net or Java code outside a good IDe is possible, but very painful. Where that article is outdated (and quite severely) is on three points:

1) Development tools - at that time, there were no quality, free tools for .Net or Java. Today, there is Eclipse and Visual Studiop Express.

2) Competition - at that time, PHP was supplanting Perl in the "open source Web development" space. Your only other option with real support was compiled C/C++ in a CGI environment. Fast and scalable, but not friendly in the slightest. Today, PHP has real competition from legitimate corners. Ruby/Ruby on Rail, Python, and Java is going open source. Compared to Ruby (I cannot speak from personal experience, however, since I have not used Ruby), PHP is a joke. Even worse for PHP, Ruby is currently "sexy" and has built in support for AJAX (via Rails), which makes it much more "sexy." PHP is not "buzzword compliant," Ruby, Java, and .Net are.

3) Suitability for more than one task - that article was written when there was little work being done on systems where portions of the code could and would be used by more than one type of environment. Today, it is almost mandatory that the business logic go into somewhere that can be used by a desktop application, Web application, mobile application, and maybe a few other places. PHP is also worthless in an N-tiered system, outside of the presentation layer.

There is a really good reason that so few complex Web applications get written in PHP. Sure, there may be some high visibility ones, or some that are huge but not complex. But as someone who has tangled with PHP plenty of times, I can tell you, it is just waiting for real competition, and it is gone. I have not met many people who are "real programmers" (as opposed to "Web masters" or "graphics designers who also write some code" or "script kiddies" or whatever) who have used PHP and think that it is a very good system.

I may add, PHP is totally stalled in terms of features and capabilities. It seems to be going nowhere fast, and much of the same lethargy was seen in Perl before its sun set.

J.Ja

What I would like to ask is...Where is ColdFusion in all of this?  I didn't even hear it mentioned.

--- Previous ---

1. The cost of the developer - yes, you need someone who really understands threads.

I agree. And within the next few years, a developer who does not understand threads will be a developer who is not employeed. Threads are approaching the "must have" point, thanks to the fact that nearly every up-to-date PC will be multi-core. Even low end PCs are dual core already.

--- END Previous ---

Boy, if only you were right !!! The world is full of developers who don't understand and who who understand but do NOT use threads. Your prediction is quite apolcalyptic, but unfortunately, it will NOT come true because if it does, 90% of the companies will run out of programmers. I wish every developper had your enthusiasm and dedication but in reality things are quite different.

Outsourcing is alive and kicking. Do you really think those Indian kids coming out of college can program effectively with thread? I spoke to Dr. Chand recently - he is an Indian born in the US but completed a second graduate degree in India. He showed me very reliable data on new programmers. There are currently 300 million young Indians who are about to start their career as programmers. The strategy of the Indian software comapnies is to keep development prices low and to hire new people every few months. Average turnover for developpers is over 30%. They know that once people get some skill, they are out the door looking for more money. Do you think that with this kind of scenario programming teams will bother to use threads. To cultivate the skills you are talking about requires commitment to quality - I don't see it happening.

In the US, companies look more and more for cheap developers who will come for a project or two and then leave. Yes, these could be consultants but just the very mentioning of the word materializes a hfty price tag. Then you need someon for cheap application support. Is that the guy who programmed with threads for 5 years?

Bottom line is, there are many jobs in IT that do NOT require the skills, the lack of which you claim will put people out of a job.

In one of your resposes you were discussing other languages, like Ruby on rails, that have all the perks that PHP has but they you said "Except for ..." - you see what I am saying? The value of a particular technology is vested not only in what it can achieve by itself but also in how well it integrates with other technologies. I outlined most of the important strengths of PHP in that respect, and so I don't want to repeat myself.

I see that you have the zeal not only to achieve but also to promote excellence. It is lofty endeavor to be sure. But remember that there are always multuiple points of view to be considered and that the most logical silution reconciles them without heavily favoring any one of them. Have a look at methods to estimate TCO (Total Cost of Ownership). You will see that there is a lot more to consider than just the engineering apsect.

The top of my list right now would be Alan Kay. Maybe Douglas Engelbart as well.

Both of them thought revolutionary ideas. They probably still do. Kay created the concept model of the personal computer as we know it today, back in the early 1970s when personal computers were just barely getting started, and when most people in the industry thought that a computer was a mainframe or minicomputer, one that would take up part or all of a room. I'm pretty sure he and his fellow researchers invented the GUI that inspired Steve Jobs to move Apple to create the Macintosh. They made it for his "Smalltalk system", which he wrote at Xerox PARC for the Alto prototype. He created the canonical object-oriented language, Smalltalk, a language I still love to work with whenever I get the chance.

Kay thinks deeply about technology's influence on society, and how personal computers have the potential to influence it years down the road. I've listened to several of his speeches. He has an amazing intellect.

Engelbart is widely known in the computer science field as having invented the computer mouse, but he was a pioneer in envisioning how computers could serve other people besides system operators, an interactive computer that would respond directly to the user. He thought time-sharing systems were the future, and in that I think he was mistaken, but he had the germ of a good idea. This is just my opinion, but I think his most forward-thinking concept was collaborative computing. I encourage people to watch the online video of his Menlo Park demo, where he gave a public demonstration of what he and fellow researchers had created, in 1968. It was so far ahead of its time some thought his demo was smoke and mirrors. It was all real. This is reminiscent of the first public demonstrations of Alexander Graham Bell's telephone system. Back when the phone was invented, some people couldn't believe that two people could talk to each other over a wire.

I wrote an article about Engelbart and Kay at my blog. I've got quite a few video links to relevant material there.

Bill Gates

Despite his billionaire status, he is still a geek (I mean that affectionately). There are people today who question whether he's a programmer at heart, or if he ever wrote code of any significance. His programming days are probably long gone, but he has the mind for it. Spolsky wrote an article about a code review he did with Gates back when he worked at Microsoft. Gates gets it. I'd love to talk tech with him if I got the chance, though these days he seems far more interested in his philanthropic work.

Alan Cooper

He created the technology that became Visual Basic at Microsoft. He didn't create the "Basic" part (the Basic came from a version that Microsoft already had), just the "Visual" part. I listened to an interview with him a year or two ago, and I got the sense that he understands the human-application interface, and usability very well. It would be neat to listen to him just do a "mind dump".

Any of the editors of Compute! Magazine, like Jim Butterfield, John Lock, Richard Mansfield, Charles Brannon, Tom R. Halfhill, etc.

This magazine went out of publication in 1994, but it had a major influence on me becoming an application developer, growing up. They tried hard to present technology as approachable and fun, and they conveyed the sense that the 1980s were historic times for technology, and that personal computers (back then) were the driver of the revolution.

Stewart Cheifet

Cheifet was the host, and probably the creator, of one of my all-time favorite TV shows: The Computer Chronicles. It was cancelled in 2002 unfortunately. When the show first started out it was co-hosted by the legendary Gary Kildall, who was also the President of Digital Research, and the author of CP/M. From the early 1980s onward, this show covered the PC industry. It gave both established and budding companies an opportunity to show that they existed, and to do a little demo of their wares. The show ran once a week, and would always end with "This week's computer news". Kildall left as co-host sometime in the early 1990s. He died a few years later.

The archives for this show are available here.

Sjsubbi -

"Built ground-up for only web programming, there is no need for multi-threading API. The PHP compiler does that, and so does Apache. Multi-threading API is something required for desktop apps and system programs."

While I agree, for a small, lightweight application, PHP is an OK choice, I disagree with your statement quoted above. You are essentially implying a view of Web development where the only thing a dynamic Web page does is slap some miscellaneous elements on the screen, and maybe send an email or run a small database query. While that may be exactly what many Web applications do, including some very high profile Web applications, for a real, serious application, a lot more is needed. For that, multithreading is a must.

For example, an application that draws data from a third party source, or performs a lengthy operation but also wants to keep the user informed as to the progress of the operation needs multithreading. In a nutshell, in a world in which everyone wnats to move desktop application functionality online (a world view that I do not agree with, BTW), desktop processing power needs to be moved to the server as well. That means multithreading. You will never write a good graphics editor in PHP, for example, without a third party library. On the other hand, something written in Java, .Net, Ruby, or C/C++ with CGI can do these kinds of complex operations and provide a great user experience at the same time.

For little apps (of the "it took me 2 days to write it" variety), PHP is fine. But for a large project, you need something that delivers a bit more oomph. PHP simply does not have that level of juice in it. And for most programmers, learning Language A for small applications and Language B for big ones just does not make sense, when Language B can do small projects too, and just as well as Language A.

J.Ja

Mark -

Alan Kay, excellent choice! My list was based not just along the lines of "who is really smart," but "who is interesting." I think Alan Kay meets that requirement. There are tons of smart people in the IT industry who just seem really boring. Michael Dell, Michael Arrington, and Larry Ellison, for example.

J.Ja

spamneeded -

"Did u got payed to say that ? PHP did not proposed threading because the core of php is quite simple and extremely scalable. Ask yourself why there is no J2EE free webhosting ? Because J2EE or ASP simply do not make it. Therefore, threading is not quite a magic function to boost performance because usage have proved that parallelizing or chaining requests have similar gain. Also parallelizing need much effort in software and hardware architecture. Therefore PHP6 may include threading. Do not try to fool us, thanks."

First, thank you. I think that is the first time anyone on this site has even suggested a lack of integrity on my part, or playing the FUD or shill game. I will be sure to mark it on my calendar. Who would pay me to knock PHP, especially chainwhen I offer not just Java, or .Net, but Java, .Net, and Ruby and Python as an example? What, you think there is some evil cabal of anti-PHP folks out there?

Furthermore, you bring up the mention of free Web hosts. Let's look at reality here. First of all, no one writing anything on a level above "check out my super kewl Web site and sign my guest book!" is using a free Web host. Second, free Web hosts typically do not come with any kind of dynamic language support. Third, if they do, you will not find any using J2EE because J2EE servers are typically complex to administer, and Windows/IIS costs money, both of which do not do well in a free environment. Fourth of all, your statement that "parallelizing [sic] or chaining requests have similar gain [sic]" is absolutely rediculous, not pertinent, and shows a complete lack of understanding. Another term for multithreading is parallel processing. More to the point, no, multithreading does not make any one request or function go faster (in fact, it makes it go slower). However (if you read my post instead of working yourself into a rage you would understand this), it is better to start a thread when requesting data from an external or slow source, assemble the rest of the page in the main thread, and then insert the data from the external source, as opposed to blocking the main thread waiting for that data. Multithreading almost always shows significant performance gains in these scenarios, particularly in instances where the main thread is computation heavy and the children threads are waiting on I/O operations.

Scalability? PHP is actually not as scalable as you would think; it has a reputation for being a touch slow. In fact, I have never heard of anyone selling a ".Net Accelerator" or a "Java Accelerator" but Zend (as well as other companies) sells a "PHP Accelerator". In fact, I cannot think of any other language off hand for which an extra "accelertor" even exists, let alone is marketable.

And PHP6? And you accuse me of FUD? If you have been around this industry more than a year or two, you should have learned by now that "the future" according to vendors, OSS developers, and everyone else is pretty much so irrelevant, particularly when it comes to feature sets and shipping times. Perl 6 is about 5 years late, by my reconing. Windows Vista is years late and missing half of its supposed feature set. Yes, PHP 6 may indeed include multithreading capabilities. Again, if you read what I wrote instead of throwing a temper tantrum, you qould have read the conditions that I put into my post: "If PHP does not catch up soon, I believe that it is doomed." It has a chance. It has to get moving, and fast, but it does have a chance to save itself. Perl did not disappear over night, and there is still plenty of it floating around. People are still wishing that COBOL would finally die. PHP can survive, if it adapts and changes to meet the current and future needs of developers.

J.Ja

Jaqui -

Don't worry, I am almost as much against AJAX and those other crackpot ideas as you are. :)

J.Ja

I haven't programmed in PHP, but I?looked at some sample PHP code recently and I didn't like what I saw. It looks too much like *nix shell script. I haven't used Perl, but I'll take Justin's word for it that they're similar. All the same I don't see why multithreading could not be added to PHP. A thought I had is maybe it's being held back by some older platforms it supports. Are there versions for DOS, Windows 3.x, or 16-bit OSes? If not, there's really nothing holding it back except for the possibility that its users haven't seen a need for multithreading yet. I assume all of the platforms it supports support multithreading natively. So all that would really be necessary is to add the language syntax/semantics that support it to PHP.

I've taken a look at Ruby, and I like what I see, with a caveat. Ruby, I've discovered, is similar to an old favorite language of mine, Smalltalk. As Justin has pointed out it's a dynamically typed language, and it's object-oriented. Back when I was getting my CS degree, the consensus seemed to be that part of the definition of an object-oriented language was it should be dynamically typed. Languages like C++ were the exception, not the rule. Of course there were always arguments going on about what truly defines an OO language. Back then it was common for Lisp to be referred to as an OO language. When I look back on that I just laugh. With the exception of CLOS (Common Lisp Object System), I don't see how people could come to that conclusion now. But I digress.

I'm going to get out ahead of Justin here, I'm sure. I was recently reviewing some old Smalltalk code I wrote, and this caveat came to mind: In a dynamically typed OO language, it's imperative that you document your instance variables. You can either do this by naming your instance variable according to the type(s) that are assigned to it, or put a detailed comment with it. The reason being that it's very easy to forget what type was assigned to a variable. In a dynamically typed language, there are no type designators in variable declarations. There are only variable names. However, once a variable is assigned an object of any type, any references to that variable must conform to the rules of that object's type. If you do not document this in a way that is clear to you, you can get yourself in a real bind, especially if the program is large and complex. As I was reviewing my Smalltalk code I noticed myself struggling a bit to figure out what types the instance variables in my classes had, because I didn't document them. This was important, because it provided a context for the code that used those variables.

One might ask why a language should be dynamically typed at all if it creates problems like this. The reason that dynamic typing can be nice is it enables code that is expressive. You can express your intent, rather than focusing on how to implement your intentions. The problem is that sometimes explicitly knowing how your intent is implemented is a good thing. Just from my short exercise in reviewing some old code, I found this was particularly the case with instance variables.

An example I've given in the past is in Ruby it's possible to say the following:

today - 2.weeks

to get a date?from 2 weeks ago. I think this illustrates well what I'm talking about. One clearly gets the sense of what I'm trying to do, almost at first glance. One can almost imagine writing this down on a piece of paper, showing this to somebody who knows nothing about programming, and have them understand what it means.

In C# I would have to say this:

DateTime.Today() - TimeSpan.FromDays(14.0);

In order to compute the date from 2 weeks ago, I have to show the types that will a) give me today's date, and b) give me a time span of 2 weeks. I'm using the .Net 1.1 API here. TimeSpan doesn't have a method FromWeeks().

From what I've read, Microsoft is planning on adding capabilities similar to what Ruby has to .Net in the Orcas timeframe. You can see the progress they're making in the Linq project. They're adding dynamic typing, lambda expressions (basically anonymous method delegates with parameters), and "extension methods" to C# and VB.Net. Extension methods will provide something similar to what we now see in Ruby. Methods can be "tacked on" to all classes that are used within a certain scope. So one can imagine a call like:

DateTime.Today() - 2 weeks;

with "weeks" being an extension method for the integer object "2", which produces a TimeSpan object. Note I did not use a period?('.') in the call to "weeks", and that I did not use parentheses. It looks like with extension methods these syntactic elements are not necessary.?Microsoft is getting the importance of expressiveness, particularly when it comes to extracting data from different sources. Programmers are complaining that it takes too much code to do this now. In the case of Linq, relief can't come soon enough. I would've loved to have had it a year ago!

This is the fifth installment of a multi-part series demonstrating multithreading techniques and performance characteristics in VB.Net.

While the last post used SyncLock to mark a "critical section" of code to maintain concurrency, we are now going to take a look at the Mutex class. A word of warning: as the test result show, Mutex is an extremely slow system! You want to be very careful when using Mutex. According to MSDN Magazine (September, 2006), Mutex can take 9801.6 CPU cycles to acquire a lock on a CPU without contention. In comparison to 112 CPU cycles for a Win32 CRITICAL_SECTION (which SyncLock uses), it is easy to see why the decision to use Mutex must be careful weighed.

Here is the code used for this test:

Public Sub MutexMultiThreadComputation(ByVal Iterations As Integer, Optional ByVal ThreadCount As Integer = 0)
  Dim twMutexLock As MutexThreadWorker
  Dim IntegerIterationCounter As Integer
  Dim iOriginalMaxThreads As Integer
  Dim iOriginalMinThreads As Integer
  Dim iOriginalMaxIOThreads As Integer
  Dim iOriginalMinIOThreads As Integer

  twMutexLock = New MutexThreadWorker

  Threading.ThreadPool.GetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)
  Threading.ThreadPool.GetMinThreads(iOriginalMinThreads, iOriginalMinIOThreads)

  If ThreadCount > 0 Then
    Threading.ThreadPool.SetMaxThreads(ThreadCount, ThreadCount)
    Threading.ThreadPool.SetMinThreads(ThreadCount, ThreadCount)
  End If

  For IntegerIterationCounter = 1 To Iterations
    Threading.ThreadPool.QueueUserWorkItem(AddressOf twMutexLock.ThreadProc, Double.Parse(IntegerIterationCounter))
  Next

  While MutexThreadWorker.IntegerCompletedComputations < Iterations

  End While

  Threading.ThreadPool.SetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)
  Threading.ThreadPool.SetMinThreads(iOriginalMinThreads, iOriginalMinIOThreads)

  twMutexLock = Nothing
  IntegerIterationCounter = Nothing
End Sub

And the MutexThreadWorker class:

Public Class MutexThreadWorker
  Public Shared MutexStorageLock As New Threading.Mutex
  Public Shared MutexCompletedComputationsLock As New Threading.Mutex
  Public Shared IntegerCompletedComputations As Integer = 0
  Private Shared DoubleStorage As Double

  Public Property Storage() As Double
    Get
      MutexStorageLock.WaitOne()
      Return DoubleStorage
      MutexStorageLock.ReleaseMutex()
    End Get
    Set(ByVal value As Double)
      MutexStorageLock.WaitOne()
      DoubleStorage = value
      MutexStorageLock.ReleaseMutex()
    End Set
  End Property

  Public Property CompletedComputations() As Integer
    Get
      Return IntegerCompletedComputations
    End Get
    Set(ByVal value As Integer)
      IntegerCompletedComputations = value
    End Set
  End Property

  Public Sub ThreadProc(ByVal StateObject As Object)
    Dim ttuComputation As ThreadTestUtilities

    ttuComputation = New ThreadTestUtilities

    Storage = ttuComputation.Compute(CDbl(StateObject))

    MutexCompletedComputationsLock.WaitOne()
    CompletedComputations += 1
    MutexCompletedComputationsLock.ReleaseMutex()

    ttuComputation = Nothing
  End Sub

  Public Sub New()

  End Sub
End Class

Here are the results of our tests. All tests are for 100,000 iterations, and the results are in milliseconds per test run. This is a significant departure from previous posts in this series, where tests were performed with 1,000,000 iterations.

TEST 1

This test allows the ThreadPool to manage the total number of minimum and maximum threads on its own:

TEST 2

In this test, we limit the maximum number of threads to one per logical processor:

TEST 3

This test uses only one thread:

TEST 4

This test uses two concurrent threads:

TEST 5

Here we show four concurrent threads:

TEST 6

This test uses eight concurrent threads:

TEST 7

Finally, this test runs 16 simultaneous threads:

System A: AMD Sempron 3200 (1 logical x64 CPU), 1 GB RAM
System B: AMD Athlon 3200+ (1 logical x64 CPU), 1 GB RAM
System C: Intel Pentium 4 2.8 gHz (1 logical x86 CPU), 1 GB RAM
System D: Two Intel Xeon 3.0 gHz (2 dual core, HyperThreaded CPUs providing 8 logical x64 CPUs), 2 GB RAM

It is extremely important to understand the following information and disclaimers regarding these benchmark figures:

They are not to be taken as absolute numbers. They are taken on real-world systems with real-world OS installations, not clean benchmark systems. They are not to be used as any concrete measure of relative CPU performance; they simply illustrate the different relative performance characteristics of different multithreading techniques on different numbers of logical CPUs, in order to show how different processors can perform differently with different techniques.

Testing revealed some very unusual performance characteristics. Although a little bit of "spin up" in .Net code is always expected, due to the GAC and what not, initial test runs sometimes took much longer than subsequent tests. Furthermore, tests with high numbers of iterations (such as 1,000,000) seemed to take quite some time to "spin down." Where the problem is cannot be found without much more in depth investigation. However, it did seem that there is definitely a "break or break" point on an individual system basis for this code, at which point something is going very wrong outside of the code itself. It may quite well be the garbage collector; the code itself had finished running, but the application was still consuming massive amounts of RAM and CPU time long after it reported success. There may be some possible tweaks that can be made to the code itself to assist the garbage collector, but altogether, it seems like Mutex is indeed an incredibly slow system. The speed difference between the Xeon system and the other systems seems to indicate that context switching is also killing performance, since it is running many more threads at once.

J.Ja

bugmenot -

"All this posts amounts to is wishful thinking. "Gee, wouldn't it be great if we could kick those Freedom-of-technology bastards off the Internet forever? If only PHP would go away, that would leave the only two server-side languages proprietary!" But PHP came along to address a need, and the need is still there. Perl still draws breath as well; you should really drop by Netcraft some time in your life before blowing off your big bazoo about what the web's doing."

Not true in the slightest. I said that PHP is falling woefully behind, and a lack of multithreading support is going to kill it. Furthermore, I am certainly not someone who hates those "Freedom-of-technology" people. I certainly offered Ruby as a logical sucessor to PHP.

Will PHP live on? Sure. Just probably not as one of the Big 3. Does Perl live on? Sure, it is still #4. But its percentage of new development is miniscule. PHP is headed there as well, unless it starts to change.

J.Ja

First, Perl isn't dead. Second, all the scripting languages are equally as good as eachother. To say anything else is just naivete or an attempt to start a religious war. We are talking about business apps here. Javscript and the web are allowing creativity to flourish by letting developers design their own widgets and more intuitive user interfaces. There will be no "winner". For the next 2 years, it will be .NET and Java and scripting languages. In the end, it will be and just be .Net. and we will live on planet Microsoft.

"First, Perl isn't dead. Second, all the scripting languages are equally as good as eachother. To say anything else is just naivete or an attempt to start a religious war. We are talking about business apps here. Javscript and the web are allowing creativity to flourish by letting developers design their own widgets and more intuitive user interfaces. There will be no "winner". For the next 2 years, it will be .NET and Java and scripting languages. In the end, it will be and just be .Net. and we will live on planet Microsoft."

Yes, Perl is quite dead (or at the very least, gasping for breath with a gut shot) as far as Web development goes. Not many people are performing new development in it. To say that all scripting languages are created equal shows a definite lack of understanding. JavaScript is pretty crippled as a language, as an example. PHP lacks multithreading, while Perl, Ruby, and a host of others do support it. Lisp, Scheme, and various ML derivitives can do things that other scripting languages only dream of. And so on. Is it a "religious war"? Sure.

JavaScript and the other languages fulfill wholly different roles. JavaScript (with the except of three people who took up Microsoft's challenge to use it in ASP) is client-side only (indeed, with the exception of Flash, it is the only client-side action you can count on being installed and turned on the bulk of the time), while Perl, PHP, Ruby, et al are server-side technologies. There is a world of difference there. I really do not care what widgets people make with JavaScript, because without something server side to feed those widgets, all they are are hopelessly obnoxious UI gagets that add little real value.

J.Ja

Look, this article is clearly ridiculous in that first, the author does not understand PHP very well and is looking at it from the eyes of a traditional application server. Second, the logical excercise of "PHP is the odd man out so it is going to die" is also demonstrably off-base.

Second one first. If you have three competitors and two are architected nearly identically and the third is not, then it is LIKELY that one of the two similar products will die off because those two compete more directly.

Now, the first one. PHP is "multi-threaded" simply through its architecture. Multi-threading is important in the Java and .NET worlds because you have a few big application servers sitting behind the scenes doing everything. PHP architecture is not that. In PHP you toss lots of cheap application servers up front and load balance across them. This means that you are spending about $1,000 per processor for a PHP system and about $10,000 per processor for a Java or .NET system. Java and .NET are not 10 times faster or more efficient than PHP. Maybe you could argue twice or three times but I doubt even that.

Finally, not everyone needs websites that will handle 10 million simultaneous users. It's a matter of scale versus complexity and PHP is dirt simple compared with .NET and Java. The barrier to entry is effectively zero.

I dont think lack of multithreading support alone will kill php; that seems a little far-fetched to me. I think PHP may/will probably be replaced at some point, but there will have to be several, really significant factors for that to happen (such as better libraries, faster development, etc); people arent all going to start simultaneously writing multi threaded apps and create this huge multi-threaded language demand just because the duo processors are available, no more than they will all immediately write 64 bit apps because those processors are available. Hence, there will not be any immediate push amongst developers for multi-thread support or bust, and php is safe in this respect.

I would actually be more likely to believe that PHP is going to be uprooted from an ease-of-development standpoint, which it sounds like Ruby is doing quite nicely already. PHP is probably going to be knocked off not by Java or .NET, but by another open source scripting based language in all liklihood (which it sounds like you agree with); just like PHP knocked off perl before it.

I think you're right that PHP will die, maybe even soon, but your reasoning is slightly unrealistic in my opinion.

So I have decided that it is time to finally overhaul my existing development environment at home. There are a lot of reasons behind it, but to put it simply, my infrastructure at home is meeting my needs, but it has me nervous and frustrated. Currently, I have two machines at home: an almost mid range eMachines (Sempron 3200, 1 GB RAM) running Windows XP Pro that I use for day-to-day work, development, and mild gaming, and an ancient white box (Athlon 1900+, 256 MB RAM) running FreeBSD 5.3 for *Nix development work and as a server for personal Web sites.

The whole idea of replacing my systems has been in the back of my head for a while. I want the server to be running a RAID 1, because a drive failure on that machine will make my life extremely miserable for a day or two. It is running a very old version of FreeBSD (5.3) that was installed as my first real foray into *Nix systems administration nearly two years ago, and a lot of mistake were made in the configuration of the system. Upgrading the OS does not seem like a great idea under those circumstances; I have things installed from ports, and things installed via make install, and between the two, I am really not sure that I want to find out what will happen on a build world. And the motherboard does not have a video card built into it, and I do not have any spare video cards, so working on it involves SSH (which I have no problem with, but is useless in case of hardware or boot problems), or turning off both PCs, removing the video card from my desktop, putting it in the server, and restarting it, which is hardly ideal.

The desktop PC is good enough to write and test code on, but it is incredibly slow. I cannot blame the system itself; if I was just doing the day-to-day work (email, Web browsing, the occasional game) it would be just fine. It is the development work that is killing it. VMWare, Visual Studio, the 2 GB text files I sometimes load into a text editor, all of these things just do not happen so well on that system. Even worse, it has a video card which tends to reset itself doing period of high stress. It is certainly not "Vista Ready" for anything other than acting like XP with different colors; the Aero interface is out of the question.

So I am getting in the final stretch of figuring out what my new infrastructure if going to look like. My requirements for the desktop PC are:

* Intel Core 2 Duo CPU, 6400 at a minimum, 6600 preferred
* 1 GB RAM, with room to grow to 2 GB or 4 GB when Vista is ready
* Multimedia card reader (optional)
* Silent case
* Excellent video card
* Floppy drive
* SATA II storage system, with RAID 0/1 capabilities
* Extremely fast hard drive for the OS and applications, either a very fast single drive, or a fast RAID 1
* Extremely reliable hard drive for data storage, in the 160 GB ? 200 GB range, RAID 1 preferred
* Dual optical drives, 1 DVD dual layer burner, one plain DVD drive (minimum)
* Gigabit Ethernet NIC
* Windows XP Pro

And the server should look like:

* Adequate, modern CPU
* 512 MB RAM minimum
* Fairly quiet case
* Basic optical drive (DVD or CD-ROM)
* Basic video card
* Floppy drive
* Extremely reliable storage, 500 GB, RAID 1
* Gigabit Ethernet NIC, possibly a second 10/100 NIC
* FreeBSD, Solaris, or Linux

Additionally, I am aiming to put the following items into my life:

* 20" Widescreen LCD monitor
* 4 port KVM
* 8 port Gigabit Ethernet switch
* New mouse
* Ergonomic keyboard

The plan is to achieve the following goals:

* Significantly improve the ergonomics of my home work environment to halt and hopefully reverse the damage that computing has done to my body
* Redundancy of data on disk and near-line access to backups
* Refresh the server to be much less kludged together
* "Vista Ready" desktop
* Not need to purchase new hardware for 4+ years
* Top-of-the-line performance on the workstation, well above average gaming and multimedia performance
* Able to run virtual machines without too much of a performance hit for testing, debugging purposes, particularly for product reviews and experimenting with *Nix
* Gigabit Ethernet for fast access across the network
* One monitor for "utility" purposes, particularly when watching movies or playing games, or testing and debugging code

Currently, I am looking to use a pair of Western Digital RE (not the RE2 drives, they are just a touch too expensive) or possibly Hitachi TK7500 drives in the 160 GB capacity range for the main partition in the workstation, and a pair of less expensive, 250 ? 320 GB drives for data storage. The server, believe it or not, tends to more or less sit there. It will have a pair of 80 GB drives in a RAID 1 to work on, and a single 500 GB drive for backup purposes (both itself and the workstation). I already have more than enough optical drives sitting around. The workstation's video card will be extremely high end, and probably ATI because I can get an outstanding deal on an ATI video card.

The RAM will be the best stuff I can get my hands on, mostly likely the Crucial Ballistix RAM at 800 mHz, and most likely 1 GB at first, and upgrading to 2 GB when I install Vista. The workstation's motherboard will be an Asus P5B, and the CPU will be either an Intel Core 2 Duo 6600 or a 6400, depending upon my mood and price when I make the purchase.

The only really tough problems are the cases. For the server, I am tempted to just take an existing case, line it with Dynamat or underbody paint, and be done with it. That should cut the noise levels dramatically while not impacting heat dissipation. I have no clue what to do with the wokstation, but a MicroATX case just will not be big enough. On the other hand, the typical tower case is too big. Why do I need five 5.25" external drive bays? I really only need two of them, and four internal drive bays (minimum).

Astute readers will notice that both machines will be getting floppy drives. There are too many utilities that require a floppy drive out there still, like Windows System Restore. And as anyone who has encountered it can tell you, it is quite disturbing to discover that Windows installation requires a floppy drive for those third party drivers when no one puts a floppy drive into a system at this point in the game.

I am going to build slowly, buying the things that immediately help me and never go down in price (NICs, switches, KVM, cases, input devices, etc.) up front, and then slowly doing one system at a time.

Any suggestions for me from the folks out there?

J.Ja

Justin-

I always saw Michael Dell as more of an interested businessman, someone who liked computers, but didn't get into them the way you and I do. I've never heard of Arrington, so I can't comment. Ellison is interesting to listen to, but more for entertainment value. He has a kind of flair and panache that's engaging, in a way. He's one of the few people in the industry who you could imagine hob-nobbing with the most elite sophisticates, and in that way I always imagine him as a legitimator of the IT industry. He's someone who says, "IT is classy." Nevermind if it isn't true. It's the image that counts. His views on the industry are almost guaranteed to be irrelevant though. The one "hit" I've seen in his predictions that's come true is the advent of online applications (web applications, basically), and readily available online information.

Hi guys,

I didn't have time to read all the comments in this blog, but here are my comments:

In my opinion, you can argue anything you want, but the fact remains, we live in a multithreaded world. If PHP does not support it, then it IS doomed. It may not die, but it will certainly cease to be one of the top players. Threading is a reality of modern computing and you will need it at some point. In fact, even suggesting that you don't need threads reflects your low degree of experience and knowledge about the subject (no offense to anyone).

I agree with some other user up there, scripting is SERIOUSLY overused nowadays. After all, AJAX and other techniques are nothing but workarounds for our stateless web environments. In my opinion big companies should be spending time working on a solution rather than building patches for this now obsolete architecture. Granted, that was not the original intent of web browsers but given its popularity and use, shouldn't we do something about it?

This article does demonstrate a lack of understanding of the PHP architecture. Especially since the main argument is wrong. PHP's request handling is done via Apache, so no threading is required to produce web services. Apache will use the available CPUs without a problem.

On the other hand, for consuming web services, PHP can use parallel request handling. Surprise! PHP has a huge library of extensions. It happens to contain one library to do this. You should perform a better research next time.

http://pecl.php.net/package/pecl_http/download/1.3.0/

As for the documentation argument, I think most PHP developers would not agree with you. One of the primary reasons of PHP's success is the fact that it has an excellent and easy to use documentation. Some extensions are not covered in full detail, but most of them are.

"This article does demonstrate a lack of understanding of the PHP architecture. Especially since the main argument is wrong. PHP's request handling is done via Apache, so no threading is required to produce web services. Apache will use the available CPUs without a problem."

I never said anything about producing Web services. I discussed parallel processing in general. It is amazing to me how many commenters seem to not know the difference between Apache using multiple threads to process requests for PHP scripts, and using threading within your script. Absolutely astounding, really. the fact that Apache runs each request in a separate thread has 1) nothing to do with PHP and everything to do with Apache and 2) absolutely no benefit if what you need is to perform parallel processing.

"On the other hand, for consuming web services, PHP can use parallel request handling. Surprise! PHP has a huge library of extensions. It happens to contain one library to do this. You should perform a better research next time."

You know what? If going to the PHP Web site, and searching for "thread" "mutex" "atomic" and "semaphore" (all common terms within the multithreading world) generate zero useful information, then as far as I am concerned, it does not exist. I did research. I literally spent hours trying to find information on this topic, and could not.

And the extension you linked to? Yes, while useful for performing the download of data via HTTP to consume a Web request (one example that I had used, so you have addressed that), it still does nothing for parallel computation. Furthermore, the "parallel requests" that you mention seem to execute the requests at the same time, but the rest of the code still blocks! The best you can do is make a new class, inheriting from HttpRequestPool, and override its socketPerform() and socketSelect() functions to have them run code while the request is processing; I hard consider this elegant. At best, to have any kind of true parallel processing, you would need to have the main script have the code split out into multiple files (or have a switch in the GET/POST data) and perform a request via the HttpRequestPool to each of those separate scripts (or the main script with a GET/POST switch somewhere) to simulate parallel processing.

Even then, you still do not have true multithreading! Where are your shared variables so that you can pass data around? What, you're going to dump evertything into session()? session() is global to that session, hardly a good way to maintain concurrency.

And let's not overlook the fact that this technique involves having Apache spool up an *entire HTTP request and instance of PHP and interpret an entire new script* simply to do some multithreading? That is entirely rediculous.

And it is hardly portable, since you need to have all of these seprate files for each "function."

I could go on and on, but to claim that this package refutes my claim that PHP cannot perform multithreading is entirely untrue. Yes, I may not have found this package in my research to this article (you can blame PHP's lousy documentation and search system for that one), but this package hardly does anything that I qould consider "mutltihreading." Sorry, but you are way off base here.

J.Ja

The project that just will not die has just knocked on my door. This was one of those projects were I made just about every freelance development mistake out there, with an extremely "challenging" customer. The last I heard from this customer was probably sometime in February, 2006, maybe March. I had received 75% of the payment already for the project, and my part of the project was 95% done.

The customer wanted an eCommerce site and the initial project specs were fairly routine. I made a flat price quote, and when the customer pushed for more and more and more, I rolled over and gave it to him without charging him more. Without bringing up any hard numbers, let me just say that the hours that I have put into this project compared to the amount that I am getting paid bring me to around minimum wage. I am not making this up. It is really that bad. I never heard from the customer again, we had been stuck on the part of the project where he enters in the information for a few thousand products. I did everything in my power to make this smoother for him; I made changes to the online administration, and even made a custom Excel spreadsheet filled with validation macros to construct the needed SQL statements to get the products into the database.

The real problem was that the customer wanted a complex "build a solution" system that allowed the components to be purchased separately, so there needed to be complex relationships between the products, and the customer just had no idea how to tie these things together.

I was actually quite grateful to never hear from this guy again. I probably would have been happy even if I never saw a cent from him and he owed me money, because he was that big of a pain in the rear.

The customer just called me this morning, laughed about waking me up (I was still sort of asleep), and then told me he is ready to get this finished.

Hooray.

J.Ja

Does the web really need complete parallel processing? Is the additional complexity really worth it?

Seriously, very large applications run on PHP. Applications that get millions of hits a day (think Yahoo!, Flickr). The applications are fast and highly personalized. They don't use parallel processing. They don't need it. It all depends on how you plan your whole architecture. If you want to rely on web services to pull out every single piece of information you display, PHP is obviously not for you. If you try using PHP the same way you use Java or .NET, you will fail. The same thing happens if you try to use Java the same way you use PHP. They are two completely different technologies.

Why would you search for mutex anyway? A mutex is a solution to a problem. PHP has no mutex extension because it does not need any.

• http://www.php.net/manual/en/ref.sem.php
• http://www.php.net/manual/en/ref.shmop.php
• http://www.php.net/manual/en/ref.apc.php

Wait... didn't the title of the first page contain the word Semaphore? It's even the first link I get when I search for it in the search box. The link is straight in the table of contents. Even google gives some results. Yeah, it's completely impossible to find information about semaphores in PHP, you're right.

lphuberdeau -

You are correct, I was able to find information on semaphores in the PHP documentation... only after changing the search parameters to include "all documentation" and not just the function list, which is the default. I stand corrected.

However, I beleive you did not fully read the Semaphor information; it is for working with System V processes. As the documentation I quote in the post itself shows, PHP running in a Web server should not be using forks and other System V process tools! So you really have not shown anything here; PHP is still incapable of running MT in a Web server.

"Seriously, very large applications run on PHP. Applications that get millions of hits a day (think Yahoo!, Flickr). The applications are fast and highly personalized. They don't use parallel processing. They don't need it. It all depends on how you plan your whole architecture. If you want to rely on web services to pull out every single piece of information you display, PHP is obviously not for you. If you try using PHP the same way you use Java or .NET, you will fail. The same thing happens if you try to use Java the same way you use PHP. They are two completely different technologies."

You will note that I never said a thing about PHP's speed or scalability, because I am well aware that PHP is used on some pretty large sites. I also did not say that every site out there requires parallel processing. But if I have to choose between two languages, one with MT support and the other without, all else being equal I will choose the language with MT capabilities. And yes, you really can use Java and .Net for the same types of sites (lightweight pages with relatively little business logic involved) and get results just as good as you can with PHP. Personally, I think Java and .Net both have their problems. Java is a monolithic pig and .Net is Windows/IIS only for all intents and purposes (not to mention the issues with anything provided by Microsoft).

That being said, PHP offers absolutely nothing unique. More importantly, while PHP in and of iteself does not provide any features that cannot be found in other frameworks, other frameworks, including the upstart Ruby on Rails, have a ton of features that PHP does not, without being significantly more complex or difficult to use. Pound for pound, the reason why PHP has such a large install base and usage rate has more to do with business reasons than technical reasons. It is open source, can be easily edited with a plain text editor, is easier to learn and work with than its predecessor (Perl), is easy to install and configure, and so on.

It is not like I am saying that PHP is without its merits. It has merits. It is simply that none of them are technical merits. The same can be said of JavaScript. JavaScript is a dog of a language, but it has a huge install base, and as such it gets used. PHP is lacking the high end features needed for big time development work. For example, the way it limits memory yet does not throw off errors when you have exceeded the maximum memory usage in a process; for those of us who do work with multiple MB and even GB with of data at a time, PHP does not cut it. As the world moves to replace traditional desktop applications with Web based equivalents, those big time features are going to be needed. You may not see the need for MT today, but what if someone asks you to write a Web based image editor (just an example). MT is incredibly useful in image editing.

Personally, I disagree with the drive to replace desktop apps with Web based versions of them. But as that is the direction that things are moving in, MT is important. More to the point, what is your resistence to bringing PHP to the world of modern languages? There are tons of language features out there that few people use, but their existence is a make or break item for some projects. For example, Perl has a lot of functional programming-esque features in it that rarely get used. But when they do get used, they slash code size and execution speed dramatically (try comparing the code to write the Knuth soundex algoritm in the Perl CPAN module to the code needed to do it in any procedural language).

"Why would you search for mutex anyway? A mutex is a solution to a problem. PHP has no mutex extension because it does not need any."

If you do not understand why someone would want to use or need a mutex, then you may want to review multithreading a bit more. Mutex's do indeed have their place.

It seems to me that you have a deep emotional investment in PHP. That's fine, and there is nothing wrong with that. But to hold PHP up as an unassailable totem of perfection when it really is not is foolish at best. I stand by my analysis; PHP's lack of MT capabilities will push it from one side, while another, better, more modern OSS language on the other side (quite possibly Ruby on Rails) will squeeze it out from the other side.

J.Ja

Just to play devil's advocate...

Well, alot of the php usage is also on personal sites/non-profits, lest we forget. I dont think I am going to use J2EE on my www hosting account that came with my home internet access anytime soon (J2EE environment for free? I dont think so). And since my ISP is using Linux on this box (I dont fault them), I doubt they're going to put Mono on it for ASP.NET. At least in this respect, I see php living on for awhile, as alot of service providers I know are not keen on switching to new technology quickly, even if it is becoming popular - such as rails.

Furthermore, if this discussion is any realistic sampling of php developers, at least half or more sound as if they dont care about/dont see a need for threading in php. Regardless of whether they are right or wrong, if php is going to die based on developer threading demand in your view, shouldnt there have been at least a few more people agreeing with you?

I think your views are great most of the time, and I am not taking sides with the non-threading people (I like to look at both sides of an argument in depth). However, just because you have such high standards for computing technologies and programming platforms, unfortunately does not mean that real world IT departments and project leaders see things the same way. Of course, we have no way to actually measure which programming teams "get it", and which ones dont. But from the sounds of things, it seems like group B.

I'm glad to finally see a tone change in your responses.

I am aware all those solutions related to threading I pointed to are rudimentary. I would not be surprised to hear that the only ones who ever used them are those who contributed to them. I never used them, I just know they exist for that one time I might need them. They might not be mature, but it solved a problem in a good-enough way for someone in the past. Alone, it's good enough of an argument to say that so far, threading is not a real need in the PHP world.

PHP might not have anything special as a language, but it does with the community. No one is trying to mimic predecessors. There is no such thing as a single solution. Design evolves over time, implementations are based on actual user needs. Even if some complain the API is inconsistent, it's probably the most simple and comprehensive API around. Have you worked with PHP 5.1? With PDO? The XML extensions? I used XML libraries in C++ and Java. Honestly, PHP's extensions beat them all single handed. Are the features unique? Of course they are not, but the implementation is. C# is one of those by the book languages made to fit well with UML tools, which was meant to match by the book object languages like Java. Unlike those languages, PHP is not trying to be generatable by CASE tools. It's not trying to be multi-purpose, although it's good enough in many situations with the CLI interface.

As a language, PHP is easily extensible using C. All those examples you gave about the need for multi-theading is related to performance. If performance is so important, the reccommended approach in PHP would be to write a C extension. From there, you have all those features you need for threading, with your mutexes and all.

As for RoR, it does have a few interesting concepts, but it's not close to being a mature technology yet. No one knows how much it can scale, how good the security of the framework is or if it will be gone with the 2.0 fad. It might end up being a good platform, but it will take more time. So far, it's all brand new. They have a small user base and could make changes quickly to their language and framework. It will be interesting to see how they handle things when it reaches a larger user base.

For your information, I know what a mutex is for. My point was that you don't need a mutex unless you have concurency. Since everything in PHP is mostly sandboxed, which is one of it's strength by the way, you don't need a mutex. The APC user cache allows to share information across requests. It handles the concurency, you don't have to worry about it. Is it the most efficient way to do it? It's probably not very smart for large amounts of data, but for small pieces, a mutex wouldn't do any better.

Hoping it clarified a few details.

    PHP is the only language I have used to date where I can go to their
official website, type "http://www.php.net/functionname", and get taken
straight to the page of the function.

MySQL also have a great site with similar user experience. Beyond the fact that functions are opened to user comments, you may type this url : http://www.mysql.com/functionname to go to the documentation in your own language !

Therefore PHP and MySQL are fully translated to other languages. Is it the case for Java ?

This is the sixth installment of a multi-part series demonstrating multithreading techniques and performance characteristics in VB.Net.

So far, we have covered single thread performance, and SyncLock and Mutex for maintaining data concurrency. This time, we will be using Monitor for concurrency. The differences between the three methods are subtle, but important. SyncLock ensures that a particular block of code is only being run by one thread at a time. Mutex is a class of its own with methods to ensure that only one thread is using it at a time; by attempting to lock the Mutex and unlocking it when finished, we are assured that only one thread is performing an operation at a time. In contract, Monitor is a singleton class that performs the locking itself, using objects as a key for the locking.

One very important note about using the Monitor class: do not use primitives as the object to lock! Because the primitive gets automatically wrapped in an object when passed to Monitor, each time you attempt the lock on the primitive, it is considered a separate object, despite the fact that the same primitive was passed in. As a result, your lock will not properly occur, and concurrency will be lost.

Here is the code used for this test:

Public Sub MonitorMultiThreadComputation(ByVal Iterations As Integer, Optional ByVal ThreadCount As Integer = 0)
  Dim twMonitorLock As MonitorThreadWorker
  Dim IntegerIterationCounter As Integer
  Dim iOriginalMaxThreads As Integer
  Dim iOriginalMinThreads As Integer
  Dim iOriginalMaxIOThreads As Integer
  Dim iOriginalMinIOThreads As Integer

  twMonitorLock = New MonitorThreadWorker

  Threading.ThreadPool.GetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)
  Threading.ThreadPool.GetMinThreads(iOriginalMinThreads, iOriginalMinIOThreads)

  If ThreadCount > 0 Then
    Threading.ThreadPool.SetMaxThreads(ThreadCount, ThreadCount)
    Threading.ThreadPool.SetMinThreads(ThreadCount, ThreadCount)
  End If

  For IntegerIterationCounter = 1 To Iterations
    Threading.ThreadPool.QueueUserWorkItem(AddressOf twMonitorLock.ThreadProc, Double.Parse(IntegerIterationCounter))
  Next

  While MonitorThreadWorker.IntegerCompletedComputations < Iterations

  End While

  Threading.ThreadPool.SetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)
  Threading.ThreadPool.SetMinThreads(iOriginalMinThreads, iOriginalMinIOThreads)

  twMonitorLock = Nothing
  IntegerIterationCounter = Nothing
End Sub

And the MonitorThreadWorker class:

Public Class MonitorThreadWorker
  Private Shared ObjectStorageLock As New Object
  Private Shared ObjectComputationsLock As New Object
  Public Shared IntegerCompletedComputations As Integer = 0
  Private Shared DoubleStorage As Double

  Public Property Storage() As Double
    Get
      Threading.Monitor.Enter(ObjectStorageLock)
      Return DoubleStorage
      Threading.Monitor.Exit(ObjectStorageLock)
    End Get
    Set(ByVal value As Double)
      Threading.Monitor.Enter(ObjectStorageLock)
      DoubleStorage = value
      Threading.Monitor.Exit(ObjectStorageLock)
    End Set
  End Property

  Public Property CompletedComputations() As Integer
    Get
      Return IntegerCompletedComputations
    End Get
    Set(ByVal value As Integer)
      IntegerCompletedComputations = value
    End Set
  End Property

  Public Sub ThreadProc(ByVal StateObject As Object)
    Dim ttuComputation As ThreadTestUtilities

    ttuComputation = New ThreadTestUtilities

    Storage = ttuComputation.Compute(CDbl(StateObject))

    Threading.Monitor.Enter(ObjectComputationsLock)
    CompletedComputations += 1
    Threading.Monitor.Exit(ObjectComputationsLock)

    ttuComputation = Nothing
  End Sub

  Public Sub New()

  End Sub
End Class

Here are the results of our tests. All tests are for 1,000,000 iterations, and the results are in milliseconds per test run

TEST 1

This test allows the ThreadPool to manage the total number of minimum and maximum threads on its own:

TEST 2

In this test, we limit the maximum number of threads to one per logical processor:

TEST 3

This test uses only one thread:

TEST 4

This test uses two concurrent threads:

TEST 5

Here we show four concurrent threads:

TEST 6

This test uses eight concurrent threads:

TEST 7

Finally, this test runs 16 simultaneous threads:

System A: AMD Sempron 3200 (1 logical x64 CPU), 1 GB RAM

System B: AMD Athlon 3200+ (1 logical x64 CPU), 1 GB RAM

System C: Intel Pentium 4 2.8 gHz (1 logical x86 CPU), 1 GB RAM

System D: Two Intel Xeon 3.0 gHz (2 dual core, HyperThreaded CPUs providing 8 logical x64 CPUs), 2 GB RAM

It is extremely important to understand the following information and disclaimers regarding these benchmark figures:

They are not to be taken as absolute numbers. They are taken on real-world systems with real-world OS installations, not clean benchmark systems. They are not to be used as any concrete measure of relative CPU performance; they simply illustrate the different relative performance characteristics of different multithreading techniques on different numbers of logical CPUs, in order to show how different processors can perform differently with different techniques.

You will see that while Monitor is consistently a bit slower than SyncLock, it is nearly as fast, and is much faster than Mutex. So why have different methods at all? Well, there are some very good reasons for it. Each method has its own purposes. Although SyncLock is marginally quicker than Monitor, Monitor locks on a per-object basis while SyncLock locks entire blocks of code at a time. For a single line where only one variable is being used and requires concurrency (such as an incrementer), SyncLock is the better choice. But for something more complex, such as many lines of code that deal with many variables, only a few of which need concurrency, Monitor is a better choice. It is preferable to let other threads do as much of that code as they can, blocking only on certain parts, than to have the entire block of code held up. Mutex has capabilities that do not exist in Monitor or SyncLock; for further information, check the documentation.

J.Ja

One of the persistent pieces of "common knowledge" out there is the idea that Firefox is slowly grinding Internet Explorer into the ground. Along with this "common knowledge" is the assumption by some Web developers that since the Firefox Revolution is nigh, there is no real reason to take Internet Explorer into consideration. Sadly for the Firefox fans out there, this simply is not true.

Where does this piece of "common knowledge" come from? A lot of people point towards IE's declining market share, FF's rising market share, and FF's current market share of about 30%. However, the people who point to these numbers are definitely failing Statistics 101. As I said in June 2006 ("Be Careful That Your Data Does Not Lie"), first order numbers, are not very useful, and are essentially worthless without at least some baseline numbers to be compared to.

Having been curious about this for some time, I decided to see if Firefox's adoption rates were the stuff of legends or not. And I have found that Firefox is indeed not a superhero, but an average Joe.

Using W3School's month-by-month browser market share numbers, I came up with some startling facts: Firefox's market share growth (and indeed, the entire Gecko family's market share growth) since the introduction of Firefix is actually less than it was before Firefox was introduced.

Here is my chart of calculations:

The Pre-Firefox velocities and accelerations are based on 12 months of data, and the Post-Firefox numbers use 21 months of data.

Note: I recognize that these numbers and conclusions may be controversial; as soon as I can (technical issues), I will make the full spreadsheet available for download. I will also be more than glad to use alternative market share numbers from a different source, as long as the alternate source measure a large sample of users and is of a "general purpose" interest, to avoid potential skew caused by a niche audience.

[Added: 9/29/2006: Download the spreadsheet]

What is happening? Well, what you are seeing is that the velocity (rate of market share growth) is lower for the Gecko browsers in the 21 months after Firefox came out than it was in the 12 months before Firefox. To eliminate any doubt, I broke the numbers out into Firefox and Non-Firefox Gecko browsers, to show that it is not simply Netscape or Mozilla destroying the numbers.

What we see in these numbers, is that while the bulk of IE's market share loss since FF came out is due to FF, that loss rate is smaller. More important to note is that Firefox came out of the gate with a 16.6% market share in January 2005, and the Gecko market share was at 18.4% in December 2004. In other words, Firefox quickly supplanted the other Gecko browsers, and as Firefox immediately became the "face" of Gecko, Gecko's growth rate wilted. Or to put it even more simply, Firefox is not as attractive to users as Mozilla and Netscape were.

I was suspicious. The numbers just did not jive with what "common knowledge" was. Indeed, I had bought into the idea that Firefox had great accelerated IE's demise myself. I thought that maybe the numbers were off, but many sources report the 30% number (give or take a few percentage points) as Firefox's current market share as well. And I have never heard anyone argue against W3School's numbers in the past. I thought that maybe Firefox's immediate 16.6% market share in January 2005 seemed wrong, so I checked Firefox's site to see when it was officially released as Version 1.0: November 4, 2004. so yes, the W3School numbers do not break out Firefox as a separate browser for two months initially. But even that seems pretty irrelevant; the raw numbers do not show Gecko's market share growing by more than 1.6% in any of the months between July 2004 and January 2005; and the 1.6% number is in November 2004. So even accounting for the fact that Firefox was being rolled into Gecko for some time, which did cause a slight spike in Gecko market share capture, it is difficult to say that Firefox is driving adoption of itself, or causing IE's demise.

At best, we can conclude that while it was bound that non-IE browsers would eventually hit the "glass ceiling" of people who will never leave IE, it may have raised that ceiling a bit.

J.Ja

This is the seventh and final installment of a multi-part series demonstrating multithreading techniques and performance characteristics in VB.Net.

This week's post on multithreading takes us full circle, back to non atomic operations. Unlike the first post that tested performance, which performed them in a single thread, this one is multithreaded. Although it is multithreaded, and performs read/writes to shared variables, there is no thread safety whatsoever. As a result, in actual code where the contents shared variables are needed, they cannot be trusted. The variable that holds the number of completed computations is actually trustworthy, because all threads are doing the exact same thing, adding the number 1 to it. If it was doing something less predictable (such as multiplying by the iteration number or adding to a string of characters) the results would be chaotic at best. That is an important distinction to note: while this code is actually functional, in a real program it would probably not work, and definitely not work as expected!

You can download an installer for this program here. The installer will also install the full source code for the project, in a subdirectory of the installation path. Feel free to try it out yourself and tinker with it or just to look at it to get a better understanding of multithreading techniques.

This is the code that launches the threads:

Public Sub NonAtomicMultiThreadComputation(ByVal Iterations As Integer, Optional ByVal ThreadCount As Integer = 0)
  Dim twNonAtomic As NonAtomicThreadWorker
  Dim IntegerIterationCounter As Integer
  Dim iOriginalMaxThreads As Integer
  Dim iOriginalMinThreads As Integer
  Dim iOriginalMaxIOThreads As Integer
  Dim iOriginalMinIOThreads As Integer

  twNonAtomic = New NonAtomicThreadWorker

  Threading.ThreadPool.GetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)
  Threading.ThreadPool.GetMinThreads(iOriginalMinThreads, iOriginalMinIOThreads)

  If ThreadCount > 0 Then
    Threading.ThreadPool.SetMaxThreads(ThreadCount, ThreadCount)
    Threading.ThreadPool.SetMinThreads(ThreadCount, ThreadCount)
  End If

  For IntegerIterationCounter = 1 To Iterations
    Threading.ThreadPool.QueueUserWorkItem(AddressOf twNonAtomic.ThreadProc, Double.Parse(IntegerIterationCounter))
  Next

  While NonAtomicThreadWorker.IntegerCompletedComputations < Iterations

  End While

  Threading.ThreadPool.SetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)
  Threading.ThreadPool.SetMinThreads(iOriginalMinThreads, iOriginalMinIOThreads)

  twNonAtomic = Nothing
  IntegerIterationCounter = Nothing
End Sub

And here is the code for the class itself that performs the work:

Public Class NonAtomicThreadWorker
  Public Shared IntegerCompletedComputations As Integer = 0
  Private Shared DoubleStorage As Double

  Public Property Storage() As Double
    Get
      Return DoubleStorage
    End Get
    Set(ByVal value As Double)
      DoubleStorage = value
    End Set
  End Property

  Public Property CompletedComputations() As Integer
    Get
      Return IntegerCompletedComputations
    End Get
    Set(ByVal value As Integer)
      IntegerCompletedComputations = value
    End Set
  End Property

  Public Sub ThreadProc(ByVal StateObject As Object)
    Dim ttuComputation As ThreadTestUtilities

    ttuComputation = New ThreadTestUtilities

    Storage = ttuComputation.Compute(CDbl(StateObject))

    CompletedComputations += 1

    ttuComputation = Nothing
  End Sub

  Public Sub New()

  End Sub
End Class

Here are the results of our tests. All tests are for 1,000,000 iterations, and the results are in milliseconds per test run

TEST 1

This test allows the ThreadPool to manage the total number of minimum and maximum threads on its own:

TEST 2

In this test, we limit the maximum number of threads to one per logical processor:

TEST 3

This test uses only one thread:

TEST 4

This test uses two concurrent threads:

TEST 5

Here we show four concurrent threads:

TEST 6

This test uses eight concurrent threads:

TEST 7

Finally, this test runs 16 simultaneous threads:

System A: AMD Sempron 3200 (1 logical x64 CPU), 1 GB RAM

System B: AMD Athlon 3200+ (1 logical x64 CPU), 1 GB RAM

System C: Intel Pentium 4 2.8 gHz (1 logical x86 CPU), 1 GB RAM

System D: Two Intel Xeon 3.0 gHz (2 dual core, HyperThreaded CPUs providing 8 logical x64 CPUs), 2 GB RAM

It is extremely important to understand the following information and disclaimers regarding these benchmark figures:

They are not to be taken as absolute numbers. They are taken on real-world systems with real-world OS installations, not clean benchmark systems. They are not to be used as any concrete measure of relative CPU performance; they simply illustrate the different relative performance characteristics of different multithreading techniques on different numbers of logical CPUs, in order to show how different processors can perform differently with different techniques.

As you can see, having no locks occurring results in significant performance gains over the tests that were performed with carious locking mechanisms. However, it is important to understand the ramifications of not using locking. If there is any type of data that needs to be shared amongst threads, locking will have to come into play. Judicial use of locking should prevent the performance hit from being too high. It is also important to note that for many situations, running your computations in a single thread will actually be faster than using multithreading; it all depends on your hardware and what you will actually be doing. As I have said before, "your mileage will vary." Test, test, and test again to see what techniques work best for your particular application.

We have come to the end of the end of this series. As always, feedback and comments are appreciated.

J.Ja

Why is buying computer hardware so much work? To be sure, there are some components like power supplies, most peripherals, and so on that are pretty straightforward to choose. Even some of the more complex hardware, like hard drives and motherboards are pretty easy to select; you decide which features you need, and find which parts have those features. But selecting CPUs and video cards is nearly impossible.

A long time ago, CPUs were easy to select; you just bought the highest clock cycle CPU you could find. You chose Intel because you did not have a choice (or much of one, at least; non-Intel CPUs tended to not be very good). Now, there are dozens of families of CPUs from more than one manufacturer (Intel, AMD, and more, if you count the less mainstream CPUs). Each family has its own benefits and drawbacks, and pure CPU speed is less of a determining factor for end game performance than it used to be. Would a dual core CPU at 2.0 gHz per core be better than a single core CPU at 3.0 gHz? It all depends on your needs. What about cache? Coprocessors? And so on. At the very moment, the choice is fairly easy: the Core 2 Duo (Conroe) CPUs from Intel are beating the competition, even when compared to much more expensive CPUs. But no one expects that to last, and the last month or so has been the first time in a while that CPU selection was fairly easy. But even when it has been confusing, the simple rule that never went wrong was to get as much cache, clock cycles, and cores as possible.

Video cards, on the other hand, have never been simple, and probably never will be. This is what I have been stuck on for some time with my recent quest to upgrade and revamp my home network and computers. Picking out everything else was pretty painless, with the exception of deciding how much I wanted to spend on hard drives and if I preferred RAID 1 with two smaller drives to one smallish drive for data and a big drive for backups (I decided to go with RAID 1, it was cheaper and will be faster). But the video card is still killing me.

I went to Tom's Hardware Guide, and I will tell you, that site is positively worthless. I really do not see why people treat it like it is the source of all hardware information. It is not. I read the guide to video cards, and what the site calls a "about $200 video card" was listed for no less than $250; indeed, even on the site's links to vendors, they were listing that "about $200 video card" for "about $300"! The recommendations could not even be found at half of the sites that I prefer to shop at.

I think video cards are a hoax at this point; someone wants me to give up and just spend whatever my maximum budget is, and hope that I get the best card possible. It is ridiculous.

Buying computer hardware gives me severe heartburn. Following hardware trends is an exercise in futility, as whatever I learn today is useless tomorrow. There are no good ways to directly compare too many components, and all too often my choice is to pay for features I do not want, or not get features I do want to remain within budget. Overall, the process kills me and I wish it was easier.

J.Ja

This article is very good. I am not a native English speaker. I am going to receive English call. So I am trying to practice this. Thanks.

Leon