ychen306

How do you deal with target-specific inline asm like tcgen05.mma?

This. It's for renaming.

Eventually the utility will be correctly priced. It's just a matter of time.

It's orders of magnitude cheaper to serve requests with conventional methods than directly with LLM. My back-of-envelope calculation says, optimistically, it takes more than 100 GFLOPs to generate 10 tokens using a 7 billion parameter LLM. There are better ways to use electricity.

I try to avoid this ambiguity by calling such variables "values".

It's a TSP route over the highest 48 peaks of NH.

How this works is the LLM predicts the probability of the next token and then an arithmetic coder turns that probability distribution into bits. So it will never hallucinate. In the worst case, when the LLM makes an outrageous prediction, you just use more bits, but it doesn't affect correctness.

My main point is that these jobs are fundamentally different and people spend their time differently as a consequence. At this point, I am more curious about how what I argue even comes across as me feeling superior or being disrespectful to people who aren't developers. (I am not a developer and would rather spent all my time running if I could)

Not writing code doesn't equate to not working. Thinking, documenting, designing, discussing, etc are all important parts of their job. I don't understand why you seem offended by my take on this. This line of reasoning doesn't by any means diminish athletes/musician's work.

In this instance what would qualify as “pursing fundamentals” for a producer as defined by the author?

NFL players wouldn’t have time to do drills if their games last 8 hours and they need to play everyday.

Training is work but their main “events” are just much shorter than say that of a programmers. Even the longest athletic event like TdF lasts only several weeks. A programmer or lawyer worker 9 to 5 (at a minimum) doesn’t have time after work to practice.

Athletes and musicians pursue fundamentals because they have time; their “work” occurs in intense but short bursts of performances, leaving them the rest of their days to practice. Knowledge workers don’t “practice” because their job (long-term research or whatever) demands much more time and commitment.

They are both randomized. https://en.wikipedia.org/wiki/Las_Vegas_algorithm#Relation_t...

I think he's referring to threads as a programming model, not the physical implementation.

> Sprinkling printf statements is an efficient debugging technique.

Debatable.

> Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.

This is not true.

Many algorithms are intrinsically imperative (e.g., quicksort). You can represent it using some monads in Haskell to hide this, but in the end your code is still imperative; and if you want to parallelize it, you still have to think about synchronization.

> , though he did not join until June 2016

It's related to intelligence in the sense that being able to predict well requires intelligence and helps compression. If you have an intelligent model that predicts new words with high confidence, then you can use fewer bits to encode them. If I were to be even more handwavy, I would say having the ability to summarize effectively is a sign of intelligence.

The counterpart of "Contracts" in C++ is "Traits" not "generics".

maybe use fences?

This is probably not useful for production, but volatile is a great way to see what kind of code compiler generates in a realistic setting. For example, if you want to see how compiler optimizes a code snippet and the code depends on a constant that you don't want to get constant folded away.

Program verification. E.g. when you want to prove that certain condition/path (e.g. asserts) is unreachable.

This seems odd. I've known no one who learns programming by reading books. Reading books help, but most people get proficient by working on projects.

This is unlikely to happen because of the performance penalty it would incur (e.g. defining outcome of all out-of-bound memory accesses).

These analysis need each other for precision but not soundness. For instance, building a good call graph requires decent alias analysis, but to build a poor one you can always assume everything aliases with everything. So the idea is you run these analyses multiple times (until fix point if you want "maximum" precision).

Arithmetic coding is a standard compression technique. It uses less bits for more frequent characters (think Huffman code, even though they are not the same).

This one makes arithmetic coding "adaptive". Consider this. The rough frequency of `e' in English is about 50%. But if you just seen this partial sentence "I am going to th", the probability/frequency of `e' skyrockets to, say, 98%. In standard arithmetic coding scheme, you would still parametrize you encoder with 50% to encode the next "e" despite it's very likely (~98%) that "e" is the next character (you are using more bits than you need in this case), while with the help of a neural network, the frequency becomes adaptive.

Perhaps some people are missing the point here?. The post is not about the technical challenge/novel but rather how existing ML techniques can play a part in making reusable energy more efficient.

You need O(log(n)) of bits to write down the input. So the output size is indeed exponential.

Size of input: O(log n)

Size of output: O(log(c^n)) = O(n)

> It is entirely possible to build something without understanding it. [...] Our relationship with true A.I. will always be a matter of faith, not proof

WTF. I have no problem with building something without understanding how or why it works, but I do have problem of using something without at least some sort of guarantee on its behavior.