backtop

Print E-mail del.icio.us 52 comment(s) - last by EricMartello.. on Jul 22 at 4:58 PM
Facebook says that performance of Intel and AMD CPUs isn't what they tout in press

There are at times a significant difference between synthetic benchmarks that are run on CPUs and other hardware and the real world performance that parts are capable of delivering. The problem is that the software and environments that servers and processors run on in the real world are often vastly different that the industry standard server benchmarks.

An example is criticism from Facebook Vice President Jonathan Heiliger who claims that the new servers the social networking site uses are not showing the performance gains that Intel and AMD touted in the press.

According to Heiliger, engineers at the company are not seeing the performance gains expected. AMD has responded to the criticism from Facebook and eWeek reports AMD said that its CPUs are among the highest performing and most efficient available. AMD agrees with the issues on benchmark discrepancies with real world performance and says that what is needed most are benchmarks that reflect real world usage more accurately.

Heiliger said at the Structure conference on June 25, "The biggest thing that surprised us … is the less-than-anticipated performance gains from new microarchitectures. The performance gains they are touting in the press, we are not seeing in our applications."

AMD's Nigel Dessau defended the performance of AMDs Opteron processors saying that the problem for Facebook is that the company runs a highly specialized software stack and performance may be off because its applications run more PHP and Java than C++.

Dessau wrote, "Let's face it: Synthetic benchmarks are essentially a useful evil. Everyone wants to know how a certain technology performs against a standardized test, but what happens when that test [bears] no real resemblance to the real work people do? You get a huge disconnect."

AMD says that its new six-core Opteron parts are striking a balance between performance and energy efficiency. Energy efficiency has become as important to enterprise users as raw performance over the past several months.

Comments     Threshold


This article is over a month old, voting and posting comments is disabled
They didn't test the new servers first?
By Jellodyne on 7/16/2009 1:21:16 PM , Rating: 5
Surely Facebook bought 1 new server and did performance testing on it before they started replacing entire rights, right? Because if they didn't, they have nobody to blame but themselves. Sounds like either their bottleneck isn't on the CPU, or maybe their code doesn't scale well.




By Jellodyne on 7/16/2009 1:22:21 PM , Rating: 2
^...entire _racks_, right....^


RE: They didn't test the new servers first?
By rs1 on 7/16/2009 2:22:41 PM , Rating: 5
quote:
or maybe their code doesn't scale well.


That's the answer right there. Facebook is a giant tangled mess of PHP code, and given what is revealed about their underlying architecture through their platform API, I would not expect it to scale well at all.

Having an incompetent Vice President who expects new hardware to magically run faster than old even if the codebase is not necessarily optimized for it doesn't help either:

quote:
An example is criticism from Facebook Vice President Jonathan Heiliger who claims that the new servers the social networking site uses are not showing the performance gains that Intel and AMD touted in the press.


...new hardware doesn't guarantee performance gains in and of itself. This is especially true now that the biggest difference between new hardware and old is an increased level of parallelism. If your application is not designed in a way that allows it to take advantage of this increase in parallelism, then of course you are not going to see an increase in performance. In Facebook's case, I would suspect that database access would be the limiting factor, and a faster/more parallel CPU isn't going to help there. They should have purchased some enterprise-class SSD's instead.

Blaming the CPU for failing to improve performance in a storage-system limited environment smacks of ignorance, and I don't know how someone can end up as VP of a company as large as Facebook without knowing better than that.


RE: They didn't test the new servers first?
By MonkeyPaw on 7/16/2009 3:05:05 PM , Rating: 5
"Work smarter, not harder."

quote:
and I don't know how someone can end up as VP of a company as large as Facebook without knowing better than that.


Most large companies have more than one VP, and you'd be surprised just how high incompetence can climb on the corporate ladder.


RE: They didn't test the new servers first?
By kattanna on 7/16/2009 3:09:11 PM , Rating: 4
quote:
and you'd be surprised just how high incompetence can climb


one just needs to turn on c-span to see that.


By lco45 on 7/16/2009 8:22:47 PM , Rating: 3
RE: They didn't test the new servers first?
By XZerg on 7/16/2009 4:56:46 PM , Rating: 2
I still feel that the following applies in big corporations:

The higher up you are in the chain, the lower your IQ is!

Only few handful companies that have management staff that know what they are doing and are actually allowed to do so. Most companies I have seen the dumber management easily outnumbers the smarter or the smarter ones are limited in what they can do as their managers won't let them do anything.


