Slashdot folks like science, so read the papers on John Latham's website. Here's his synopsis:
John Latham is working with several collaborators (including Prof. Tom Choularton, University of Manchester, UK; Prof. Stephen Salter, University of Edinburgh, UK; and Prof. Mike Smith, University of Leeds, UK) on a proposed geo-engineering technique for global warming mitigation (Latham, 1990 and 2002 , Bower et al. 2006). A detailed account of this work is presented in the three papers linked, above.
The basic principle of the scheme is advertently to increase the droplet number concentration N in maritime stratocumulus clouds, thereby increasing their albedo (reflectivity) for incoming sunlight and also their longevity. This would produce a cooling effect, the magnitude of which could be controlled, and calculations and GCM computations both indicate that its magnitude could be sufficient to balance the warming due to increased atmospheric carbon dioxide concentrations resulting from the burning of fossil fuels. It is proposed to increase N by atomizing seawater at the ocean surface (producing copious quantities of droplets of around 1micron in size), and the significant fraction of these which rise into the low-level clouds above would act as cloud condensation nuclei (CCN), thereby creating additional droplets and enhancing N. The seawater droplets would probably be disseminated from a fleet of satellite-controlled unmanned vessels, deriving their required energy from wind or wave-power. Control over the degree of planetary cooling could be achieved via albedo measurements linked to a global climate model.
Technological questions regarding the production and dissemination of these particles remain to be resolved. Also, detailed examination of the meteorological and climatological ramifications of this proposed geo-engineering scheme would need to be conducted before justification would exist for its operational deployment. Two advantages of the scheme are that: (1) it is relatively benign, the only raw material being seawater; (2) if the disseminators were switched off, the droplets introduced into the atmosphere would fall back into the oceans within a few days.
Amdahl's law says that if Facebook were to switch from PHP to C++, the best possible improvement in the overall processing time is proportional to the total time spent in PHP now. If PHP processing accounts for 90% of the time and they reduce that to zero, they'd have a 10x speedup. However, if it accounts for 10% of the time and they reduce it to zero, they'd have about a 10% speedup.
So, the question is: How much time (overall) is spent in PHP processing? My guess is not very much. As other posters have pointed out, there are disk accesses and MySQL. And quite a bit is cached in Memcached.
The original article is slashdotted now, so I'm not sure if it says what those 30k servers are doing, but Facebook has more than just PHP running. Perhaps a thousand of those servers are running Hadoop, probably calculating the social network.
From an architectural perspective, it probably does not make sense for them to optimize for processing speed (i.e., switch PHP to C++) if their performance is acceptable. That's because they face larger risks: modifiability and time to market pressures. They may worry that switching to a statically typed language (such as C++, but Java would be similar) would make new feature development slower. If they could have both, great, but these two quality attributes often trade off against each other. A design with better performance may hinder modifiability, and vice versa.
I don't mean to start a language war -- I'm speaking broadly about the idea that dynamically typed languages (PHP, Smalltalk, Ruby, Python,...) yield programs that are faster to write and modify compared to statically typed languages (C, C++, Java). You may disagree with that generalization, but you may agree that others think it is true, and are therefore acting rationally if they choose a dynamic language when they want modifiability.
Disclaimers: I knew Aditya in school but haven't spoken to him about Facebook; I am writing a book on software architecture.
Slashdot Mirror
John Latham is working with several collaborators (including Prof. Tom Choularton, University of Manchester, UK; Prof. Stephen Salter, University of Edinburgh, UK; and Prof. Mike Smith, University of Leeds, UK) on a proposed geo-engineering technique for global warming mitigation (Latham, 1990 and 2002 , Bower et al. 2006). A detailed account of this work is presented in the three papers linked, above.
The basic principle of the scheme is advertently to increase the droplet number concentration N in maritime stratocumulus clouds, thereby increasing their albedo (reflectivity) for incoming sunlight and also their longevity. This would produce a cooling effect, the magnitude of which could be controlled, and calculations and GCM computations both indicate that its magnitude could be sufficient to balance the warming due to increased atmospheric carbon dioxide concentrations resulting from the burning of fossil fuels. It is proposed to increase N by atomizing seawater at the ocean surface (producing copious quantities of droplets of around 1micron in size), and the significant fraction of these which rise into the low-level clouds above would act as cloud condensation nuclei (CCN), thereby creating additional droplets and enhancing N. The seawater droplets would probably be disseminated from a fleet of satellite-controlled unmanned vessels, deriving their required energy from wind or wave-power. Control over the degree of planetary cooling could be achieved via albedo measurements linked to a global climate model.
Technological questions regarding the production and dissemination of these particles remain to be resolved. Also, detailed examination of the meteorological and climatological ramifications of this proposed geo-engineering scheme would need to be conducted before justification would exist for its operational deployment. Two advantages of the scheme are that: (1) it is relatively benign, the only raw material being seawater; (2) if the disseminators were switched off, the droplets introduced into the atmosphere would fall back into the oceans within a few days.
First, a few helpful links:
Amdahl's law says that if Facebook were to switch from PHP to C++, the best possible improvement in the overall processing time is proportional to the total time spent in PHP now. If PHP processing accounts for 90% of the time and they reduce that to zero, they'd have a 10x speedup. However, if it accounts for 10% of the time and they reduce it to zero, they'd have about a 10% speedup.
So, the question is: How much time (overall) is spent in PHP processing? My guess is not very much. As other posters have pointed out, there are disk accesses and MySQL. And quite a bit is cached in Memcached.
The original article is slashdotted now, so I'm not sure if it says what those 30k servers are doing, but Facebook has more than just PHP running. Perhaps a thousand of those servers are running Hadoop, probably calculating the social network.
From an architectural perspective, it probably does not make sense for them to optimize for processing speed (i.e., switch PHP to C++) if their performance is acceptable. That's because they face larger risks: modifiability and time to market pressures. They may worry that switching to a statically typed language (such as C++, but Java would be similar) would make new feature development slower. If they could have both, great, but these two quality attributes often trade off against each other. A design with better performance may hinder modifiability, and vice versa.
I don't mean to start a language war -- I'm speaking broadly about the idea that dynamically typed languages (PHP, Smalltalk, Ruby, Python, ...) yield programs that are faster to write and modify compared to statically typed languages (C, C++, Java). You may disagree with that generalization, but you may agree that others think it is true, and are therefore acting rationally if they choose a dynamic language when they want modifiability.
Disclaimers: I knew Aditya in school but haven't spoken to him about Facebook; I am writing a book on software architecture.