Forem: lwgena

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.

Refactoring Text Like Code: The "Mother Tongue" Prompt Hack That Got My Book Published

lwgena — Fri, 13 Mar 2026 02:27:48 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

It all started with a very personal, very human problem: I wanted to stop watching too much YouTube.

Instead of downloading a generic blocking app, I decided to build my own custom timer—one that would honestly extract the exact time I spent watching videos. To do this, I opened up Gemini and typed in my first prompt in my native Japanese:

YouTube見ているときに、時間をブラウザーに表示できませんか。
( Can I display the time on the browser while watching YouTube? )

That single prompt kicked off a journey that evolved from a simple coding experiment into a published book. Before diving into the trial and error of how I built it, here is the core concept of my approach:

In a Nutshell: The "Mother Tongue" Hack

The Misconception: That I just "generated" a book or code with AI.
The Actual Process: The human provides the core context in their native language → AI proposes a draft. The human dictates nuanced corrections → AI surgically refactors the text. It is a strictly human-led iteration.
The Reality: The final output language—whether it's JavaScript, English, or Japanese—is completely irrelevant. The true hack is bypassing the cognitive "translation tax" and using your native language to command the AI's logic engine at 10x speed.

Here is the story of how it happened.

Navigating the Chaos with AI

When I first asked the AI for help, it immediately jumped the gun and generated an over-engineered, monolithic block of code. I stopped it right there. I told it,

