1,379 karma · joined April 8, 2014
Put simply, if Musk only made one controversial call, this comment thread wouldn't exist. The many controversial calls cannot be easily disentangled.
Spark will re-run the query planner after doing the map stage of a map-reduce operation so as to leverage the information collected: https://databricks.com/blog/2020/05/29/adaptive-query-execut...
Both examples represent changing parameters about a lower level plan than simply join operators, but the industry is certainly moving in this direction.
New cars are primarily bought by comparatively wealthier people or fleet sales. Less well off people might occasionally buy newer cars, but it’s more common to buy them second hand after 5-10 years of careful ownership. The $40k truck has historically depreciated by around 40% during that 5 year period, by which point it’s worth about $24k. Better examples may be worth more, worse examples less (although perhaps a poorer buy). Large examples of this come through age - in the US, the median new car buyer is in their 50s, whereas the median American is in their 30s.
Put simply, yes, the average new car is unaffordable for the average American, but how much of a problem is that?
Out of buyers in the market for a new car, this is clearly close to the affordable side of the range, no matter how ridiculous that might sound.
- Garbage collectors have required far less tuning; with G1, Shenandoah, ZGC it's likely that your application will need little tuning on normal sized heaps.
- modules, jlink etc allow one to build a much smaller Java application by including only those parts of the JVM that one needs.
- Graal native images are real. These boast a far lower startup overhead and much lower steady state memory usage for simpler applications.
Probably my counterexample of choice is this: https://github.com/dainiusjocas/lucene-grep - it uses Lucene, one of the best search libraries (core of Elasticsearch, Solr, most websites), which is notoriously not simple code, to implement grep-like functionality. In simple cases, they demonstrate a 30ms whole process runtime with no more than 32MB of RAM used (which looks suspiciously like a default).
The JVM is fast becoming a bit like Postgres... one of those 'second best at everything' pieces of tech.
Have you found that the approach has made it easier for you to ship improvements to Cassandra?
1. Benefactors who give money to the orchestra, rent boxes, etc. 2. Popular (non classical) concerts which have a possibly larger crowd and varied material. Harry Potter with orchestral accompaniment? Tenacious D with orchestral accompaniment? The musicians hate it, it pays the bills. 3. A mostly part time staff. Most orchestral musicians will play in many orchestras, teach, etc.
They made a loss on your concert. But they knew they would.
In one case, the developer writes `System.out.println`. In the other, the developer must individually get the static field System.err and push it to the stack, reference PrintStream's method println, including the arguments (Ljava.lang.String;)V. That means it takes an array of strings and returns void.
So the idea with SMT is that most of the time, lots of the execution units are unused because the thread a) isn't using them at all (e.g. a process to do encryption won't use the floating point units) and/or b) can't use them all because of how the program's written (for example, if I say 'load a random memory address, then add it to a register, then load another random memory address, then add it, etc' I'm going to be spending most of my time waiting for memory to be loaded.
SMT basically means that you run another program at the same time, so even if the encryption process can't use the floating point units, maybe there's another process that we can schedule that will.
However, imagine my encryption process can use 6 of the 8 arithmetic units. If I have 2 encryption processes scheduled on the same core, I have demand for 12 when there are only 8. So now I have contention for resources, and I won't see a speedup from using SMT.
Other comments mention registers and not execution units: I'm suspicious of this, since modern processors have many registers (for Skylake, 250+) which they remap between aggressively as part of pipelining. Maybe this is different for the SIMD units.
That said, I haven't looked at this stuff since university so could well be wrong on the execution unit vs register comparison.
This was because that package depends on a different version of jersey-jackson or whatever, which was discovered by classpath scanning, and so because Eclipse doesn't keep a separate test classpath, we'd be discovering a new MessageBodyWriter which Jersey would be using to override the Dropwizard supplied MessageBodyWriter, which would not have the appropriate Jackson modules.
It was a mess.
I think that Spark comes at the cost of customisability - 2-way SSL is a chore, you have to parse your own message bodies, you don't get straightforward logging out of the box - there's a base set of features and functionality that I couldn't find in Spark.
The thing that impressed me about Dropwizard is that you can get in perhaps 50 lines of boilerplate a really solid core behind an application - with Spark you can do that in perhaps 20, but you are somewhat limited beyond that.
logger.debug("My logger message has placeholders {}, {}, {}", some, objects, toLog);
logger.debug("...");
1. Can't sort using a GIN index.
2. Stats are shit with GIN indices - Postgres assumes that every filter has 100 matches, every array has 99 elements or something. Usually this works well, sometimes (specifically in my case) it's terrible. Specifically, it means that if you combine an aggregation over a GIN filter with an inner join, the performance will be awful because postgres picked a nested loop join for expected 100 results instead of a hash join for the actual 50,000.
3. This also means that additional expression indices you add basically aren't getting used, because it'll always appear better to the query planner to use the GIN index first. This includes things like sorting.
4. Because of how jsonb is implemented (basically arrays containing fields ordered by key alphabetical), we discovered that we were taking out more and more fields out of our jsonb field and placing them in other columns, which kinda missed the point of it (but was very good that we could do so, yay relational data model).
5. Sorting can become an epic chore if you don't have stuff like enum types etc, especially when you try to combine it with tsvectors.
So, very happy with Postgres, but don't slam people who don't use Postgres because of insufficient json support - because Postgres' json support although excellent has quirks that will bite you with certain use cases. Very good, but not a panacea.
For example, a normal disc encryption system with the caveat that the password is XORed with a secret before the key derivation algorithm is used (where the secret is unique to the exact laptop model) would effectively stop all decryption in its tracks until you knew the exact laptop model, but would not compromise security at all.
This is something that has been thought about in detail - see https://vtllf.org/blog/ssh-web-sign-in/quest-to-replace-pass... for Stajano's analysis.