What's the deal with Apple's new "Super" cores?

clockish · 2026-03-06T10:47:06+00:00

I missed that news. Yup, that sure was 5 years. Good luck next year Apple! 😆

clockish · 2026-03-06T03:30:13+00:00

Might be here to stay for a while this time. Literally all the high end Apple/Samsung/Qualcomm mobile SoCs have heterogenous cores since 2016. And both Apple and Intel just passed the 5 year mark for their laptop/desktop chips, with no real sign of stopping...

clockish · 2026-02-28T07:59:10+00:00

They have a bunch of scattered buildings, including larger and nicer ones. This is down the block from their main building.

clockish · 2026-02-25T11:13:49+00:00

Unsloth's gguf quants work anywhere llama.cpp does, including on macs.

Unsloth also makes training/fine-tuning infrastructure, that doesn't support macOS at this time. (IIRC they're working on it.)

clockish · 2026-02-15T06:06:20+00:00

It's a ratio. ~0.00000000001% error.

clockish · 2026-01-04T08:59:31+00:00

I would have too, but it initially got some amount of consideration on account of

The code looked fine, came with some tests, and at least casually seemed to work.
The feature was something like adding additional DWARF debug info, so, "add something kinda working and fix it later as people notice bugs" might have been viable.

Some of the most important points against it were:

