No. String.hashCode() was already memoized. So after the first call to hashCode(), future calls just retrieved the data from the hash field of the string object.
This optimization is about avoiding even calling the method because the jvm knows that the value returned will be the same.
No. The string hash is stored as part of the String object. It is initialized to 0 but gets set to the real hash of the string on first call to hashCode()
(which is why it will be computed over and over again if your special string happens to hash to 0)
The biggest problem Intel had was that their process was optimized for their high end processors. Everything else (within the company) suffered.
For Intel to succeed as a foundry it needs customers that target the same "high end, power hungry" market segment. I don't see how Qualcomm (low power) fits that niche. More likely big AI accelerators (like, perhaps, Microsoft is planning).
As long as Intel depends on its high end processors for most of its profits, it will be difficult to develop a low power process for other, less profitable, customers.
Unrelated: anything similar for increasing photo resolution? I frequently encounter cases where users upload low resolution images (transferred using Whatsapp or similar) and need to increase the resolution to get something suitable for printing.
My take: have a few database instances (machines) each holding the data for a group of customers. With postgres you can even put different customers on the same database instances but in different schemas.
This way you get all the benefits of the relational model (you can use foreign keys, transactions consisting of multiple tables, etc.) and the performance benefits of additional machines that are not just read-replicas.
Centralized shared tables can be in a separate database which can also hold the mapping between customer-ids and database instances.
Only drawback is that management is more difficult -- backup, migrations, etc. Specifically, you need to handle the case where some customers have migrated their database and others had not yet.
This one is about compression, reliable communication. While interesting and well-written, I don't think it matches the original request for "papers on AI, ML, ...".
May I suggest joining some sort of sports activity where you can meet and train with others? For example, an amateur running team or cycling. Search for a mixed group - not an elite team full of testosterone loaded men.
That had helped me improve self confidence (and I'm _terrible_ at sports), find friends and ultimately find my wife.
People doing sports are typically in good mood and the activity naturally gives one something to talk about.
Some of their stuff for handling data and versioned pipelines seem very well done.