rcoh

The stdlib rand() function on unix has a global lock around it provided by many versions of Linux. As such, if rand() is called in performance critical parallel code, performance will tank as each thread or process attempts to acquire this lock. Even if this lock is not acquired, you will still have a race condition on the state of the random number generator and may produce bad (non-random) randomness.

Use rand_r(unsigned int *state) instead in parallel and concurrent applications.

Sources: man 3 rand [unix command] http://unixhelp.ed.ac.uk/CGI/man-cgi?rand+3

From github: The algorithm is iterative deepening depth first alpha-beta search. The evaluation function tries to minimize the number of tiles on the grid while keeping same/similar tiles in line with each other.

This basically means he's running an optimized version of minimax -- essentially, depth first search of game states looking for states that minimize tiles and keep them in line.

At each step, he looks several steps into the future, assigns them each a numerical score, then picks the move that leads to the best outcome.

Iterative deepening means that he evaluates all 1 move options, then all two move options, then all 3 moves options and so on. It increases the chances of finding a good move within a time constraint.

Alpha beta is a "lossless" optimization that allows you to more aggressively prune the tree when you're searching.

Was that article thrown together in 10 minutes? It's filled with typos: "But federal safety regulators on Tuesday classified as a recall Tesla' move to provide upgraded wall adapters and charging software, citing the risk of fire."

"involving a Model Sin Irvine, California, which the "

"Separately,three road fires in"

As a gut check, if you're solving some replication problem and you'd consider using Paxos to solve the problem, be /very/ wary and reason extremely carefully about why your weaker solution will provide the same guarantees. Chances are, it will fail in certain cases of network outage or system failure.

The US hasn't adopted EMV because it isn't necessary. EMV was created because in Eastern Europe many businesses didn't have sufficiently reliable phone and internet connections to validate credit cards -- in the US we have no such problem.

The cost of rolling out EMV was determined to be greater than the cost credit card companies paying for the increase in fraud and chargebacks out of pocket.

1. I'm thinking of it being connected with Google Play.

2. Once you've increased the scope beyond the apps on the device, work needs to be done to show the most relevant and useful actions.

3. Enabling flows like:

- Take file from one app, edit in another app, save back over the original file

- Take an email attachment, edit / modify in another app, then reply back on the same thread

4. But there is no reason a third party can't come in and make it happen.

An Android phone is my primary device. A few key issues for me:

1. No app discovery -- I want to find out about apps that can work with my content.

2. Action curation -- I want to see the actions that other people think are most useful when dealing with my content.

3. No "Return" actions -- eg. The context knowledge necessary to reply to the same message, or overwrite an existing file.

4. Cross device and cross OS: If this is done right, there's no reason for the action to be bound to just one device or even one person.

This is a good start -- http://x-callback-url.com/ is a standard and listing for apps that support it. The biggest problem is that there is a limited amount of data that you can transfer in a URL (about 80KB I believe) so even large PDFs will start to cause problems.

Yes. The Ubuntu Phone / OS is a interesting byproduct of this idea.

There's a difference between the performance you want in your kernel and the performance you need sharing to Facebook. It seems like creating monolithic mobile apps is premature optimization.

Ah, yeah. I was talking about iOS in particular. Android intents are pretty sweet -- a couple the missing bits to make them great in my mind are -- App discovery: tell me about apps that can use my content if I don't have any? -- Action curation: What do users think are the best app for this action?

We think that the key is to provide a limited and controlled interface between the apps (which is what we're trying to do). We'll see how it goes :-)

Intents are useful, but could be better. A standard way to hook into the Facebook app is fine for Facebook but what about when the space is more fragmented? Should app authors have to integrate with every document viewer or Mail App?

Ah, thanks for the heads up. I've updated the footnote.

It seems that what you actually want is for CoffeeScript to have configurable backends. I agree that it's silly to generate IE6 compatible code when I know that I'm targeting node. This isn't a reason not to use CoffeeScript -- it's a reason to improve CoffeeScript.

Furthermore, as others have noted, your post does smack of premature optimization. Without numbers, most of the claims are all pretty meaningless. Judging by number of instructions is no longer a valid metric on any platform on any level of abstraction and hasn't been since the 1980s.

Times must be hard if you're selling free t-shirts for money :-p

I'm especially excited about the race detector. It looks like a practical implementation of http://cseweb.ucsd.edu/~savage/papers/Sosp97.pdf. Always exciting to see research coming up in practice!

For a while, Linked in was present a password input box that looked like "You failed to login, try again" at a glance, but in reality it was asking for your email address and password. From that point, they could read your email and extract all your contacts.

Ironically, I'm seeing 500s. Great for testing my reliability in the face of errors!

Why not just use Filepicker?

This is missing Spring config! How could is possibly be considered a real enterprise app without at least half of its logic encoded in XML!

503....Whoops.

I became irritated when quick sort was claimed be O(n^2). Not only is that not true in practice, it's just wrong for all but the simplest implementations of the algorithm.

With minor tweaks to the selection of partitions, quick sort can be made O(n lg n). Specifically, if combined with linear time median finding, we can pick perfect partitions every time. (Of course, this algorithm is painfully slow in practice).

All this said, the idea of analytic combinatorics is interesting for a deeper understanding of algorithm performance. It quantifies behavior that good engineers understand is swept under the rug by Big-O notation.

Of course, if you really want good performance, you'll have to understand the algorithm beyond just it's combinatorial properties -- caching locality and coherence, branch mispredictions, function call-overhead etc. play an enormous role when it comes time to really make code fast.

To write fast code, you need the whole picture.