Forem: TinyAlg

2.78 TFLOPS on a Fanless MacBook Air? Benchmarking Apple's M4 with MLX

lwgena — Thu, 19 Mar 2026 05:58:37 +0000

(This article is an English translation of a post originally published in Japanese on my blog. You can read the original Japanese version here).

My fanless M4 MacBook Air hit 2.78 TFLOPS in a matrix multiplication benchmark using Apple's MLX framework.

Matrix multiplication (GEMM) isn't just a basic math problem; it's the beating heart of modern Machine Learning and Large Language Models (LLMs). By measuring how fast a machine can multiply huge matrices, we are essentially measuring its raw capability to run AI locally. Let's see what the M4 chip can do.

< Test Environment >

Machine: M4 Macbook Air
Memory: 16GB
Python: 3.10.11
Framework: MLX v0.28.0

1. Measuring Execution Time

To measure the execution time, I used a simple matrix multiplication operation.

1.1 The Benchmark Script

I've published the measurement script on GitHub Gist. Feel free to download it and test it on your own Apple Silicon Mac.

Note: I ran the benchmark last summer. I have recently verified that the script still runs on Python 3.12.12 and MLX v0.31.1 without any modifications.

Save the script as matmul_benchmark.py and run the following commands in your terminal:

% python3 -m venv venv
% . venv/bin/activate
% pip install mlx
% caffeinate python matmul_benchmark.py

1.2 Results

I measured the execution time for various matrix sizes. The average time below is based on 5 consecutive runs for each size. All computations were done using the bfloat16 data type.

Matrix Size	Avg Time (s)	Total Ops	Real TFLOPS	Run 1 (s)	Run 2 (s)	Run 3 (s)	Run 4 (s)	Run 5 (s)
`10000x10000`	0.740	2 Trillion	2.70	0.738	0.738	0.742	0.740	0.743
`20000x20000`	5.754	16 Trillion	2.78	5.667	5.698	5.750	5.810	5.847
`30000x30000`	21.624	54 Trillion	2.50	20.341	21.076	22.252	21.897	22.555
`40000x40000`	75.872	128 Trillion	1.69	62.925	77.502	72.921	85.509	80.505

1.3 Observations

Peak Performance: The highest performance recorded was 2.78 TFLOPS at a matrix size of 20000x20000.
Thermal Behavior: For the 20000x20000 and 30000x30000 sizes, execution times creep up slightly with each run. This hints that the fanless chassis might be starting to manage heat.
The Impact of Swap Memory: At 40000x40000, the execution time spiked, and the variance between runs became larger. This is because the 16GB of unified memory ran out, forcing the system to frequently swap to the slower SSD. I confirmed this by watching the swap space usage shoot up in Activity Monitor during the run.

2. Calculating Total Operations and TFLOPS

TFLOPS (Tera Floating-point Operations Per Second) is a performance metric indicating how many trillions of floating-point calculations a processor can execute in one second.

We can calculate this using the total number of operations and the execution time.

2.1 Total Operations

First, let's calculate the total operations. A matrix multiplication $\cdot B$ for matrices $A$ and $B$ of size $\times N$ can be expressed as:

\left( \begin{array}{rrr} c_{11} & \dots & c_{1N} \\ \vdots & \ddots & \vdots \\ c_{N1} & \dots & c_{NN} \end{array} \right)= \left( \begin{array}{rrr} a_{11} & \dots & a_{1N} \\ \vdots & \ddots & \vdots \\ a_{N1} & \dots & a_{NN} \end{array} \right)\cdot \left( \begin{array}{rrr} b_{11} & \dots & b_{1N} \\ \vdots & \ddots & \vdots \\ b_{N1} & \dots & b_{NN} \end{array} \right)

A single element $c_{ij}$ in matrix $C$ is calculated as:

c_{ij} = \sum_{k=1}^{N} a_{ik}b_{kj} = a_{i1}b_{1j} + a_{i2}b_{2j} + \cdots + a_{iN}b_{Nj}

