Tag: programming

Competitive AI

OpenAI:

We built a neural theorem prover for Lean that learned to solve a variety of challenging high-school olympiad problems. These problems are not standard math exercises, they are used to let the best high-school students compete against each other. The prover uses a language model to find proofs of formal statements. Each time we find a new proof, we use it as new training data, which improves the neural network and enables it to iteratively find solutions to harder and harder statements. We achieved a new state-of-the-art (41.2%) on the miniF2F benchmark, a challenging collection of high-school olympiad problems.

DeepMind:

we created a system called AlphaCode that writes computer programs at a competitive level. AlphaCode achieved an estimated rank within the top 54% of participants in programming competitions by solving new problems that require a combination of critical thinking, logic, algorithms, coding, and natural language understanding.

nft_ptr

C++ std::unique_ptr that represents each object as an NFT on the Ethereum blockchain.

Why?

Biggest issue facing $125 billion security industry: Memory safety.
“~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues.” – Microsoft Security Response Center

The world’s largest codebases are written in C++
Browsers, operating systems, databases, financial systems

C++ memory management is hard to understand, opaque, and not secure

As we all know, adding blockchain to a problem automatically makes it simple, transparent, and cryptographically secure.

Thus, we extend std::unique_ptr, the most popular C++ smart pointer used for memory management, with blockchain support

Non-Fungible Tokens and std::unique_ptr have the exact same semantics:
each token/object is unique, not fungible with other tokens/objects
each token/object is owned by 1 owner/unique_ptr
others may view the NFT/use the object, but only the owner can transfer/destroy the NFT/object.
absolutely no protection against just pirating the image represented by the NFT/copying the pointer out of the unique_ptr

Written in Rust for the hipster cred.

2021-11-11: Funny and poignant web3 critique here:

Even at comparable stages in their development, the World Wide Web and Web 2.0 were not quite so … self-referential? They were about other things — science and coffee pots and links and camera lenses — while Web3 is, to a first approximation, about Web3. For all the Web3 rhetoric around the potential rewards for “users”, Ethereum only recognizes “wallets”. One user can control many wallets; one BOT can control many wallets; Ethereum doesn’t know the difference, doesn’t care. Therefore, Web3’s governance tools are appropriate for decision-making processes that approximate those of an LLC, but not for anything truly democratic, which is to say, anything that respects the uniform, unearned — unearned!—value of personhood.

C Is Not Low-level

For a language to be “close to the metal,” it must provide an abstract machine that maps easily to the abstractions exposed by the target platform. It’s easy to argue that C was a low-level language for the PDP-11. it is possible to make C code run quickly but only by spending 1000s of person-years building a sufficiently smart compiler—and even then, only if you violate some of the language rules. Compiler writers let C programmers pretend that they are writing code that is “close to the metal” but must then generate machine code that has very different behavior if they want C programmers to keep believing that they are using a fast language.”

Undefined Behavior

Recently we’ve heard a few people imply that problems stemming from undefined behaviors (UB) in C and C++ are largely solved due to ubiquitous availability of dynamic checking tools such as ASan, UBSan, MSan, and TSan. We are here to state the obvious — that, despite the many excellent advances in tooling over the last few years, UB-related problems are far from solved — and to look at the current situation in detail.

The Monkey and the Apple

It has been waaaay more work than I expected. Starting with a more-or-less working game, and tweaking it to work on Cloud and mobile — I mean, come on, how hard can it be, really? Turns out, yeah, yep, very hard. Stupidly hard. Especially since out of brand loyalty I chose Google’s cloud platform, which 3 or 4 years ago was pretty raw. And let’s face it, iOS APIs have evolved a ton in that timeframe as well. So even as “recently” as 2013 I was working with some pretty immature technology stacks, all of which have come leaps and bounds since then.

WebAssembly

Today we’re happy to announce, in tandem with Firefox and Edge, a WebAssembly Browser Preview. WebAssembly or wasm is a new runtime and compilation target for the web, designed by collaborators from Google, Mozilla, Microsoft, Apple, and the W3C WebAssembly Community Group.

2018-08-16: WebAssembly Attacks

WebAssembly is a format that allows code written in assembly-like instructions to be run from JavaScript. It has recently been implemented in all 4 major browsers. We reviewed each browser’s WebAssembly implementation and found 3 vulnerabilities. This blog post gives an overview of the features and attack surface of WebAssembly, as well as the vulnerabilities we found.

2023-01-19: While I still think node.js is a dumb joke, this makes a good point for using wasm instead of containers

The following are a few of the reasons WASM is worth keeping an eye on.

  1. It’s Getting Faster
    Speed is a feature, and those behind the WASM specification have been hard at work. A little over 3 years ago we spoke to some of the core dev team, and their estimation was that WASM came with approximately a 20% performance hit versus native code. They speculated that within 2 years that difference could be erased, or at least made negligible enough to not matter. Today, depending on platform and workload, that has proven to be the case; one provider even claimed recently to run faster within WASM than natively. The performance limitations, therefore, that have held WASM back in the past are largely subsiding, making it viable for more and more workloads.
  2. It’s Quick
    If WASM has been compelled to work on its overall performance, there’s no such need with respect to its latency. Even from cold start situations, WASM’s latency is measured in milliseconds, not actual seconds as is typical with other application platforms from containers to function-as-a-service providers. This makes it highly suitable for workloads that are latency-sensitive, which is more and more workloads – and certainly the event-based workloads that are becoming more common within the enterprise.
  3. It’s (Relatively) Secure
    Granting that no software is immune to vulnerabilities, WASM is nevertheless distinguished in this area. Designed from day one to be secure enough to run executables within the context of an individual’s browser, it is based on sandbox principles, with no access to or from the outside by definition. At a minimum, the historical priority placed on security has been higher than other platforms, a fact likely to be appreciated by security-sensitive enterprise buyers.
  4. It’s Lightweight
    Relative to something like V8 isolates, WASM executables are sizable. But just as containers were much lighter weight than the virtual machines they supplanted, so too is WASM dramatically lighter weight than containers. This means that, properly orchestrated (a subject we’ll come back to), WASM deployments can be fantastically dense relative to their container based peers; one provider reports 20X-30X more WASM sandboxes than Kubernetes containers, for example, on a given piece of hardware. Similarly, Cloudflare has talked about their usage of Isolates to achieve the same goal.

    This density is, in part, why the popular assertion that a growth in WASM deployments will enable something of a renaissance of PaaS platforms seems correct. The unit economics of running platforms – potentially more safely – at dramatically higher densities than container-based alternatives make WASM-based PaaS platforms more viable not only technically but economically as well. Both in terms of their overall end user pricing, but also potentially making free or lower cost tiers possible that have previously been deemed cost prohibitive by vendors such as Heroku.

  5. The Language Support is Improving
    For enterprises used to working with container-based platforms, or virtual machines before that, language limitations are non-existent. Whatever the language and runtime, a given application is wrapped in a container and then run on platforms like Kubernetes alongside hundreds or thousands of other workloads, covering a multitude of languages. But as Fermyon’s language support page indicates, WASM’s support for various programming languages varies, and widely. But this is unlikely to be a fatal flaw for WASM-based providers. First, because the support for new languages is improving, and at an accelerating pace as more attention is focused on the technology. Second, because the set of core languages supported already (C/C++. C#, Go, Kotlin, Rust, Swift etc) cover a large number of potential workloads. And lastly because abstract models like PaaS have always imposed such constraints, and if anything that’s likely to become more common rather than less as more and more abstract models emerge.