RE: They didn't test the new servers first?
By grath on 7/16/2009 7:27:00 PM , Rating: 5
IQ is frequently inversely proportional to how loud and full of shit you are. Obviously being loud and full of shit serves a managerial career path far better than intellegence does.


RE: They didn't test the new servers first?
By riottime on 7/17/2009 3:16:36 AM , Rating: 3
we have a guy who used to be considered a good technical engineer. but when he got promoted to manager level, it didn't take long before he got lobotomized. on the other hand, another engineer in a different group got promoted into management still retained his engineering insight and skills.

unfortunately, there are more zombie managers than not. most really smart engineers that i know avoids taking management position unless they absolutely have no other choice. some have actually went from management back to lead positions because they love to do technical work instead of spending their days doing budget and schedules.

which leaves the type of engineers who are average at best that ends up in management position then eventually moves on to become vp.


By Eris23007 on 7/20/2009 7:15:59 PM , Rating: 2
I see things a little differently. Management and engineering distrust each other fundamentally because of misaligned priorities.

It is the mission of any engineer worth a damn to make the very best technical product he or she can. Period.

It is the mission of any project or program manager worth a damn to produce a technical product that is "good enough" to meet requirements and satisfy customers at the lowest feasible cost and in the fastest possible time. It is also the mission of said managers to establish a long-term business strategy, incorporating upgrades, new capabilities, greater requirements, etc. This is a very difficult balancing act and one that requires insight into long-term industry trends, appreciation for risk, comprehension of a portfolio management strategy, ability to handle / exploit organizational politics, and many other crucial skills. All the while they have to deal with HR issues such as unsatisfactory performers. It's a completely different job from being a technical individual contributor.

In some cases, the best engineers and the best project/program managers may be the same people. I've seen it happen. But in many cases the skills are so different that one can be excellent in one area and useless in the other. Engineers frequently make the mistake of thinking that a person's engineering skills dictates their value to an organization. "Zombie managers" certainly do exist, but the generalizations that are rife in engineering organizations are mostly derived from overwrought Dilbert-esque characterizations of management.

Purely functional managers (i.e. those who focus exclusively on people issues) are another story... :-P


By Nobleman00 on 7/21/2009 2:05:18 PM , Rating: 1
quote:
IQ is frequently inversely proportional to how loud and full of shit you are. Obviously being loud and full of shit serves a managerial career path far better than intellegence does.


WHERE IS THE +95 UPVOTE BUTTON? This person is a genious and should be quoted heavily on the topic of management.

No, they don't test servers. Manager's just say "throw 10 new boxes at it and let's see how it does."

"Stick a Corvette engine in a Chevy Aero, it will be fine."

"Make it an iPhone app, that will save us."

"If I am pervasive with the use of big words and say them loudly and vociferously, it will make the project run more good... pervasively."

"They're not ALL going to connect at the same time."

"My home internet connection is faster than that."


RE: They didn't test the new servers first?
By dsx724 on 7/16/2009 3:09:51 PM , Rating: 5
You're totally right. Having programmed for Facebook, the way they designed the application and feed platforms is a completely mess. When they introduce new features, they keep patching on new features instead of an overhaul. There's so many database IO operations that cascade into multiple databases that I doubt any hardware can handle it.
There are so many companies that plan around high-level languages that they don't realize the fundamental limitations of low-level subsystems. I think it's going to get worst as companies try to virtualize their servers on top of all the inefficient architecture they have.


By MrPoletski on 7/20/2009 5:36:01 AM , Rating: 2
hehe, sounds like facebook is gonna slow down and eventually stop and drown in its own sludge unless they have a coding revolution over there...


By HrilL on 7/16/2009 4:01:59 PM , Rating: 3
A lot of times its who was a better brown noser. The person with the dirtiest nose gets the promotion too much of the time.


By zsdersw on 7/16/2009 4:16:01 PM , Rating: 3
Just like with leftovers.. you know what floats to the top as it chills in the refrigerator.


By 67STANG on 7/17/2009 1:49:55 AM , Rating: 2
Agreed. PHP in general is going to need GIANT resources for millions of users. It can use all of the accelerators it wants, but will never be as fast as .Net-- which scales MUCH better than even JAVA, much less PHP.


By cornelius785 on 7/16/2009 1:51:44 PM , Rating: 2
I'm not that familiar with the what the effects of processor performance, RAM performance, and hard drive performance on web server stuff, but wouldn't having a good hard drive subsystem (and code to efficiently access it) and fast RAM have larger impact on web server performance than just upgrading the processor?

