shepik

Niice. So if somebody were to mark all non-action scenes (like dialogues) in action movies as "language", i' be finally able to watch some real action. Nice.

So, they optimized "Round" which took 18 seconds, and by that reduced total cpu time from 53 to 23 seconds. Did I get that right?

You don't. The man who wrote that code does.

And judging by his response, i'd say he did - http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02919.html

To be honest, Linus' rants is making a better point for me. I really feel his pain with overflow_usub, and i feel nothing when reading rewritten version.

This sounds like a depression. Not as a "I'm in a bad mood" depression but as a medically diagnosed illness which has to be treated properly. So please, go visit a doctor.

I believe an efficient algorithm should combine recursive approach http://stackoverflow.com/a/28027063 with sse-based small matrices transposer http://stackoverflow.com/a/16743203

Also, a good reference point to compare performance to is math libraries, like eigen/mtl/ibm essl or something like that.

Tight coupling and money are a good arguments, thanks. However, i believe we are comparing apples to oranges here. IIS uses it's own kernel module, HTTP.SYS - http://www.microsoft.com/technet/prodtechnol/WindowsServer20... So, looks like having specific kernel api optimized for your particular usecase is an advantage, which IIS has and others don't.

It turns out there are kernel-mode webservers (or there were, at least), which seriously outperform user-mode ones. https://www.usenix.org/legacy/events/usenix01/full_papers/jo... (page 11; article is old, but anyway)

> MS stack is more performant than the Linux one on the same hardware

Could you please provide some evidence to support that?

What does "20 Knowledge bases" mean? Is it 20 articles, or 20 independent sets of articles?

imo git is hard, because it is hard to think of history as a tree. also, problems we solve with git are harder than what we used to solve with subversion or cvs. i mean, most of the git problems i or my colleagues ever encountered happened because of a rebase, or rebase + merge, or merge + rebase, or similar combinations, when we tried to rewrite history to make it clean and readable, and we never even think about "clean history" back then.

You can grasp in about an hour concepts like "index", "staging area" and other that the article mentions.

The paper assumes that git is hard because there are lots of concepts, like "Tracked file", "Ignored file", "File staged for removal", "Untracked file" etc. They also think to remove index as a way to reduce complexity.

But those are not the reasons why git is hard.

I've gone through picking embedded key-value store, too.

What really concerns me is why never in benchmarks they perform on already filled database (like, 14G, 28G, 60G)? Because "add 100k random keys into an empty database" is very different from "add 100k random keys into a large database". And that is where more novel algorythms start to shine.

Yes, read speed of leveldb (and, i assume, sophia) with its fancy sst's is lower than of plain old b-trees or hashtables (kctree/kchash), but it is still high enough for most tasks. Write performance of kc* (and btree-based libraries in general) is, however, unacceptable, at least on hard drives, and even with a reasonable-sized database (~90% of RAM) it degrades to a couple of random write per IOPs (so, 200-300 writes per second on a consumer-grade HDD, or up to 1000 on a 2x10k sas hdd in raid-0, if i remember correctly)

It may be reasonable to use kc* on SSD, but i did not test that.

At my last job, the coolest project i did was to create an image duplicate detection system (so that it would tell, given an image, that the image is new, or it's a version of what was uploaded before, or the image contains fragments of some known image, etc). It used opencv for feature points detection, so i had to maintain an index to search for those points (there were around 7M images, and load was up to 50 rps). I came up with a rather clever algorithm, which as i later discovered (thanks, wikipedia) is a kind of implicid k-d tree.

That task was the most algorithm-intense task I ever had, and that algorithmical part took 20% of the time. 80% was straight coding, glueing things together, testing and putting all that in production system.

So i should be taxed more, if instead of spending all my income month-to-month i shopped wisely and saved some money in the bank. That sounds right!

If that kind of tax was implemented in all countries, this would render almost all phone manufacturers (except, well, you know, Apple) unprofitable. In fact it would not: they'll just raise prices, and we, as customers, will effectively pay this tax, not businesses.

At least two questions are bad.

7. a = "5"; b = 2; c = a+++b;

Why even ask that? It's boring. And operator precedence is not really important in practive, and it's bad style and no one writes like that. It's a question for junior-level interview, when you can't ask anything meaningful and (because you have to ask anything) you ask _this_.

9. (16).toString(16)

Oh, so Guru should memorize every obscure parameter, shouldn't he?

Other questions are fine, though (except 10. Numerical systems, c'mon, it's 2013, not 1980s)

Troll's claims were "dismissed with prejudice", according to Kaspersky's personal blog. So, i suppose, this means that effectively the patent is invalid.

http://eugenekaspersky.files.wordpress.com/2012/06/dec.png

http://translate.google.com/translate?sl=ru&tl=en&js...

upd: court order: http://www.scribd.com/doc/98161737/Https-Ecf-txed-Uscourts-g...

http://www.scribd.com/doc/98161154/Https-Ecf-txed-Uscourts-g...

Some time ago I wrote a system to collect performace statistics for my company's internal use (we have 100+ application servers - 4-6core 2xcpu hardware servers - and 1 server running the statistics). And then we released it as open-source. Our system shows not only by-service- or by-source-script- statistics, but also which services are used by a particular script. Drawback: all information is in russian.

pics: http://imgur.com/a/idFF6 https://github.com/mambaru/btp-daemon - and google-translated text https://gist.github.com/3139890

Anyone interested? Is it worth to translate it to english?

I'd suggest adding "take this regular function and return function callable with array" function: https://gist.github.com/3029279

(also, this variant is better because you can mitigate performance losses by moving all reflection operations out of lambda function to its parent, make_named_array_function)

* a global server lock

It's gone

* The query engine of MongoDB still can only use of one index per query. How insane is this?

MySQL uses one index per query and it's fine with that. What else do you want? It's a tree index, there's no any magic there.

* Having no option to perform an operation comparable to UPDATE table SET foo=bar WHERE..

In fact, you have that option. That's what modifier operations are for.

* there are already too many moving parts in a setup for scalable applications.

Oh my god! Creating scalable applications is hard! I thought MongoDB would do that for me, but it did not.

I think that no-nosql hype is even worse than nosql hype. That's when you suddenly realize: no, it's NOT WEBSCALE.

Awesome, indeed. What does that mean, though?

Yep, but i you can call "loosing the scope" as "specifying data dependencies explicitly" :) It all depends on a use case, though.

Y U NO USE your cache like that:

  $data = $cache->get('key',function() {
    // do the stuff if cache misses
    return $some_value_to_be_cached;
  });

? It's quite handy and it forces you to separate actual logic to get the value, which is good by itself.

I don't think there is an issue with graceful degradation. Basically, wkterm is a terminal and a set of pretty-printers that read data from stdin and print it in html. As in my example with cpu usage graphic, there is some ./gen_cpu program which just prints cpu usage values as text, and there is graph drawing program. So, use them both for graphical output and use only the first for text.

Links, as you describe them, can be implemented with javascript. I'll try to make an example on weekend.

Some months ago I tried to improve shell while keeping all it's features. So i made webkit-based terminal emulator (pseudoterminal; like xterm) with special esc-sequences to turn on html output (in a console, yes). Screenshots: https://github.com/shepik/wkterm/#readme