I'm curious about the 10x via implementation in Go - couldn't it have been realized otherwise? Finding the hotspots, reimplementing them using better algorithms, if necessary move a few critical paths to native etc. Or even improving the JIT itself which might benefit all programs. Just wondering because I wouldn't think that the JIT-overhead was that much that you could gain 10x just reimplementing in Go (or C, assembly etc)... that is something I would only have expected if going from an interpreted context.
Readit Newsmaginx commented on A 10x Faster TypeScript devblogs.microsoft.com/ty... · Posted by u/DanRosenwasser
maginx commented on It is not a compiler error (2017) blog.plover.com/2017/11/1... · Posted by u/misonic
Note... it's not really that "it's never a compiler bug," but more like "it's never a backend/codegen bug."
It's not particularly hard (for someone who knows the language rules, which are difficult for a language like C++) to make a widely-used compiler be erroneous in its acceptance or rejection of code.
What's much more difficult ("never" happens) is to make the compiler accept valid code and then generate an incorrect executable. It's possible (and I run into this maybe once a year doing unusual things) but it's really rare. If you think that's what's going on, it's very unlikely to be the case.
That's not my experience - I've found a handful of accepted and verified bugs in major commercial compilers and all were in the codegen/backend, and the code to be generated was quite simple. In one case it was basically an array copy in Java byte code that got erroneously translated into what was effectively a "copy until zero termination" error.
maginx commented on It is not a compiler error (2017) blog.plover.com/2017/11/1... · Posted by u/misonic
Around 10 years ago I found a JIT bug in a JDK from a big Java vendor. A new version of a web application server had been applied. The production application crashed after around 30 minutes of running, almost simultaneously on both production sites. It was an internal checksum calculation in the application that failed - an obscure error never seen before. The upgrade was rolled back immediately. I was assigned to the case and of course didn't suspect a JIT error. But within a week of investigation I started suspecting it must be (but I didn't dare tell anyone!) and I eventually managed to show this and reproduce it consistently. The vendor confirmed and made a temporary workaround via switches that disabled some new optimizations. Later a real fix was shipped.
I've also found 3-4 JavaScript JIT compiler errors in major browsers, all confirmed. I was a developer on what was for its time a quite complicated JavaScript solution, so we tended to encounter obscure JavaScript errors before others.
> a branch of computer science
It should be considered a distinct field. At some level there is overlap (information theory, Kolmogorov complexity, etc.), but prompt optimization and model distillation is far removed from computability, formal language theory, etc. The analytical methods, the techniques to create new architectures, etc. are very different beasts.
I agree - I don't know what field it formally is, but computer science it is not. It is also related to information retrieval aka "Google skills", problem presentation, 'theory of mind', even management and psychology. I'm saying the latter because people often ridicule AI responses for giving bad answers that are 'too AI'. But often it is simply because not enough context-specific information was given to allow the AI to giving a more personalized response. One should compare the response to "If I had asked a random person on the internet this query, what might I have gotten". If you write "The response should be written as a <insert characteristics, context, whatever you feel is relevant>" it will deliver a much less AI. This is just as much about how you pose a problem in general, as it is about computer science.
maginx commented on Bzip3: A spiritual successor to BZip2 github.com/kspalaiologos/... · Posted by u/tosh
Things that look magical often stop being magical when you have the right perspective and the right abstractions. The step from a toy example to proving any verifiable statement is just NP-completeness. Which is simple enough that undergraduates are often expected to understand it.
Interactive zero-knowledge proofs are also technically non-interactive. They are defined in terms of the verifier evaluating a transcript of the protocol. If the verifier accepts some causal assumptions about the provenance of the transcript, they will accept the proof. If they disagree with the assumptions, the proof is indistinguishable from random noise they could generate themself. An interactive commitment – challenge – response protocol is one possible causal assumption. A source of randomness could replace the challenges, making the protocol non-interactive. Or there could be a pre-committed secret, making a single-round protocol effectively non-interactive.
These are things a sufficiently interested CS undergraduate can prove and understand. Public-key cryptography, on the other hand, remains magical. There are many things people assume to be true. Which need to be true for public-key cryptography to function. Empirically these things seem to be true, but nobody has been able to prove them. And I don't think anyone really understands them.
Agreed - I've worked with PKI in many years, and know why the various systems work...in terms of "why you can decrypt again", not in terms of why it is secure (no other way to decrypt) which no one really knows. But if we assume for a moment the systems are secure, it is truly fascinating when thinking about it in abstract terms: Who would have thought, it is possible to give someone an exact recipe to follow that scramble a message to be sent... we can consider e.g. an encryption routine where the public key is inline so it is really just a standalone scrambling problem. Even though it is completely public, it can only be used to scramble and not unscramble. The sender who literally went through the steps to scramble the message, cannot undo what they just did. (the sender could have saved the original before scrambling!). And it is not because data is thrown away it can't be unscrambled - all the information is there there, fully recoverable, but only by the person who made the scrambling-recipe and there's no practical way to deduce this unscrambling recipe from the scrambling recipe.
maginx commented on Bzip3: A spiritual successor to BZip2 github.com/kspalaiologos/... · Posted by u/tosh
I've studied the Burrows-Wheeler Transform, I understand the transformation, I've re-implemented it countless times for kicks, I see how it improves compressability, but for the life of me the intuition of _why_ it works has never really clicked.
It's a fantastic bit of algorithmic magic that will always impress me to see it.
I feel exactly the same, and have also implemented it backwards and forwards. I've thought about it in my sleep, trying to recall how it REALLY works. Happens every few years ;-) I always thought it was probably obvious to everyone else what the "magic" is.
maginx commented on UK's hardware talent is being wasted josef.cn/blog/uk-talent... · Posted by u/sebg
> Sarah: Built a fusion reactor at 16. Now? Debugging fintech payment systems.
It's striking to imagine a fully functional fusion reactor that could benefit humanity, yet its creator now focuses on fintech payment systems. This highlights the importance of a strong middle class, which seems to be declining globally. A thriving middle class, with disposable income and free time, creates the conditions for innovation. Without it, even brilliant minds like Einstein might spend their entire careers working on immediate economic needs rather than pursuing breakthrough discoveries.
Probably what was built was a Fusor. There's tons of instructions how to build one (https://fusor.net/board/) and seemingly there's a lot of focus on how "young" the builders of such are. Just google: fusion reactor teenager. In some of the stories it become apparent the fusor was never actually even finished but just along the way.
https://newsforkids.net/articles/2024/09/04/16-year-old-stud...https://online.kidsdiscover.com/quickread/arkansas-teen-buil...https://interestingengineering.com/energy/nuclear-fusion-rea... ...
I believe that the intention was to say "No ability to save progress _between sessions_" in the original program, whereas the C++ implementation saves to text files.
Another portion of the article says more explicitly:
Limitations:
Maximum number of nodes: 200.
The structure is stored only in memory (no disk saving).I don't think so. Consider "It didn’t just attempt to guess the chosen animal but also learned from its mistakes, adding new questions and answers to its knowledge base. What’s more, it had the ability to save progress and load it during the next run.". Data persistence across trials is already implied by the first sentence, so what would the next "What's more, ..." part refer to - it mentions "saving" and "loading"? Even if we grant "saving" to mean updating the in-memory data structure, what would "loading" refer to? Also note the later "No ability to save progress" which directly contradicts "It had the ability to save progress". These sentences, both clearly referring to the original, are in direct contraction with each other and use the exact same terms. Inspection of the code shows that it clearly only saves the memory and not to disk.
In two places the article states that the original game had the ability to save the updated tree ("it had the ability to save progress and load it during the next run" and "It is an amazing example... of how, even with such a simple language, ... and the ability to save new questions").
The later part says the opposite - that the original implementation had "No ability to save progress" and that this is new in the C++ implementation.
I can't help but wonder (also due to other language features) if the author ran the article through an AI to 'tidy up' before posting... because I've often found ChatGPT etc. to introduce changes in meaning like this, rather than just rewriting. This is not to dismiss either the article or the power of LLM's, just a curious observation :)