I saw this on my 2GB laptop with Intel X-25M SSD. Whenever I hit about 1.6GB used ram it would swap for several minutes, and sometimes grind to a halt.
That's not what he meant. Say if there are 5 lanes, and 5 cars in front of you. In the US, they will frequently line up each in their own lane, and cruise at the same speed, so it's impossible to pass them. In Europe (most countries I know at least), there's a rule that if the outermost lane is not full, and you are not passing, you should stay out there. Not so in the U.S. So you very much have to drive "zig zag" to get anywhere.
To make it fair, if most people still ran 2.4.18, then programs like Firefox would be made to work on that kernel. Same with most of the other programs you mentioned. (If 2.4.18 was as big as XP, then graphics cards would also support it). If that was the case, then why would you upgrade?
So people who download a movie, likes it, and goes and buy both the DVD and Blu-ray are not customers?
What about people who buy Ubisoft/EA games, comes home, finds out it doesn't work, and have to download a crack to get it to work? Not customers? Why not?
Both are happening with increasing frequency for me and my friends.
The proposed ratio of 1:10 is real, if not bigger. And here's why:
1.) For each request, PHP has to load entire application responsible for that particular response, including its configuration, etc. With memcache(d), you have to instantiate connection classes and reconfigure them, per request. Languages like C/C++, Python and Ruby have different architecture to begin with. They load ONCE and each request triggers a FUNCTION or METHOD of a class, with all the app-specific configuration, db and memcached connections done and configured on app init, NOT per request.
With caches like APC, overhead is very much mitigated. PHP can also use a pool of connections to memcache/database to minimize connection delays.
2.) TFA mentions microsecond relevance! Even a simple echo "Hello World" will take much more time than similar action in C. I have yet to see a PHP helloworld app that does it in under 1msec, let alone the microseconds required.
helloworld.php takes 0.363ms on average here on my laptop.
3.) Arrays in PHP are slow, being always hashmaps. Other data structures can speed up things. You don't always need hashmaps. SPLFixedArray() is a joke, btw, and available only as of 5.3. Can't compare it to a vector anyways, and lots of fixed structures can be represented by structs or classes in C which are anways faster than in PHP. Also the app can instantiate them once on init, and just (re)load when required.
PHP can also instantiate it once, with the use of APC cache. It caches opcodes (and thereby constant values/arrays), and you can also cache any data you want, and loading that data is fast since APC is written in C (some small overhead).
4.) Even if all the app does it parse input vars and call memcache(d) / database funcs/methods to retrieve/store data, those calls are faster in C. Params can be parsed quicker in C, not requiring hashmaps for instance.
Is waiting on I/O in C faster than in PHP? Nope. So if you're mainly doing database lookups you'll see extremely low speedup porting your code to C.
5.) FastCGI is crap. If this app were to be done in C, then it would require its own HTTP layer, epoll based (for Linux). It can take out all the crap in HTTP that is not requred to parse the AJAX calls, and does not need to be "generic" enough to deliver static content.
I know. I'd like to get rid of that crap too. But is it really worth it? Making a very efficient server with all the capabilities your application has now, with all the error checking, testing and security protections would take months. HTTP is more complicated than you'd think.. Is the small speedup you'd gain, versus the maintenance of a much larger application worth it?
6.) For such dedicated and distributed deployments, garbage collection is sometimes not required. For instace, fixed-length stuctures can be preallocated upon app init, and the app can really take as much RAM as possible on startup. Yes, that would limit the MAX number of users/connections per server, but so what? The app dominates the server, nothing else is required to run (except basic OS environment for the app), so fixed memory consumption is not a problem.
7.) Even though each request has to wait for I/O of some sorts, either from memcache(d), from disk or from DB, you can process much more of these per front-end server and just scale backend servers as required. For example, with PHP your front-end server can serve 100k/sec, having X DB backends and Y memcached backends. With a C application, the front end can serve, say, 1M/sec. You still get to keep one front-end, even though you had to put more backends.
In short, you can significantly reduce the number of servers required if the app was written in C.
You're pulling those numbers out of thin air. You sti
Efficiency maybe? Moving your hand from coding position to mouse/arrow key position hundreds of times a day actually takes a lot of time. Same reason behind most vi commands.
The problem is that some of those actions that you can do to get "tokens" are just a scam. They say it's just a free survey, but at the end of the survey they ask for your phone number to confirm that you've completed it, and then they just charge you $9.99 a month until you figure it out. Farmville did exactly that, and I bet others do it too.
Slashdot Mirror
This is why I would like a "created" timestamp for files in unix file systems.
I saw this on my 2GB laptop with Intel X-25M SSD. Whenever I hit about 1.6GB used ram it would swap for several minutes, and sometimes grind to a halt.
Sounds a lot like wuala. There's a good tech talk about it.
That's not what he meant. Say if there are 5 lanes, and 5 cars in front of you. In the US, they will frequently line up each in their own lane, and cruise at the same speed, so it's impossible to pass them.
In Europe (most countries I know at least), there's a rule that if the outermost lane is not full, and you are not passing, you should stay out there. Not so in the U.S. So you very much have to drive "zig zag" to get anywhere.
Or how would you preserve Assassins Creed 2?
To make it fair, if most people still ran 2.4.18, then programs like Firefox would be made to work on that kernel. Same with most of the other programs you mentioned. (If 2.4.18 was as big as XP, then graphics cards would also support it). If that was the case, then why would you upgrade?
Because Win7 probably costs more than a 3TB disk.
So people who download a movie, likes it, and goes and buy both the DVD and Blu-ray are not customers?
What about people who buy Ubisoft/EA games, comes home, finds out it doesn't work, and have to download a crack to get it to work? Not customers? Why not?
Both are happening with increasing frequency for me and my friends.
Mark IRC as "Always on Visible Workspace".
Give me one example where OpenGL lags behind Direct3D?
The proposed ratio of 1:10 is real, if not bigger. And here's why:
1.) For each request, PHP has to load entire application responsible for that particular response, including its configuration, etc. With memcache(d), you have to instantiate connection classes and reconfigure them, per request. Languages like C/C++, Python and Ruby have different architecture to begin with. They load ONCE and each request triggers a FUNCTION or METHOD of a class, with all the app-specific configuration, db and memcached connections done and configured on app init, NOT per request.
With caches like APC, overhead is very much mitigated. PHP can also use a pool of connections to memcache/database to minimize connection delays.
2.) TFA mentions microsecond relevance! Even a simple echo "Hello World" will take much more time than similar action in C. I have yet to see a PHP helloworld app that does it in under 1msec, let alone the microseconds required.
helloworld.php takes 0.363ms on average here on my laptop.
3.) Arrays in PHP are slow, being always hashmaps. Other data structures can speed up things. You don't always need hashmaps. SPLFixedArray() is a joke, btw, and available only as of 5.3. Can't compare it to a vector anyways, and lots of fixed structures can be represented by structs or classes in C which are anways faster than in PHP. Also the app can instantiate them once on init, and just (re)load when required.
PHP can also instantiate it once, with the use of APC cache. It caches opcodes (and thereby constant values/arrays), and you can also cache any data you want, and loading that data is fast since APC is written in C (some small overhead).
4.) Even if all the app does it parse input vars and call memcache(d) / database funcs/methods to retrieve/store data, those calls are faster in C. Params can be parsed quicker in C, not requiring hashmaps for instance.
Is waiting on I/O in C faster than in PHP? Nope. So if you're mainly doing database lookups you'll see extremely low speedup porting your code to C.
5.) FastCGI is crap. If this app were to be done in C, then it would require its own HTTP layer, epoll based (for Linux). It can take out all the crap in HTTP that is not requred to parse the AJAX calls, and does not need to be "generic" enough to deliver static content.
I know. I'd like to get rid of that crap too. But is it really worth it? Making a very efficient server with all the capabilities your application has now, with all the error checking, testing and security protections would take months. HTTP is more complicated than you'd think.. Is the small speedup you'd gain, versus the maintenance of a much larger application worth it?
6.) For such dedicated and distributed deployments, garbage collection is sometimes not required. For instace, fixed-length stuctures can be preallocated upon app init, and the app can really take as much RAM as possible on startup. Yes, that would limit the MAX number of users/connections per server, but so what? The app dominates the server, nothing else is required to run (except basic OS environment for the app), so fixed memory consumption is not a problem.
7.) Even though each request has to wait for I/O of some sorts, either from memcache(d), from disk or from DB, you can process much more of these per front-end server and just scale backend servers as required. For example, with PHP your front-end server can serve 100k/sec, having X DB backends and Y memcached backends. With a C application, the front end can serve, say, 1M/sec. You still get to keep one front-end, even though you had to put more backends.
In short, you can significantly reduce the number of servers required if the app was written in C.
You're pulling those numbers out of thin air. You sti
Facebook uses Alternative PHP Cache and has contributed a lot to the project.
Exactly. Most of the time is spent waiting on I/O anyway!
Ubuntu is not dumbed down. It just got sensible defaults, so you don't have to configure everything.
Name one thing I can't do on Ubuntu that you can on your "un-dumbed down" Linux?
Progress Quest is the best game ever. I play it all day and night!
Efficiency maybe? Moving your hand from coding position to mouse/arrow key position hundreds of times a day actually takes a lot of time. Same reason behind most vi commands.
If a Facebook server goes down, you could possibly lose your friends!
Does anyone know about an open source alternative to Google analytics? Something that gives a more information than just webalizer/awstats etc.
Any FPS game will show what's the PC's good for.
It even messes with your EXIF data without you knowing.
The problem is that some of those actions that you can do to get "tokens" are just a scam. They say it's just a free survey, but at the end of the survey they ask for your phone number to confirm that you've completed it, and then they just charge you $9.99 a month until you figure it out.
Farmville did exactly that, and I bet others do it too.
Remember, that's $0.20 per incoming and outgoing message. So AT&T earns $0.40 for each message going through their system.
How do you get a guided tour at a data center?
So this is just a way to not having to upgrade their capacity at bottlenecks... Great.
I hope btrfs will get it. Or else you will have to add it :)