This requires $N$ multiplications and $N - 1$ additions, totaling $2 N - 1$ operations. In our experiment, since $N$ is large, we can approximate this to $2 N$ operations per element.

Since the matrix $C$ has $N^2$ elements, the total number of operations is:

\text{Total Operations} \approx (2N) \times N^2 = 2N^3

For example, when $N = 20000$ :

\text{Total Operations} \approx 2 \times 20000^3 = 16 \times 10^{12} \text{ (16 Trillion Operations)}

2.2 Calculating the TFLOPS Performance

Finally, we use the total operations and the execution time to calculate the TFLOPS using this formula:

\text{TFLOPS} = \frac{\text{Total Operations}}{\text{Execution Time [s]} \times 10^{12}}

For $N = 20000$ :

\text{TFLOPS} = \frac{16 \times 10^{12}}{5.754 \times 10^{12}} \approx 2.78

**

Did you feel the sheer scale of TFLOPS calculations? It's pretty mind-blowing what a fanless laptop can achieve locally these days.

I Fed My Tech Book into NotebookLM, and It Generated Spot-On Infographics

lwgena — Sat, 07 Mar 2026 07:48:07 +0000

Recently, I published a technical book (in Japanese) titled "The YouTube Timer Quest: Mastering the Engineer's Mindset via Chrome Extensions."

Out of curiosity, I decided to feed my entire Japanese book into Google's NotebookLM to see how it would summarize the content. The result? It generated surprisingly accurate, professional-grade infographics—in natural English!

Even if you haven't read my book, I want to share two of these diagrams and explain why this blew my mind as a developer and author.

How AI Visualized the Author's Intent

First, take a look at the initial infographic it generated.

As the author, I was astonished by how well it captured both the core philosophy and the specific technical challenges discussed in the book.

My book uses the development of a real-world Chrome extension (Watchtime Badge) to teach readers how to move beyond simple "copy-paste" coding and adopt an actual "Engineer's Mindset." It focuses heavily on solving real-world browser constraints.

Here is why this diagram is so impressive:

Extracting the Core Philosophy: The diagram clearly illustrates the "Define, Decompose, Build" pillars. This isn't just a specific chapter; it's the foundational theme of the entire book. The AI understood the underlying message remarkably well.
Pinpointing Technical Solutions: In the middle right, you'll see "Delta Time for Precision". This directly corresponds to my chapter explaining why JavaScript's setInterval drifts over time and how to fix it using timestamp differences.
Understanding API Context: It highlighted the use of the chrome.alarms API as "The Heartbeat for Survival". This reflects my chapter on how to revive Chrome Service Workers that are automatically terminated by the browser's energy-saving features.

The Secret: NotebookLM Prompt Settings

To generate these high-quality diagrams, I used the following settings in NotebookLM:

Choose Language: English
Choose Orientation: Landscape
Level of Detail: Standard

💡 Author's Tip: Even though my source material was completely in Japanese, I intentionally set the output language to English. Why? Because for technical diagrams, English text tends to fit the layout much better visually, resulting in a cleaner, more standard, and stylish look. NotebookLM handled the cross-lingual summarization seamlessly.

Here is the second infographic it generated:

While the first infographic visualizes the development process as a dynamic journey (a "quest"), this second one organizes the same knowledge into a structured, static overview.

It clearly categorizes the abstract "Engineer Thinking" on the left and concrete "System Constraints" on the right. It is fascinating to see how the exact same prompt generated two completely different visual approaches—process versus structure.

Conclusion: What Engineers Should Focus On

Seeing these images made me realize something profound: We no longer need to spend hours manually formatting our ideas into visual diagrams.

AI can now effectively grasp technical context, understand system constraints, and translate complex concepts into beautiful visuals. This frees us engineers to let go of tedious layout adjustments and focus on what truly matters: defining the right problems and designing the core system.

Have you tried generating diagrams with NotebookLM for your projects? Let me know your thoughts in the comments!

Introducing 'Publish to Dev.to Organization' Action: How to Safely Test Your Workflow

lwgena — Fri, 06 Mar 2026 01:38:29 +0000

