Comment Re:will this help with the swap-paralysis problem? (Score 1) 603
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.
Comment Re:Take it a step further... (Score 1) 591
Submission + - Open Source Music Fingerprinter C&D'd (google.com)
Nushio writes: The code wasn't even released, and yet Roy van Rijn, a Music & Free Software enthusiast received a C&D from Landmark Digital Services, owners of Shazam, an Android application that allows you to find a song, by listening to a part of it. And if that wasn't enough, they want him to take down his blog post (Google Cache) explaining how he did it because it "may be viewed internationally. As a result, [it] may contribute to someone infringing our patents in any part of the world".
Comment Re:For a day? (Score 1) 460
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.
Comment Re:WoW? (Score 1) 122
Or how would you preserve Assassins Creed 2?
Comment Re:Pfff... (Score 1) 1213
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?
Comment Re:XP + 3 TB?? (Score 1) 467
Because Win7 probably costs more than a 3TB disk.
Comment Re:This will fail (Score 1) 227
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.
Comment Re:Have You Actually Tried It? (Score 1) 460
Mark IRC as "Always on Visible Workspace".
Comment Re:OpenGL and the rant about marketing (Score 1) 515
Give me one example where OpenGL lags behind Direct3D?
Comment Re:A C app would be much faster (Score 2, Informative) 752
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 still have to wait for data! You're not magically reducing latencies by switching to C. There are many layers of latencies in a complicated web application, from the front end facing the user to the backend storage. Making one layer go faster doesn't magically fix the other bottlenecks. And the bottlenecks are mostly I/O or network latency. (And developers...)
Comment Re:He's not wrong.... But... (Score 1) 752
Facebook uses Alternative PHP Cache and has contributed a lot to the project.
Comment Re:10:1... Really? (Score 1) 752
Exactly. Most of the time is spent waiting on I/O anyway!
The Definitive Evisceration of The Phantom Menace *NSFW* 629
cowmix writes "When TPM came out ten years ago, its utter crappiness shocked me to the core and wounded a entire generation of geeks. My inner child had been abused and betrayed. I moped around, talking to no one, for almost two weeks. I couldn't bring myself to see #2 or #3, whatever they were called. Now, a decade later, comes Star Wars: The Phantom Menace Review, the ultimate, seven-part, seventy minute analysis of this mother of all train wrecks. Not only does it nail how the film blows, but tells us why. Time, apparently, does not heal all wounds." Or, if you prefer all 7 parts embedded in one page, you can check out slashfilm's aggregation.
Comment Re:Thanks Mark (Score 1) 163
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?
