Could you provide some source about Google selling your data to ad networks? Because Google explicitly says that they don’t do that and none of the fines received by Google is for selling your data. I’m curious to read about this.
Personally, whether or not Google actually sells raw data isn't that important to me. My objection is that they (and all other companies that do this) collect the data in the first place.
It’s indeed a lot more likely that LyricFind, from whom Google buys the content, scrapes the lyrics.
Why risk showing stolen content when you are already paying for them?
I understand that Genius focuses on Google though. That makes the story a lot more interesting for publications like WSJ that have a bit of a anti-Google campaign going on.
It's in Google best interest to not give others the data it collects as it can rent out the results multiple times to multiple customers. Where as giving data means they earn money of it one time.
If you like burnt and bitter coffee. The Moka pot company, Bialetti, is in fact struggling, partly because there are just so many better ways of producing coffee. The Moka pot had its time, but nowadays people know that pushing (> 100 degree) boiling water through coffee grounds just doesn’t produce a great cup of coffee. It’s a pretty device though.
The low-level nature of C++ (and also C) makes data races unavoidably undefined behavior. Imagine a data race that causes a torn write on a pointer. This pointer could now point pretty much anywhere. The function stack, some vtable, program data, etc. Any write to that dereferenced pointer will alter the state of your program in such a way that the behavior of your program will become undefined. There would be no way for C++ to guarantee any kind of defined behavior when you can write to arbitrary locations in memory.
There are two different things that people can mean when they say "undefined behaviour" in regards to C/C++. One is what you're talking about, with "undefined behaviour" meaning "one of several things could happen, you don't know which, and some of them may be bad."
The other is more specifically talking about code that is deemed "undefined behaviour" by the spec. There's a surprising amount of this, and the compiler is explicitly allowed to do anything it wants when encountered, from emitting 'close enough' code to emitting no code at all, to emitting code to order a pizza to your current location.
If this is the latter case then it could result in random bits of code mysteriously doing completely unexpected things if the compiler thinks a data race there is possible. This would make it far harder to track down bugs and reason about what code might cause such.
Yes, if your data races can pollute pointers, that makes subsequent access of those pointers undefined behavior.
But is the actual data race undefined behavior?
Take the following example from the article:
Thread A loads the value 0
Thread B loads the value 0
Thread A increments the value, calculating a result of 1
Thread B also calculates a result of 1
Thread A stores the value 1
Thread B stores the value 1
This is definitely indeterminate behavior, for the final value could also be 2. But if it is undefined behavior, the standard would also allow that final value to be 3 or 999 or -1 or INTMAX, it would allow anything.
To see a case where this matters, suppose you want an approximate total and you do this by concurrent addition to some shared variable. You expect overlapping additions to be so infrequent as to not have a large effect on the final value.
Thus, you decide to not make that value atomic and accept the inaccuracy since it is an approximation anyway.
Maybe you do this because atomic locks an entire cache-line, and something else in the cache-line is frequently accessed due to struct outline.
If the above scenario is actually 'undefined behavior' then this would be a really bad idea. You'd be at the mercy of the compiler not wanting to use this for any optimization.
It's only undefined behavior if you use regular variables and regular increments. If you use the standard atomic functions/classes with std::memory_order:relaxed, it's legal, and provides what you want.
std::memory_order:relaxed would not cover my use case.
This still requires locking, if we are using atomic<int> on x86 the locking is probably done at an assembly level which is much faster, but it remains locking.
Specifically, that form of locking marks a specific cache line 'locked' and blocks all processors from modifying that cache line.
When you're variable happens to share that cache line with something you want quick access to, this stuf matters.
(there is an exception using 'compare and swap' instructions, but I've only seen ICC emit those, not GCC.)
In general, I would expect data races to only create UB when the behavior they result in happens to be UB.
In my specific example, there is no source of UB except for apparently the data race.
If you really want that, just do a relaxed read into a local variable, increment there and relaxed store afterwards. At least clang will give you exactly the assembly you want, minus the technically undefined behavior:
https://godbolt.org/g/9ikt1m
memory_order::relaxed doesn't imply locking. Compilers on platforms where aligned access is atomic will generally implement relaxed reads and writes without locking, barriers or other expensive operations. So x = x + 1 with relaxed semantics should be cheap and best effort, like you want.
> You could give millions or billions to TomTom, which is what Apple has been doing, or you could pour the same amounts into creating your own datasets, allowing you to do a lot more than navigation, i.e. anything.
It is rumored that TomTom and Apple have a data deal. Apple gets maps from TomTom (for free, or a strongly reduced price), TomTom gets Apple maps user location data which they use for their traffic service.
How the deal works exactly isn't known (financial details are not public). But it's quite clear Apple doesn't pay a lot to make use of or improve TomTom maps.
Question, asked on HN because others might be interested in the answer as well. Since you did not explicitly mention it in your post and I could not find this on your website either, I was wondering if you only hire locally (i.e. US) or are H1Bs welcome too?