It is sort like upgrading subsystem X, when subsystem Y is limiting the performance, and expecting a large performance increase.




By onelittleindian on 7/16/2009 1:55:56 PM , Rating: 2
It depends on the site content. For extremely simple sites serving up static content, they tend to be memory-bound. Your average heavily-dynamic production site is cpu-bound. About the only sites that are i/o bound are those serving up large amounts of streaming media...and even these would tend to be cpu-bound if they have any transcoding to do. (not that that's very common).


By EricMartello on 7/16/2009 2:15:02 PM , Rating: 4
Streaming media is hardly I/O intensive. It's streaming. Transactional loads like those you get with databases are those that benefit the most from high IOPS.

Dynamic websites require CPU power since scripts are being executed as bytecode on server-side JIT compilers...as the number of requests goes up so does the load on the CPU. The efficiency of the underlying script can also have a drastic effect on the overall performance of the website.

I would imaging that a big site like Facebook has a lot of unnecessary bloat and other garbage in their scripts due to the number of different developers who work on it. High performance starts with the program/script. :)


By onelittleindian on 7/16/2009 2:32:36 PM , Rating: 1
"Streaming media is hardly I/O intensive."

Um, of course it is. Unless you're streaming a small enough content library that you can cache it all in RAM (a very rare occurrence) you're reading directly off disc. If you're having performance problems in this scenario, then its due to your i/o subsystem, NOT how fast or slow your cpu is.

There is NOTHING more i/o intensive than flat-file reading, without any need for post-processing or caching. That's the very definition of i/o bound.

"Transactional loads like those you get with databases..."

Did you miss the "web server" part above? A database server can be cpu bound (as I said). But that's not a WEB server.

"Dynamic websites require CPU power since scripts are being executed ..."

Which is exactly what are I already said.

"I would imaging that a big site like Facebook has a lot of unnecessary bloat and other garbage in their scripts "

"Bloat" in general hurts performance yes. But it doesn't necessarily impact scalability. If FaceBook is seeing extremely poor scaling, I imagine they're having contention issues.


By onelittleindian on 7/16/2009 3:08:01 PM , Rating: 3
" Are you familiar with the term I/O? It stands for INPUT / OUTPUT. Reading a file does not involve any writing"

Lol, I think its clear here who isn't familiar with the meaning of the term. Reading a file is I/O -- whether or not you ever write to that file. An app that does nothing but read files is going to be i/o bound.

"Streaming performance is mainly limited to the THROUGHPUT of your storage subsystem and it is not CPU intensive."

Which means streaming is I/O bound, not CPU bound. Exactly what I said in the first place.

"the web server is still responsible for encoding/compiling the scripting language of choice - a feat which can quickly eat CPU time"

Again, this is exactly what I said in the first place. Try reading posts before you reply.


By eldakka on 7/17/2009 2:35:35 AM , Rating: 2
Err, this is I/O.

You read data from disk and then write it to memory (probably to the NIC to stream it somewhere). It comes in (Input in I/O) from disk and goes out (Output) via a NIC. I/O does not requre reading from and writing back to the same device. The system is performing an I/O operation. If you can read in at 1GB/s from disk, but you only have a single 1Gb NIC and hence can only Output at 1Gb/s, then you are still I/O bound, on the Output side of I/O.

Also, I think you are confusing I/O, where a slash separating words means 'or', such as Input OR Output, with an IOP, which is an Input AND Output operation.


By onelittleindian on 7/20/2009 9:03:20 AM , Rating: 2
It's pretty clear who made the fake IDs here, since I seriously doubt there are two people in the entire universe stupid enough to believe your "I/O doesn't exist without writes" argument.

How many more people need to tell you you're wrong before you wise up?


By EricMartello on 7/22/2009 4:58:02 PM , Rating: 2
quote:
It's pretty clear who made the fake IDs here, since I seriously doubt there are two people in the entire universe stupid enough to believe your "I/O doesn't exist without writes" argument.

How many more people need to tell you you're wrong before you wise up?


A low transaction load is not I/O intensive. Are we struggling with the English or what?

Are you really an indian? If you are that means you're the equivalent of a burger-flipper in the world of tech. You get paid pennies to do mediocre work and are rarely expected to actually know anything. In fact, you should be dodging bullets at a mini mart or overcharging people for rides in a busted up taxi cab...not pretending you know d1ck about computers.

