Recent submissions

Comment · 5 years ago
market cap = book value + discounted future cash flows = share price * number of outstanding shares

When you do a buyback, the book value drops (company loses cash), but the discounted future cash flows remains unchanged. The number of outstanding shares also drops.

The net result is the stock price increases as a company accumulates cash and uses it for buybacks because the number of outstanding shares drops.

Another way of thinking about it is that it's the same as dividends, but the dividend only goes to the sellers of the stock during a buyback.

Comment · 8 years ago
Comment · 8 years ago
Comment · 8 years ago
People rarely train ML models on macOS for the reason you mentioned. Most machine learning work happens on Linux, so this should work well there.

TensorFlow supports a standalone server mode where it receives computation graphs and executes them. This is nice because then you can remotely execute on any accelerator (Cloud TPU, multi-worker multi-GPU) from your laptop.

In their demo, they did exactly that with a Cloud TPU: it connected to a TensorFlow server that executed the machine learning training part of the program.

Comment · 8 years ago
Comment · 8 years ago
Keep in mind that what you linked refers to TPUv1, which is built for quantized 8-bit inference. The TPUv2, which was announced in this blog post, is for general purpose training and uses 32-bit weights, activations, and gradients.

It will have very different performance characteristics.

Comment · 9 years ago
An exponent bit flip, especially at later layers, would completely break inference.
Comment · 9 years ago
Yeah, essentially a lot of supporting libraries were written in Python at first, and they need to be ported to C++ to make other languages train.
Comment · 9 years ago
I'll discuss this a bit during my talk at the dev summit.

The short answer is no.

The long answer is yes, but only if you create the model in Python, export it, and then feed training data in other languages. There are some people doing exactly that.

Long term, I'd like to give all languages equal footing, but there's quite a bit of work left.

Comment · 10 years ago
(I agree that thread-per-request works just fine in the majority of cases, but it's still worthwhile to write about the cases where it doesn't work.)

Responding to your original post: you argue that async/await intends to solve the problem of data races. That's not why people use it, nor does it tackle that problem at all (you still need locks around shared data).

It only tries to solve the issue of highly-concurrent servers, where requests are bound by some resource that a request-handling threads have to wait for the result of (typically I/O).

Coroutines/fibers are not an alternative to async servers, because they need primitives that are either baked into the language or the OS itself to work well.

Comment · 10 years ago
It's not clear what you're suggesting as an alternative. My understanding is that you're suggesting thread-per-request, which has many known flaws. There are three approaches to serving requests:

1. Thread-per-request. This is a simple model. You have a fixed-size thread pool of size N, and once you hit that limit, you can't serve anymore requests. Thread-per-request has several sources of overhead, which is why people recommend against it: thread limits, per-thread stack memory usage, and context switching.

2. Coroutine style handling with cooperative scheduling at synchronization points (locks, I/O). This is how Go handles requests.

3. Asynchronous request handling. You still have a fixed-size thread pool handling requests, but you no longer limit the number of simultaneous requests with the size of that thread pool. There are several different styles of async request handling: callbacks, async/await, and futures.

#2 and #3 are more common these days because they don't suffer from the many drawbacks of the thread-per-request model, although both suffer from some understandability issues.

Comment · 15 years ago
I think this is fair. Bandwidth costs money, usage likely follows a power law distribution, and their fees are reasonable:

AT&T: $10/50 GB = 20 cents/GB

Amazon S3/EC2: 10 cents/GB

It's not like we're being gouged here...

Comment · 15 years ago
That would never happen.

The problem is that Amazon has no operations in certain states to avoid charging sales tax. Buying Borders would put them in every state.

Comment · 16 years ago
Comment · 16 years ago
At least in economic theory, a company does not give out dividends if it believes that it can get a better return on its cash (in terms of profit) than the investor can in the overall market.

But, companies must eventually give out dividends. There's a certain point at which the company's cash hoard gets so large that investors become unhappy (see Microsoft).

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton