jcdavis

Its closer than you might think - Fitbit did $1.5B in rev last year. Haven't check their filings but presumably thats almost all from their devices. Garmin did $858m in rev last year from their "fitness" segment. Plus some fraction of their $809m "outdoor" segment includes the Fenix line, which is also in the same category. So probably $1B+ total

But that IPO stock-comp expense is largely attributable to R&D, so if you want to subtract that from the losses to look at a more cash-focused analysis you have to substract that cost from the R&D side as well.

Of the $3.95B total stock expense, $2.56B was from R&D, which suggests cash cost that quarter was more like $910m (still a lot!)

You can break that question into 2 parts.

First, the 3.9B figure appears to represents all RSUs vested up to this point, aka many years worth ("(2) Q2 2019 includes $3.9 billion of stock-based compensation expenses, primarily due to RSU expense recognition in connection with our initial public offering"). That's why its slightly misleading - its many years worth of stock comp for employees which is all getting recognized this quarter (Happens in pretty much all the big tech IPOs)

In general though, its very reasonable to associate that as an expense, which is why GAAP requires it. Where that gets complicated is that its not an immediate cash expense to the company, hence some fudging around with non-GAAP accounting which is seen by some companies.

No doubt they are struggling to show a path to profitability, but $3.9B of that is a one-time recognition of all their stock comp which makes look much worse than it should (Assuming that a 1.3B loss is more "normal")

Matt Levine is a national treasure

PSA: If the new sidebar is a little too aggressively purple for you (it was for me), the "Aubergine classic" sidebar is the old style

It is in the first example (the sal instruction)

As the devils advocate: Why not? The competition for that employee is largely local offers, remote is a small part of the overall market. Plus many other companies hiring for remote do local adjustments too, they just aren't public about it.

This all sounds weird for me to say because I certainly want devs to get paid, but this is the reality of the situation

> That said, in my view as an employee, the value I create for the company isn't based on my physical location, so why should my salary be

Because your salary is much more influenced by market supply and demand than the value you create for your employer.

If you look at the llvm IR, it is using ashr (arithmetic shift), so you can probably assume this isn't targeting unsigned types

> I don't know about you, but I can't run a 2:15 marathon or a 4 minute mile, and I don't think fancy shoes would make the difference.

But for those that can, fancy shoes make a massive difference.

Not really familiar with v8 internals, aren't there ways to do deopts without relying on guards? The JVM deopts methods by hotpatching the start of them to be a jump to runtime handlers.

Because the economy has picked up and they have retention issues

That course (15-251) is somewhat controversial among CS students (at least it certainly was when I was there) in that its primary goal in the curriculum seemed to be to act as the weedout course, since as you observed it covers a ton of material in little depth. It is typically taken 2nd semester freshman year, and I know at least 3 people my year who dropped out of CS from it :(

Vanguard charges no fees for buying/selling their owns ETFs. I believe Schwab and others do as well.

That was my first thought as well. Accurate navigation from footpod data that could eliminate or at least drastically reduce gps usage would be a gamechanger for watch battery life.

So interestingly, they are storing extra metadata in the object pointers, which means no more compressed oops (ie 32 bit pointers). Curious what the effect of that on heap sizes is considering most JVMs run with <32gb heaps

I'm assuming you're looking from another browser, in which case if you are logged out you cannot. However I, a random logged in strava user, can see at least some of your activities (Last Sept 3)

That is easy to change, but again there is the opt-int vs opt-out discussion.

Not a strava employee, but under https://www.strava.com/settings/privacy There is a setting to disable your activity data from being incorporated into the heatmaps, which I would assume (hopefully) is retroactive at some point - not sure how frequently those maps are regenerated

FWIW, graal has partial escape analysis, which can avoid a lot of those pitfalls by allowing allocations to escape through just some of the branches. For instance, if you have

    X thing = new ...;
    if (slowpath) {
        unlikely_function(thing);
    }
    ...

Even if unlikely_function isn't inlined, it can still perform scalar replacement, and push the allocation site into the branch (reconstructing the state of the allocated object as it would've been at that point), which is a big improvement.

This in turn lets the inliner be smarter about what it does and doesn't inline, vs c2 which tries to greedily inline everything, partly to assist escape analysis

I assume you are referring to the java.lang.Integer box caching situation, which is indeed shitty. However as you've written it, that will always evaluate to true, as it unboxes, adds 1 to each side, and compares the int values, not the references. To get what I assume you are talking about, you need something like:

    Integer b = a+1;
    Integer c = a+1;
    b==c

Which by default returns true for a=126 but false for a=127. A bad situation for sure, but thankfully pretty much every static analysis tool will spot that.

Is worth mentioning that SubstrateVM (https://github.com/graalvm/graal/tree/master/substratevm) is now open source, which does whole-world AOT compilation to produce a single executable or shared library. It does have substantial limitations (eg no runtime class generation/loading), so it might not be suitable for every project

The example of bad allocations

  def first[A](left: A, right: A): A = left

  first(12, 42)   // => 12

actually allocates nothing, because both numbers are in the Integer box cache range (-128 to 127 inclusive by default, but configurable to be greater). The general argument is good though, so mabye first(128,129) is a better example :)

> Neither Apple nor Microsoft use Java.

From what I understand Apple uses java/scala fairly extensively for backend services.

IIRC when I took 213 (Fall '07) a some folks somehow figured out bit of what the autograder branchmark was, and so added tricks like odd if statements to allocate extra memory for very specific sizes (which therefore, when freed and coalesced, allowed enough space for some following large allocation).

Seems like their new benchmarks might limit that sort of behavior

Just a guess, but from what I understand they spend significant $$ on driver-side acquisition and retention, perhaps even moreso than customer side. In addition to the signing/referral bonuses, they have regular weekly bonuses for hitting a certain number of rides.

Scala sort of has this with the @tailrec annotation. The compiler will always attempt TCO, but the annotation makes failure to do so a compilation error. (Its not a perfect situation though, since there can still be functions assumed to be tail recursive without @tailrec, and whose behavior can change without warning)

The most widely used library for dynamic bytecode generation is asm: http://asm.ow2.org/

Its fully complete. Because it was reversed engineered function by function, it was never really not feature complete, since it would still call out to existing code in the binary (thought there were some bugs). They've since added a ton of new features not in the original game (eg multiplayer networked mode), native OS X/Linux support, etc.

I contributed a little bit back in 2014/2015 and it was a lot of fun. Because it is almost all hand-written x86 ASM (which is insane), it was actually not too hard to reason about, certainly far easier than what Clang/GCC will spit out.

As yes, the classic "I can outsmart the compiler".

I've been down the exact rabbithole, before, but with java. There are 2 different bytecodes for representing a switch statement: tableswitch, which is dense (has a case for every key from X to Y), and lookupswitch, which is sparse. Of course the dense one must be better, I thought: O(1) vs O(log n) ! Maybe if I added a few more cases manually to my switch statement to cover missing holes, my lookupswitch would become a tableswitch and my hot loop would be faster.

Turns out, of course, that not only is O(1) not necessarily any faster than O(log n) when n is small and the constant factor is large (see this article), but in fact its irrelevant since the hotspot uses the same function to generate the IR for both bytecodes (http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/b756e7a2ec... ), and thus the decision about whether to use a jumptable or binary search is entirely unreleated to the bytecode that represents the switch statement :)