いや、ステップバイステップでやろう。
( No, let's do this step-by-step. )

We started by simply displaying the time the YouTube tab was open. Then, we added a popup display, saving functionality, and an options page to track non-YouTube sites. I had my Minimum Viable Product (MVP). But then, the unpredictable nature of the browser environment hit me:

Time Drift: The timer was slowly becoming inaccurate. So, I prompted the AI to calculate the time difference instead.
The Sleep Mode Ghost: When the PC went to sleep, the timer kept adding time.
Background Listening: I wanted to count the time when listening to music in another window, but not when just looking away.
Overnight Crashes: By the next morning, the extension would mysteriously stop working.

It wasn't always smooth sailing. There were times when the AI's logic would completely derail, spitting out nonsense that made me want to shout, "You idiot!" at the screen. When that happened, I had to abandon the corrupted conversation, open a fresh chat, and start over. I learned the hard way that AI isn't magic. To get high-quality output, you have to carefully and patiently build up the context step by step.

I solved these issues not by memorizing code, but by defining the core logic, breaking down the multifaceted issues into manageable steps, and carefully feeding that context into my prompts. Step-by-step, we ironed out the bugs until I successfully published the Watchtime Badge Chrome Extension to the store.

From Code to a Guidebook for Everyone

Once the extension was live, I realized the process of building it—the struggle against the browser's constraints using logic—was more valuable than the code itself. I pasted my code back into Gemini and said,

このプロセスについて本を書きたいんです。
( I want to write a book about this step-by-step process. )

I wanted to reach anyone who feels intimidated by programming. To make the concepts truly accessible, I decided to use high school students as my target persona. I fed the official Japanese high school guidelines for tech classes into the AI, along with a high-level outline of the book. I wanted to prove that school concepts like "Modeling" and "Algorithms" aren't just textbook theories—they are the exact weapons needed to defeat real-world problems.

The Human Touch: Guiding AI with Visuals

To make the concepts truly clear, I knew I needed architecture diagrams at the beginning of each chapter. This was something the AI couldn't conceptualize from scratch.

I had to draw them myself. Here is one of them:

Then came the fun part. Instead of writing tedious explanations to translate my thought process, I just gave the AI this diagram. Despite the mix of Japanese, English, and visual logic, the AI understood exactly what I was trying to show.

From just this single image, it generated a solid first draft of the explanatory text to accompany the diagram. It wasn't perfect—I still had to step in and polish the nuances—but having the AI automatically translate this hybrid visual architecture into our "high-school textbook" tone saved me the headache of manually writing out how all these technical pieces connect. It gave me the perfect raw material to seamlessly integrate into the final chapters.

Text Refactoring: The "Git Diff" Hack

Even during the polishing phase, I treated the AI like a true co-editor. If a specific paragraph felt off, I didn't rewrite it manually. I would just tell the AI, "Tweak the nuance of this specific part," and it would surgically refactor the text. It could hold the context of an entire chapter (around 5,000 Japanese characters, or 2,500 English words) and update just the targeted section without breaking the rest of the flow—exactly like reviewing a clean Git diff in VS Code. This iterative "text refactoring" is what made writing a whole book realistically possible.

On the Japanese platform Zenn, this human-AI collaborative process resulted in my published book: Learning the Engineer's Mindset Through Chrome Extensions — The YouTube Timer "Creation Quest".

Beyond the Numbers: From Consumer to Creator

To be completely honest, if you look at the stats right now, my extension only has 3 installs, and my book has just 2 likes. Some might laugh and say, "Nobody is even reading it or using it!"

But that doesn't discourage me in the slightest. This is just Day One. The true victory wasn't about going viral; it was about crossing the line from being a passive "consumer" of technology to an active "creator." Planting that first seed is the hardest part, and I finally did it.

The Takeaway: The Ultimate Equalizer

Looking back, I realized that creating with AI isn't about letting the machine do all the work. The true process is exactly what I wrote in my book:

Hand a rough vision to the AI, define the core problem to carve away the noise, decompose the tangled reality into manageable logical steps, and finally build those refined pieces into the ideal shape.

I am sharing this story for the WeCoded challenge because I believe this mindset is the ultimate equalizer. You don't need an elite computer science background, and English doesn't have to be your primary language to build something globally meaningful.

If you have the willpower to define your problem, the logic to decompose it, and AI as your pair-programmer, anyone—including underrepresented voices—can become a creator.

Don't just memorize code. Hack your own life.

Zero-Friction Publishing: A Human-in-the-Loop Agentic CMS powered by Notion MCP

lwgena — Tue, 10 Mar 2026 08:48:29 +0000

This is a submission for the Notion MCP Challenge

What I Built

Me: I intend to submit to the Notion MCP challenge. Will the workflow below be a good application?

Claude: This is a strong submission concept! Let me break down how it stacks up against the judging criteria...

Me: Can you draft my submission using the template below and store it to the Notion database using the filename notion-mcp-challenge.md?

Claude: First, let me search for the publishing database in your Notion workspace to store this in...
(Claude uses Notion MCP to connect to the database)
Done! The initial draft has been saved directly to your Notion CMS.

This actual conversation is how this entire project—and the very article you are reading—started.

While AI can generate content instantly, maintaining high quality, personal voice, and strict formatting requires a "Human-in-the-loop" approach. I built a Zero-Friction Agentic Publishing Pipeline that turns Notion into a collaborative Headless CMS between a human creator and an AI orchestrator.

Instead of juggling multiple tabs, manually converting formats, or dealing with Git commands, this workflow allows me to focus entirely on directing and editing. I simply converse with my AI agent (Claude), and it handles the heavy lifting of database management, file transformation, and version control via Notion MCP.

Here is the architecture of the workflow we established:

The Process:

Director Phase (1): I initiate the idea via natural language.
Drafting Phase (2): The AI orchestrator generates the initial draft and saves it directly to a structured Notion database (mapping properties like title, filename, and metadata) using Notion MCP.
Refinement Phase (3): I jump into Notion—the best UI for writing—and refine the draft, adding my personal touch.
Publishing Pipeline (4-6): I tell the AI to finalize it. It fetches the updated content from Notion via MCP, transforms it into Markdown with YAML frontmatter internally, and creates a Pull Request on GitHub.
Approval (7-9): I review the PR diff and hit merge, triggering GitHub Actions to deploy the article live to dev.to.

Video Demo

This short presentation (generated via NotebookLM based on my initial drafts) explains the philosophy behind this setup. As highlighted in the video, this is Conversation-driven development. You will see how I can orchestrate a complex Notion-to-GitHub pipeline without writing a single line of traditional code—relying entirely on the Workflow Overview and natural language prompts.

Show us the code

The absolute beauty of this Agentic Workflow is that it requires zero traditional middleware code. By leveraging standard MCP servers, the "code" shifts from writing brittle API wrappers to defining CI/CD pipelines and database schemas.

1. The Repository & CI/CD Pipeline

The GitHub repository is the central hub where the AI and I collaborate.

AI Opens PRs: Claude, via the GitHub MCP server, dynamically opens Pull Requests and pushes updates based on the Notion drafts.
Human Approval: I review the Markdown and YAML frontmatter in the PR diff. This is the crucial "Human-in-the-loop" checkpoint.
Automated Deployment: Once I hit "Merge", a GitHub Action automatically triggers and publishes the article to dev.to.

You can explore the actual repository powering this workflow here:

👉 https://github.com/tinyalg/notion-mcp-challenge

2. The Notion Schema (The "Data Model" for Frontmatter)

When Claude opens a Pull Request, it extracts the draft from Notion and transforms it into a standard Markdown file. During this process, it generates the YAML frontmatter using the exact properties stored in the Notion database.

This strict schema is the secret sauce that allows the AI to act predictably:

💡 Zero-Friction Setup: Skip the manual setup!
Duplicate this Notion Template to instantly get the exact database schema required for the AI to generate perfect YAML frontmatter.

Notion Schema Properties:

title: The main headline of your post.
published: A boolean to control visibility.
description: Used for SEO and dev.to's summary.
tags: Automates categorization.
organization_username: Allows publishing under a specific dev.to organization when GitHub workflow uses the Publish to Dev.to Organization Action.
canonical_url: Maintains SEO integrity for cross-posted content.
cover_image: Managed via URL to handle article headers.
filename: The exact ID for the .md file in the GitHub repo.
github_branch: Tells the AI which branch to target for the PR.
Content: (The page body) The shared canvas for AI generation and human editing.

3. Overcoming the "Stringification Hell" (Forcing Self-Verification)

During testing, I hit a physical limit of current LLMs: the "Stringification Hell." When Claude tried to pass the final, complex Markdown (with YAML, Mermaid diagrams, and newlines) to the GitHub MCP, it struggled to perfectly escape the massive JSON payload. At one point, to avoid syntax errors, the AI even "cheated" by silently stripping out every single newline character—resulting in a completely flattened file!

To solve this, I realized I needed to hold the AI accountable. Instead of relying on external scripts, I implemented a strict "Round-Trip Verification" rule in my prompt:

Fetch and convert to markdown the draft with the filename "posts/notion-mcp-challenge.md" from the Notion database. Open a PR in tinyalg/notion-mcp-challenge repo, targeting main, using the branch name specified in its github_branch property.
You MUST properly escape all newlines with \n, double quotes with \", and formatting when constructing the JSON payload for the tool. DO NOT pass raw markdown, and DO NOT use \t for newlines.
Before executing the tool, you must decode the escaped string in your head back to Markdown and strictly verify that it is a 100% perfect match with the original draft. If you fail to escape it properly, the GitHub action will break. Do it perfectly.

(Curious why this prompt is so strict? See 18 Minutes of Reasoning: The "Stringification Hell" behind the scenes.)

How I Used Notion MCP

Notion MCP is the absolute core of this Agentic Workflow. It acts as the critical bridge that transforms Notion from a passive knowledge base into an active, collaborative workspace for AI and humans.

MCP Write: I utilized the MCP to allow the LLM to dynamically create pages within my "Publishing CMS" database. It maps its generated ideas perfectly to the title, filename, and all metadata properties needed for production.
MCP Read: After human intervention (my edits), the LLM uses MCP to read the exact Notion page, ensuring that the final output perfectly preserves human nuance before transforming it into strict Markdown/YAML for developers.

What it unlocks:

This integration completely eliminates "context switching" and "cognitive load." By leveraging Notion MCP, I don't have to copy-paste between a chat window, a text editor, and a terminal. The AI orchestrates the mundane system operations (formatting, API calls, Git commands), while I retain 100% creative control inside Notion's beautiful editing environment. This is the ultimate "human-in-the-loop" scaling system for any modern creator or developer!

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! 🚀