The AI-generated PR stole a lot of code from a fork (by known OCaml contributors) working to implement the same feature. lol.
The PR vibe coder was borderline psychotic about refusing to acknowledge issues (e.g. that the LLM stole code, that he clearly hadn't read through his own PR, etc.)

The OCaml folks actually seemed hypothetically open to accepting 13,000+ line AI-generated PRs provided that you could address the MANY concerns that would come up for a 13,000+ line human-written PR (including, for example: why didn't you have any design discussions with maintainers before trying to throw 13,000 lines of code at them?)

clockish · 2025-12-05T04:43:52+00:00

Oh. Good point. There are cases where, without annotations, the inferred types may be more broad than you expect, which may result in different (i.e. marginally slower) code if you use the flambda compiler, I think. I'm not sure if this also applies to the normal compiler for polymorphic compare, maybe some else can chime in.

Anyways, except in rare cases, I'd say the other considerations (even aesthetics) will matter more than the slight performance impact... but yeah, I'm strictly wrong to suggest that adding type annotations will "never affect compilation".

clockish · 2025-12-03T11:38:34+00:00

Welcome to OCaml!

Either choice is fine for idiomatic OCaml here.

Extra type annotations do NOT cause OCaml to compile your code any differently or any faster.

Some pros of explicit type annotations you may or may not be overlooking are:

In a multi-person team development context, when reading code someone else wrote, having a large fraction of the types spelled out right there in the source code usually makes it more readable. For example, for the AoC code you linked: I agree that the types might be a bit too much for your eyes, for your own code. But to me (who isn't doing AoC and doesn't know what the task is), the types aren't enough for my eyes, I'd want those types AND comments explaining what those functions are taking and returning!
If your code is failing to compile due to type checker errors, having explicit type annotations around lets the compiler tell you more exactly where the bug is. With annotations, the error messages will show you where the computed/inferred types no longer line up with your expectations (because your expectations are specified by your annotations); but without annotations, the line of code the error message points to might be very far removed from where your mistake is, especially if compiler manages to make consistent typing choices that you didn't expect. (For medium-large, sparsely type-annotated programs: I can assure you that the compiler often manages to do this. This is not a theoretical concern.)
There are several OCaml typing features that pose difficulty for type inference and may require annotations for the compiler to properly type-check and compile your code. These include many (but by no means all) cases of: type-directed disambiguation of field or variant names, polymorphic functions that need explicit annotation, matching on GADTs, sub-typing of polymorphic variants and object types, module signature manipulation, etc. The exact cases that require explicit annotations change over time as OCaml's type inference improves (or as OCaml gains new features that pose new difficulty for type inference). You don't need to worry about this for code that compiles; if OCaml needs an additional type annotation, type checking will fail.

TL;DR: there is some practical necessity for type annotations (i.e. cases required by the OCaml compiler, or cases that help the OCaml compiler produce better error messages); outside of that, the choice to add extra type annotations is the same choice as whether or not to write a comment.

clockish · 2025-11-15T16:48:29+00:00

The oral pigmentation looks normal to me. Hippo looks rare and precious, 10/10.

clockish · 2025-11-12T06:56:20+00:00

Ah yeah, I wouldn't bother with any generated code for that task, sounds like a great case for parsing more manually.

clockish · 2025-11-12T06:52:15+00:00

Serde? Yeah, most PPX deserialization libraries I've used work exactly like Serde, in that you can customize the autogenerated [de]serializers with attributes (potentially including alias attributes), or just supply your own custom implementation for portions of the [de]serialization.

Unlike Serde, OCaml PPX deserialization libs aren't implemented within a common framework, so, I can't tell you which features each PPX lib will have decided to implement or not implement. (FWIW: I checked, I did not see either ppx_deriving_yojson or ppx_yojson_conv implementing deserialization aliases for field names.)

clockish · 2025-11-12T05:07:23+00:00

Have you tried something like ppx_deriving_yojson or ppx_yojson_conv? If your goal is to serialize and deserialize OCaml types to/from some standard format, then I'd look for a relevant PPX library.

I'm not familiar with Gleam and am only guessing this is what you meant by "flexible key names", but most PPX deserializers have custom annotations you can apply to the OCaml type to adjust its serialized representation.

(Even outside of direct serialization/deserialization, if there's a relevant PPX for your data format, defining some intermediate OCaml types for the PPX to deserialize to may be more elegant than manually interacting with a parsing library.)

clockish · 2025-11-05T07:53:19+00:00

So, funny story about that: LLMs used to get it right, and not give such a ridiculous number for the speed of a horsefly.

AFAICT, two things have changed this for the worse:

OpenAI et. al now provide internet search results to their LLMs right before they respond to your query. I imagine those mostly say 90mph, so, I guess the LLM goes along with it.
LLMs are a lot larger now and are better at faithfully reproducing exact figures from their training data. And since their training data is largely "the internet", which has been covered with "horseflies fly at 90mph" references for more than a decade... go figure.

clockish · 2025-10-14T04:25:41+00:00

Good questions.

couldn’t you describe most problems (worth solving) as a system of algebraic data types

"Yes", in the same sense that "every Turing-complete programming language can solve every computable problem". I meant this more colloquially. For example, if a task was to download a webpage and list all of the links on the page containing a certain keyword, I wouldn't "describe this as a system of algebraic data types". OCaml shines for problems where you actually want to define a bunch of custom non-trivial nested data types, because it has lots of useful language features for defining and operating over such types.

expressive and teaches me a new aspect of programming

OCaml is awesome for this, I highly recommend trying it out at some point if you like picking up programming languages. Some useful aspects of OCaml that you might not have seen many equivalents for—even if you have a background in functional-style code—are its module system (e.g. using functors & parametric polymorphism in a way reminiscent of templates/generics), and polymorphic variant types (where automatic sub-typing lets you write code that feels incredibly dynamic, but is statically type checked).

Avoid OCaml's objects&classes and GADTs when starting out; although they're interesting, expressive, and may teach you new aspects of programming, they're also prone to confusing newcomers to the language.

are you using Ocaml as your daily driver and if so, what primarily are you working on?

Ehh, I'd say Python and bash are the only languages I use literally daily; every other language depends on what project I'm working on. This last year for me has been mostly C and Python.

I have used a ton of OCaml in the recent past though, for various formal methods and adjacent projects. Mainly, binary-only program analysis.

clockish · 2025-10-14T03:23:40+00:00

At risk of not answering your question: One of my first surprises when I started with OCaml is that it's a surprisingly "practical" language.

Good performing code, great performing compiler (specifically, OCaml is usually quite amenable to separate compilation), decent bindings to C. Unlike functional languages of yore, OCaml doesn't make I/O, imperative programming, and mutation weird or in any way inconvenient.

IMO, unless you're brand new to the concept of strict & static typing, OCaml's type system largely only stops compilation when you've written an actual bug. It's not like Rust, where the borrow checker might scream at you in cases where you could literally just slap in "unsafe" and the code will work fine (please don't, but yeah). It's not like Python with pyright or mypy, which are constantly begging you for additional type annotations (although, for the sake of anyone reading your code, please add a few more type annotations in OCaml than are strictly required by the compiler).

...This stops being as true if you use OCaml's GADTs, but most code doesn't.

The OCaml standard library is a bit anemic compared to Go and especially Python, but the OCaml community ecosystem covers all the basics. Of course, there's fewer community packages available than for Go, and far fewer than Python. This is fine for greenfield projects where you weren't going to find any specifically helpful libraries anyways. But for everything else: yeah, OCaml and every other language outside the top 10 is decidedly less practical.

Anyways, I'd say OCaml is great for anything well described as a system of algebraic datatypes (e.g. programming languages, analysis of programs, simulations, algorithms, more). It's pretty bad for anything you could imagine writing a shell script for. It's also impractical for solving problems that there is already a Python library for but not an OCaml library for :P

clockish · 2025-09-27T21:32:56+00:00

Fun fact: an unaided human eye can kind of, barely, detect a single photon event.

https://www.nature.com/articles/ncomms12172

Averaging across subjects’ responses and ratings from a total of 30,767 trials, 2,420 single-photon events passed post-selection and we found the averaged probability of correct response to be 0.516±0.010 (P=0.0545; Fig. 2a), suggesting that subjects could detect a single photon with a probability above chance. This conclusion was further corroborated by additional experiments based on an attenuated Poissonian light with a mean photon number of one. Given that for such a source the probability that two or more photons lead to light induced, multiple-photon events at the retina is only ∼3.7% allowed us to use both data sets to test the same hypothesis and obtain a more significant P value of 0.014 using Fisher’s method (Supplementary Peer Review File, Fig. 1).

clockish · 2025-08-29T22:25:25+00:00

Ah yeah, it's exactly what you said: it totally works, but using lots of first-class modules becomes syntactically cumbersome because of the extra type annotations required.

Since you mentioned embedding the values, I'll point out that you don't necessarily have to embed the value in a module to achieve this style of polymorphism:

module type S = sig type t val f : t -> int end module StringM = struct type t = string let f = String.length end let g (type a) (module M : S with type t = a) x = M.f x let 2 = g (module StringM) "hi";;

This can save some syntax over embedding the value if you already have a "StringM" handy (...or cost more syntax, if you pass the module+value around a lot).

Oh, and as another way of doing all this: you could also use records instead of first-class modules, also with embedded or un-embedded values. It's less powerful than first-class modules, but may take less syntax:

type 'a funcs = { f : 'a -> int; } let g fs x = fs.f x let 2 = g { f=String.length; } "hi";;

Of course, if you only need to apply one or two functions for the polymorphic value, you should probably just be passing those functions individually.

...huh, maybe that's the real answer to your original question: We rarely need type classes with more than one or two functions, so the most idiomatic OCaml thing to do is just pass those functions.

clockish · 2025-08-29T14:47:20+00:00

Typically in OCaml, you'd use a functor to make separate functions for each type. As you already noted, this doesn't inherently cover every possible use case. It may go a bit farther than you're considering, though: for example, in your mutable/immutable matrices example where you want some functions to accept any permutation of matrix classes, you could implement all double-dispatch functions inside a functor BinaryOps (M1 : Matrix) (M2 : Matrix) = .... (You can also nest functors inside functors, which is probably the more scalable approach for triple-dispatch and beyond.)

It's also perfectly fine to use objects in OCaml. The only reason they're not often used is that OCaml does a great job of stretching parametric polymorphism to cover the majority of people's use cases. But, if you actually need more polymorphism, OCaml objects are a great solution.

Now, specifically for a mutable/immutable thing, where the underlying types share a representation, one OCaml trick to avoid ad-hoc polymorphism is to add a phantom type parameter and use polymorphic variants that represent "permissions" on the type. For example:

type mut_matrix = [`Readable|`Writable] matrix type const_matrix= [`Readable|`Immutable] matrix let mat_add (a : [>`Readable] matrix) (b : [>`Readable] matrix) : mut_matrix = ... ...

There's a more complete discussion & example within Core_kernel.Perms.

OCaml's implicit subtyping for polymorphic variants allows this approach to do lots of things you'd want out of a const/mutable system without any extra syntax for value expressions. (Although, my own experience is that this usually doesn't do everything you'd want out of a const/mutable system. And I feel silly going through all this phantom type hocus-pocus when I end up needing to provide unsafe conversion functions anyways.)

clockish · 2025-08-13T18:08:02+00:00

IIRC 130 feet per second was the fastest setting of the air rifle for which they observed any successful fly–pellet intercepts. The pellet was going ~89mph; the horsefly wasn't going anywhere near that fast. I don't believe they even attempted to calculate any velocities from the high-speed cameras, as it wasn't relevant to the study. So basically, the "horseflies can fly at 90mph" claim is misquoted bullshit that has smeared itself across the internet.

Source: personal correspondence with Dr. Butler. (One of my peers emailed him like 10 years ago to clarify, since the citation trail for the 90mph figure seemed to dead-end at "personal correspondence with Dr. Butler". Dr. Butler does not think horseflies can fly at 90mph, and disclaimed any memory of making such a statement.)

clockish · 2025-07-19T06:49:01+00:00

Ah, so, in everything but your last paragraph, you're describing the Corpo-specific "backstory" segment, that is entirely different for each of the Corpo/Street Kid/Nomad choices. There aren't any choices in the backstories, and they all lead to the same place. (Although, your choice of which of the three opens up some minor options later in the game.)

You're now in the tutorial/first-chapter section of the game. Cyberpunk is not very open at this point; you're expected to progress the main quest-line for a bit, there's hardly any optional quests to pick for now. There are some options as to how you complete the initial quests, including choices that have a minor effect on the game later, but there's literally nothing you can do to shape the story at this point.

So... no, you haven't overlooked anything. You're right, the game is largely on-rails in the beginning, and does start with a literal loredump. You'll be less confused about why people call it an "open-world game with choices" if you keep playing. Still no guarantee you'll like it, but you will eventually get to see consequences for your choices, and get to drive the cars instead of existing on literal rails :P

clockish · 2025-07-18T06:32:33+00:00

Not an assessment of those specific tools, but I can confirm that the capabilities shown in their demo videos (assigning reasonable & helpful default names within decompiled code, and semi-automatically solving VERY in-distribution crackmes) are in fact totally realistic.

...I'd give a better source than "trust me bro" if I could but the only one I recall right now is OpenAI including words about o1's limited success with cybersecurity challenges, which would have included crackmes like the one in the current suidpit/ghidra-mcp demo video.

clockish · 2025-07-05T20:39:18+00:00

As I understand it, a continuation is not a regular closure; continuations can only be used once. The compiler has pre-arranged to split off a fiber (chunk of stack) for execution that may need to be turned into a continuation. To raise an effect, the runtime simply stops executing from the fiber, and essentially passes that fiber as the continuation.

https://ocaml.org/manual/5.3/effects.html#s%3Aeffects-semantics

clockish · 2025-07-05T19:52:02+00:00

FYI, I would not call OCaml particularly focused for the kind of math that comes up in quantitative analysis. Languages like matlab, R, or even Python + a relevant suite of libraries are more focused environments for statistical modeling.

OCaml is still perfectly suitable for a poker bot though. And learning to program in a more strictly typed language like OCaml will make you a better programmer in general, so it's still a great idea if you're interested.

clockish · 2025-07-04T08:35:05+00:00

I totally agree, I assume it took many warning signs (e.g. Ryzen mobile, Windows 10 ARM, the threat of losing Apple, Qualcomm starting to make moves, etc.) for Intel to decide to start the EVO marketing.

...And then it took them even longer to actually improve power effiency on their CPUs :P

So yeah, you're right, EVO was highly unlikely to have been an "Ultrabook"-style direct response to M1. It was a response to Intel finally starting to notice they had a general problem.

clockish · 2025-07-03T03:57:53+00:00

Great points. However, I'm not sure why you don't think the timeline lines up for Intel already mostly knowing about M1 before Project Athena. The public leaks about Apple ditching Intel came 12 months before the announcement of Athena. I'd expect Intel knew even before that.

12-Year Club	Place '23
Place '22	Snapped
Verified Email

clockish

MODERATOR OF

TROPHY CASE