Spam these comments all u want with your fake IDs. You got rated down for being a moron. I got rated down because this comment thread too I/O intensive for you to process. LOL


By Sunner on 7/17/2009 4:23:24 AM , Rating: 2
Stop being such a dimwit, you're wrong, I/O does NOT imply that both happen.
Go read up on the matter and learn something, heck you can start with Wikipedia and work your way from there.
http://en.wikipedia.org/wiki/I/O


By mindless1 on 7/17/2009 5:18:22 AM , Rating: 2
You totally misunderstand streaming servers, and yes I/O can be only reading, it would be retarded to write only O.


By Fritzr on 7/20/2009 5:09:05 AM , Rating: 2
Actually as noted above a streaming server is using both sides of I/O.

*The server CPU/RAM is receiving input from the data storage.
*The data storage subsystem is supplying output to the CPU/RAM.
*The CPU/RAM is supplying output to the Internet.
*The Internet interface is receiving input from the server CPU/RAM.

Whether this is done in parallel or sequentially, the server is performing multiple Input & Output operations for each and every streaming connection.

The load on the CPU will depend on how much of the I/O processing is done by the data storage hardware & the Internet connection hardware. If it is virtualized so that the CPU does the work (like a WinModem where everything accept the electrical connection is handled by the driver) then the CPU will affect throughput. If the processing required to fetch & send the data is handled in hardware (Modem implemented entirely in hardware with it's own onboard processor) then the CPU will have little or no effect on throughput.

So your throughput (input OR Output) will be throttled if ANY of those connections cannot handle the load. You can also get throttling if any of the subsystems have been virtualized and the CPU cannot handle the additional load efficiently (serial code vs parallel code on a 6 core processor for instance)


By MrPoletski on 7/20/2009 6:20:43 AM , Rating: 2
wow what an argument has been going on here.

I'd just like to say, streaming IO will produce a low transaction, high bandwidth use environment.

Databse IO will produce a very high transaction, medium level bandwidth environment.

The high transaction IO environment makes it far more difficult to get efficient use of your IO subsystem, the bottleneck would be the hard disks, the controllers or the CPU handling all these requests. I'd hedge a bet a balanced system would first run into hard disk/controller related performance issues as it expanded.

As for streaming IO, the low transaction level (i.e. likely fewer users, but more data being shifted) will produce lots of nice predictable reads, many of which can be cached (i.e. 100 people wataching the same channel). Because of the lower transaction levels more efficent use of the storage hardware is possible. I'd hedge a bet a balanced system would first run into internet upstream bandwidth issues as it expanded.

Which server type has a higher IO load is far too open to interpretation to factually state. Is bandwidth use more or less important than the physical number of transaction requests you receieve?

Well bandwidth use is equal to the number of transactions received multiplied by the average transaction size. As you move down in transaction size and up in transaction volume you make your IO subsystem less efficient - but there is dedicated server hardware out there to specifically address this.


By EricMartello on 7/22/2009 4:50:33 PM , Rating: 2
Wow, it's about time someone with an IQ over room temperature responded. :)

quote:
As for streaming IO, the low transaction level (i.e. likely fewer users, but more data being shifted) will produce lots of nice predictable reads, many of which can be cached (i.e. 100 people wataching the same channel). Because of the lower transaction levels more efficent use of the storage hardware is possible. I'd hedge a bet a balanced system would first run into internet upstream bandwidth issues as it expanded.


You are correct.

quote:
Which server type has a higher IO load is far too open to interpretation to factually state. Is bandwidth use more or less important than the physical number of transaction requests you receieve?


When most server admins talk about I/O they are referring to the activity between the CPU, Memory and Mass Storage. If someone says an application is "I/O Intensive" they are saying that there will be a high amount of I/O transactions. If they load is high throughput it will be restricted primarily by bandwidth.

I can tell you from experience that a media server - serving audio or video streams - can quickly saturate its upstream WITHOUT placing a heavy load on the CPU, Memory or Disk Subsystem. For a DB server, it typically works out that the CPU or I/O system hits its limitations BEFORE the upstream, and the entire I/O subsystem will be under heavy load.

As per the original discussion of this comment thread, the point is that Facebook would probably have noticed a more significant improvement in performance IF they had improved their I/O subsystem along with the AMD CPU, rather than expecting a CPU alone to speed everything up.


By EricMartello on 7/16/2009 2:11:22 PM , Rating: 2
Yes, that is true. DATABASE-INTENSIVE site like Facebook or a large dating site with many simultaneously active users would benefit more from a faster storage subsystem than straight CPU power.

Even with dedicated DB servers, a web server will probably gain the most noticeable performance from more memory, faster memory and faster storage. Moving away from mechanical HDs to SSDs will no doubt breath new life into web servers running on older CPUs.


C++ ?
By cgrecu77 on 7/16/2009 1:25:26 PM , Rating: 1
yes, there are thousands of websites built in C++ ...

while I don't understand the complaints from Facebook, they should have tested the new architecture before implementing it, and usually web servers are not limited by CPU power anyway, I don't get AMD/Intel's response either.

Technically is possible to build a website in C++, but why would anybody do that?




RE: C++ ?
By onelittleindian on 7/16/2009 1:45:49 PM , Rating: 2
Huh? Web servers are almost always cpu-bound. Backend data servers can be cpu or i/o bound, but web servers typically are doing nothing more than (a) translating incoming requests into web service or data requests, (b) generating content dynamically, or (c) serving up a generally small set of files, which are usually cached in memory. All 3 of these are cpu-bound operations.

As for the number of sites written in C/C++/C#, its much more than you think. Even sites that have their highest-level framework in PHP or some other scripting language often have a lot of the low-level "heavy lifting" done in C++ -- assuming its a complex, commercial production site, that is.


RE: C++ ?
By dsx724 on 7/16/2009 3:19:26 PM , Rating: 2
Most web servers wait are not bound at all. They mainly sit back and wait for the backend DB servers to run their poorly coded queries against multiple tables per request. One webserver can handle 5000+ requests a second without fail but the DB server will pretty much bomb if it is working with a large dataset and join statements.


RE: C++ ?
By nafhan on 7/16/2009 2:40:57 PM , Rating: 2
Apache was written in C...


RE: C++ ?
By MrPoletski on 7/20/2009 6:24:07 AM , Rating: 2
No, it was written in Shadows.


RE: C++ ?
By 67STANG on 7/17/2009 1:53:01 AM , Rating: 2
C++ is probably for server apps that handle specific duties with the website as it is an OS language-- not a web language. C# is a web language, but is based on the .Net framework (Microsoft) and that isn't what they are using-- as it clearly states they are using PHP. This means their site is built on LAMP.


Good car - bad rider
By axias41 on 7/16/2009 1:17:55 PM , Rating: 3
A better car doesn't make the rider more capable




RE: Good car - bad rider
By MrPoletski on 7/21/2009 11:05:31 AM , Rating: 2
It makes the girls think he has a bigger manhood, however.

At least, he thinks it does.


By mvpx02 on 7/16/2009 4:22:56 PM , Rating: 4
I'm not a very active facebook user (I login 3-4 times per year) but I've heard a lot of complaints about slowdowns after recent website "upgrades".

It sounds to me like Facebook never designed their software to scale efficiently (understandably so), but instead of overhauling their inadequate code when red flags started appearing (surely 10's of millions of accounts ago) and planning how to properly and efficiently run what would end up being one of the internet's busiest websites, they just kept throwing more hardware at it (not a terrible short-term strategy, but a stop-gap at best). Unfortunately, with their current size, they've probably now reached the tipping point and hardware upgrades alone can't continue to compensate for inefficient programming.

Facebook is probably hoping that, by going on record blaming underperforming hardware, they can have a scapegoat in place to blame for inevitably more frequent gripes about website performance as they continue to grow.

I can't remember ever seeing another major internet company publicly question the performance of the servers that host its website... as far as I know, AMD, Intel, Sun and the other chip and hardware manufacturers catering to the webserver industry have a pretty good performance track record.




This is very funny.
By atlmann10 on 7/16/2009 11:20:18 PM , Rating: 2
I have said for years now that hardware is beyond the point in many aspects. We still run hard drives in general that are what 5 years old from a minimal outlook. The processors are quad going on 6 then 8 cores, but the largest amount of software has trouble using beyond one core. Some may use a second core to a middling degree, but 6 or 8 that's a joke. Yeah maybe if I was running a blade center unit or a main or database server. That is because everything is multi-threaded on a corporate strength unit.

The software has gotten seriously behind the hardware. This guy bitc7ing in a publicly viewable way about running on messed up singular code models needs a brain examination. I am seriously surprised this article is not titled AMD sues facebook CEO. Then you look at the Intel comment, I know how readily able they use there legal team, so I will be looking for the Intel sues facebook for slander or it and 10 other things in the next few weeks.

I think Microsoft is right with there current push to 64 bit, as it is much more robust and expandable. But what is up with all the other companies still not even being able to use 2 or more cores effectively. Do I not pay for current software? Then how many people have a single core cpu? I have one on one machine the other 3 are all multi.

I also second the other comment; if he upgraded his whole grid, without first buying or bringing in a single unit and estimating the improvement has no one to blame but himself.




RE: This is very funny.
By rippleyaliens on 7/17/2009 12:36:11 AM , Rating: 2
Well there is also the simple thing, of Complete Stable System. I could have quadx6 core servers, 128gb ram, and such, and still have slowwwwww access, and huge bottlenecks.
YET I have personally installed, Dual Quad Servers, 64GB ram, BUT with a RAM SAN, which just DEVASTATES any machine i have ever worked on. IOPS were on the magnitude >600,000 IO's Per second, >4.5GB of sustained data transfers... Access less than 15 micro seconds..
Slower Server than the BEST of the BEST, but a superior system never the less.

We can always say that facebooks code is buggy, etc.. BUT re-writing that takes more than just saying that it is bad.. A good SYSTEM, meaning the entire system.. = Performance..

PS.. Ever wonder how google, Microsoft's Sites are sooooo fast??? Easy, =-= They do this thing called putting in a good system. The front End of google, is of all things, powered by a Citrix Device.. Netscaler FTW..... PS i would think that facebook has a number of Netscalers, (i would hope).. SO yes, there is the secret of googles speed.. Netscalers...


Synthetic benchmarks are...
By Motoman on 7/16/2009 3:30:11 PM , Rating: 2
...synthetic. As in, they aren't testing anything "real." So while they may provide an available tool to compare different products (CPUs in this case), ultimately you have to be cognizant of the fact that your specific applications weren't included in that benchmark (unless, of course, they were...in which case rock on).

Also, when you're writing all of your own custom code/applications, you have to remember that you're the one responsible for them, and that there's no way to predict their performance...like you could with off-the-shelf apps like SAP or SQL Server. Ultimately, the performance and scalability of your custom code is up to you...and if you write crappy code (or it physically has natural limits to performance/scale anyway), you can throw all the hardware you want at it and it won't get better.

This is why MS et al don't "benchmark" Visual Studio and other similar development environments. There's no "benchmark" for C# per se, any moreso than one could write "equivalent" code in C#, C++, and PHP and compare them - at which point the "equivalence" of the code is probably going to be an issue you're not going to settle anyway.

At any rate, I think FB should stop whining at AMD and/or Intel and try to optimize it's code. Or at the very least stop whining.




RE: Synthetic benchmarks are...
By dark matter on 7/16/2009 6:59:22 PM , Rating: 2
Stop whining? Ha. In this day and age it always someone elses fault that your product/service isn't working. No-one ever seems to accept responsibility for their own actions any longer.

You see it all the time. Tyres bursting? Not our fault, blame pirelli. Batteries exploding? Not our fault, blame sony. Erm no, I blame you, you put them on the car and you fitted them to the laptop, the buck stops with you for using crap parts.

Hurt feelings? Didn't get a pay rise? Someone winked at you slightly funny. You burn't yourself on that coffee you just bought. You fell of a ladder at work. Sue someone. It surely isn't your fault, hell no.


RE: Synthetic benchmarks are...
By Tsuwamono on 7/17/09, Rating: -1
this should show...
By ipay on 7/17/2009 1:43:39 AM , Rating: 3
facebook's VP to shut his mouth when he has no idea what he's talking about.




hahaha
By Tamale on 7/16/2009 1:14:16 PM , Rating: 2
lol.. serves 'em right for expecting the same gains in PHP as they saw in benchmarks using C++. that's all I have to say about that.




synthetic garbage
By GlacierFreeze on 7/16/2009 1:59:36 PM , Rating: 2
I never buy hardware based on synthetic benchmarks. They're useless.




looking in the wrong place
By zephyrprime on 7/16/2009 2:50:49 PM , Rating: 2
They're probably limited by their data backend. They probably upgraded their request processing with new computers but didn't upgrade their data backend also.




"Spreading the rumors, it's very easy because the people who write about Apple want that story, and you can claim its credible because you spoke to someone at Apple." -- Investment guru Jim Cramer











botimage
Copyright 2009 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki