12.1 The following terms apply only to current and future Google Cloud Platform Machine Learning Services specifically listed in the "Google Cloud Platform Machine Learning Services Group" category on the Google Cloud Platform Services Summary page
- Cloud AutoML
- Cloud Text-to-Speech
- Dialogflow Enterprise Edition
- Google Cloud Data Labeling
- Google Cloud Natural Language
- Google Cloud Speech-to-Text
- Google Cloud Video Intelligence
- Google Cloud Vision
> The Licensee hereby agrees ... it will not: ... (j) publicly display or communicate the results of internal performance testing or other benchmarking or performance evaluation of the Software;
This kind of clause is usually known as a "DeWitt clause"[1], after a University of Wisconsin professor who benchmarked a couple databases, including Oracle (which performed poorly). Oracle/Larry Ellison didn't react well to that and decided to forbid benchmarks.
Database performance depends on so many variables - thread pools, queue sizes, RAM allocations to different purposes, disk layout - the list goes on. There are whole consulting fields that are essentially doing a random walk through database configuration files looking for better performance - ascending the performance gradient if you will.
So in this world, its sensible to say "benchmarks are uninformative and misleading - your mileage will almost certainly vary"
Benchmarks are easily abused, misused, and misinterpreted. E.g., benchmarks looking at some very specific aspect of query performance being extrapolated to more complex/real-world queries.
Also trade-offs are rarely mentioned in benchmark numbers– e.g., great write throughput, at the expense of: ?.
It's fun to be cynical about stuff like this, but it's rarely as simple as "Ellison didn't react well to that and decided to forbid benchmarks".
Anyone who has done serious performance testing on a DB knows that there's a massive gap between initial findings and a well tuned system designed with the help of the database maintainers. I've seen some nasty performance out of Riak, Cassandra, SQL, ElasticSearch etc. But with each of those, once I talked to the DB owners and fully understood the limitations of the system it was possible to make massive gains in performance.
Databases are complex programs, and if I ever wrote one, it would be infuriating for someone to pick it up, assume it was "just like MySQL" and then write a blog post crapping on it because it failed to meet their expectations.
I think you're being a little bit unfair. The same block then continues:
This is called an integer overflow. At best, we might just get an error. At worst, our computer might compute the correct answer but then just throw out the 9th bit, giving us zero (0000 0000) instead of 257 (1 0000 0000)! (Python actually notices that the result won't fit and automatically allocates more bits to store the larger number.)
The article is introducing the concept of integer overflow.
Anyone who claims to understand integer overflow from actual experience, rather than memorizing textbooks, should know that by inspection.
I'd forgive that in a CS grad (possibly) but if someone claimed to have been working in C or other unsafe languages for more than a trivial amount of time I'd be very suspicious.
I like Zoom (http://zoom.us/). I used to use Hangouts, but it consumed a lot of CPU. The free Zoom account allows you to have up to fifty people in a room for forty minutes, or an unlimited length call with just two participants.
I've used zoom.us quite a bit and was family impressed. There's also appear.in which is not as good, but doesn't have all the restrictions the free zoom.us tier has.
I just encountered Zoom this week! I had a conference with a German (I'm in Vietnam at the moment) and she sent me a link to it. I'd never heard of it and was a bit frustrated to need to install another plugin.
But it was a great experience compared to Hangouts! The connection quality was on par with Skype and it was super light-weight for something based in the browser.
https://theconversation.com/a-mysterious-interstellar-radio-...