I recently joined Dev.to and wanted to automate my article publishing directly from GitHub. However, I quickly hit a roadblock: I wanted to publish posts under an Organization, but I realized I had to write a custom script using the Forem API to make that happen, as existing tools didn't fully support it.

I started writing a custom GitHub Action just for my own workflow. But halfway through, I thought, "Why not just make this available for everyone on the GitHub Marketplace?" And so, Publish to Dev.to Organization Action was born!

But of course, before publishing a tool that interacts with a live API, I needed a way to test it thoroughly. If you test a publishing workflow live, you risk spamming your followers or hitting rate limits.

To solve this, I implemented a dry_run feature in this action. In this post, I'll show you how to use this feature to test all 8 possible publishing patterns without making any actual publishing API calls (POST or PUT) to Dev.to. (Note: The action only makes safe GET requests to resolve Organization IDs when necessary.)

The 8-Pattern Matrix

When managing Dev.to articles via front matter, there are 3 variables that create 8 unique scenarios:

Target: Personal Account vs. Organization
State: Draft (published: false) vs. Public (published: true)
Action: Create (POST) vs. Update (PUT)

You can test all of these in two simple rounds using GitHub Actions.

Prerequisites: The Workflow Setup

First, set up your workflow using tj-actions/changed-files to only process modified files, and enable dry_run: 'true' in this custom action.

# .github/workflows/publish.yml
name: Publish to Dev.to

on:
  push:
    branches:
      - main
    paths:
      - 'posts/**.md'

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get changed files
        id: changed-files
        uses: tj-actions/changed-files@v47
        with:
          files: posts/*.md

      - name: Publish Articles
        if: steps.changed-files.outputs.any_changed == 'true'
        uses: tinyalg/publish-devto-org-action@v1
        with:
          devto_api_key: ${{ secrets.DEVTO_API_KEY }}
          file_path: ${{ steps.changed-files.outputs.all_changed_files }}
          dry_run: 'true' # This prevents actual POST/PUT API calls!

      - name: Commit Article IDs
        if: steps.changed-files.outputs.any_changed == 'true'
        uses: stefanzweifel/git-auto-commit-action@v7
        with:
          commit_message: "chore: update Dev.to article IDs [skip ci]"
          file_pattern: 'posts/*.md'

Round 1: Testing "Create" (POST)

To test the 4 creation patterns, create the following four markdown files in your posts/ directory.

1. Personal & Draft (pattern1.md)

---
title: Pattern 1 Personal Draft
published: false
---
Test content here.

2. Personal & Published (pattern2.md)

---
title: Pattern 2 Personal Published
published: true
---
Test content here.

3. Organization & Draft (pattern3.md)

---
title: Pattern 3 Org Draft
published: false
organization_username: tinyalg
---
Test content here.

4. Organization & Published (pattern4.md)

---
title: Pattern 4 Org Published
published: true
organization_username: tinyalg
---
Test content here.

After committing and pushing these files, check your GitHub Actions logs. You will see the dry_run output. The action simulates the API, confirms it would have sent a POST request, and injects a mock id (e.g., id: 9123456) into each file. The git-auto-commit step then saves this back to your repo.

Round 2: Testing "Update" (PUT)

Now that the files have an id assigned to them, you can test the update patterns.

Run git pull on your local machine to fetch the mock IDs added by the GitHub Action.
Open the 4 files and make a tiny change (e.g., add a new line at the bottom).
Commit and push again.

Check the GitHub Actions logs once more. Because the files now contain an id in their front matter, the action correctly identifies them as existing articles. You will see that it would have executed a PUT request to https://dev.to/api/articles/<mock-id>.

Conclusion

And just like that, you've tested your entire CI/CD publishing pipeline—including file diffing, ID injection, and payload generation—without publishing a single test post to your actual Dev.to feed!

Once you are confident, simply remove dry_run: 'true' from your workflow, and you are ready to automate your Dev.to blog.

Feel free to check out the action here: Publish to Dev.to Organization Action

Happy automating! 🚀