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.

This seems pretty reasonable. The obvious risk is that if the encryption keys leak, all of your credentials may be retroactively compromised...

Still, much better than keeping the passwords in VC unprotected, of course.

My preference still is using environment variables so that the secure bits can be fully decoupled from your code, however..

While Lock-free code gets you part of the way to efficient parallelism (by removing suspension-induced dead time) as he mentions, the performance impact caused by repeated cache line invalidation can be a significantly bigger problem.

In many modern processor architectures (x86, for example), a cache-coherence protocol is used to ensure that cache lines provide data according to the memory discipline. On x86, that discipline is Total Store Ordering. (See http://en.wikipedia.org/wiki/Memory_ordering).

This means that if two processors are contending for the same value (eg. trying to increment it, set it to true, or even read it), they will force the CPU to invalidate the cache line containing the value on all the other cores, leading to massive scalability bottlenecks. If multiple cores are contending for the same location in memory, whether it's lock free or not, performance will suffer.

More deviously is the case of false sharing, where 2 different values just happen to fall on the same cache line. Even though they don't conflict, the processor must still invalidate the line on every core. Modern compilers do their best to prevent this, but sometimes they need a little help.

The takeaway is this: Don't try to implement your own locks using CAS -- even something as simple as a lock is very hard to get right (performance-wise) when scaling to dozens and hundreds of cores / threads. People have solved this problem (people.csail.mit.edu/mareko/spaa09-scalablerwlocks.pdf). Writing fast concurrent code (especially lock-free code) is a minefield of weird architecture gotchas. Watch your step.

Any plans for Linux support? Does the Windows 7 executable work well under Wine?

It's worth noting that some of the Go inconsistencies derive from the language designers desire to make the grammar regular (facilitating extremely efficient and simple parsing). In order to do this, you need statements that mean different things to the compiler to look different. This manifests itself in the (I admit, very inconsistent) var x int foo vs. x := 5 declaration. They mean the same thing to you, but different things to the compiler -- to preserve a regular grammar, they have to look different.

It's definitely a little ironic that what is needed to make a regular grammar makes the language more inconsistent.

The images in the right pane are blurry for me -- I guess they're getting stretched out on my monitor. Could you use vector graphics instead of JPGs?

Working in FF....

This is a big deal, opening up the possibilities for more side channel attacks against VMs located on the same physical hardware sharing CPUs and memory...