Forem: Ranieri Althoff

Speed up Next.js build with Typescript and Tailwind CSS

Ranieri Althoff — Wed, 24 Mar 2021 09:19:41 +0000

In the project I'm currently working with, we have a platform split between a single-page React app and a Next.js SSR website. The development server runs both in the same machine, using containers, but it has only one processor core and 2 GB of RAM.

The React SPA is big, and it takes a while to build. Next.js is notably very slow to build too, even if we only have a handful of pages. I'll document my quest to reduce the unbelievable build times, ranging from at least 5 minutes up to 22 (!) minutes when both are building in parallel.

Setting the baseline

I will not be running the tests on the dev server, but on my machine. I have a Ryzen 7 4800H with 16 GB of RAM, so the build will not be bottlenecked by hardware as heavily as the aforementioned server.

On this machine, the React SPA takes 84s to build, and Next.js takes 112s. We will reduce the time spent build CSS, and then on building Typescript.

CSS: `@tailwindcss/jit`

Update: You don't need to install a separate package anymore. Just add mode: 'jit' to your tailwind.config.js file and you are good to go! I will keep reading this section for historic purposes :)

The big issue with Tailwind is that it pulls a huge amount of CSS classes into the parser, in the form of a 3.6 MB CSS file - or 6.0 MB if you enable dark mode. This is heavy on PostCSS, uses a lot of memory (our server would frequently trigger OOM kills).

Enter @tailwindcss/jit, a drop-in replacement (though not with 100% feature parity yet) that collects the classes used by your files and only generates the requested classes.

Outdated PostCSS plugins

In this process, we had to get rid of two PostCSS plugins that were not updated to work with PostCSS 8, which is required by @tailwindcss/jit: precss and postcss-rtl, both of which are unmaintained and won't be updated.

We replaced the former with postcss-nesting and rewritten the CSS to not use the rest of the features from precss - in our case, this was an easy job.

The latter was replaced by tailwindcss-rtl, which is instead a Tailwind plugin. It works great and requires very little effort, you just need to search and replace some non-RTL classes with RTL equivalents - which I expect to be easily swappable once Tailwind supports CSS Logical Properties.

These are the changes required in webpack.config.js:

    module: {
        rules: [
            ...
            {
                test: /\.css$/,
                use: [
                    ...,
                    {
                        loader: 'postcss-loader',
                        options: {
-                           postcssOptions: { plugins: ['postcss-import', 'postcss-url', 'tailwindcss', 'precss', 'postcss-rtl'] },
+                           postcssOptions: { plugins: ['postcss-import', 'postcss-url', '@tailwindcss/jit'] },
                        },
                    },
                ],
            },
            ...
        ],
    },
    ...

Don't forget to update your tailwind.config.js file, the instructions are in the @tailwindcss/jit README.

Results

This has the benefit of not only reducing the load on the parser, but also generating a much smaller CSS file by default, even without minification: a drop from 17.2 MB to 461 KiB before PurgeCSS for the SPA, and from 110 KiB to 1.34 KiB for the Next.js website.

With only that change so far, it reduces the build time to 66s for the SPA and to an amazing 26s for Next.js. I guess that the SPA didn't benefit as much because it uses much more classes - as evidenced by the significantly smaller CSS output.

Typescript: `esbuild` & `esbuild-loader`

esbuild is a JS and TS bundler that promises ultra-fast build times. We use webpack, and there is support to leverage esbuild with esbuild-loader.

Using esbuild-loader is really simple, we just need to swap ts-loader (or babel-loader, but I didn't use that) with esbuild-loader in your webpack.config.js:

    ...
    module: {
        rules: [
            ...
            {
                test: /\.tsx?$/,
                use: [
                    'cache-loader',
-                   'ts-loader',
+                   {
+                       loader: 'esbuild-loader',
+                       options: { loader: 'tsx' },
+                   },
                ],
            },
            ...
        ],
    },
    ...

Furthermore, since we use the new JSX transform and esbuild does not support it yet, instead transforming JSX to calls to React.createElement which is not available, we need to provide a global React variable. This is super simple with webpack:

+const { ProvidePlugin } = require('webpack');

    ...
    plugins: [
        ...
+       new ProvidePlugin({
+           React: 'react',
+       }),
    ],
    ...

The improvement, in real life, is not as huge as advertised in esbuild's website - I guess because it is not pure JS/TS - but still very significant: building the SPA now takes less than 20s. However, we didn't see as much improvement for Next.js, now taking about 22s. It doesn't hurt, so we will keep it 🤷

Conclusion

We brought down the build time from 84s down to 20s for a React SPA, and from a painful 112s down to 22s for a Next.js SSR website by just swapping the tools used to build. No features were harmed in the process, and we even ended up with less generated CSS.

Additionally, our pipelines used to take at least 5 minutes for a full build and deploy, and now only take around 3 minutes, caching and spinning the containers included, and it does not run out of RAM anymore. Mission accomplished.

On a separate note, we haven't suffered from this out-of-memory situation since we made the switch, and it seems to be related with excessive amounts of CSS.

Perfectly localizing date & time with Intl.DateTimeFormat

Ranieri Althoff — Thu, 03 Dec 2020 09:25:24 +0000

The ECMAScript Internationalization API is a namespace that contains several utilities to format values in a language-sensitive way. It solves the issue of outputting dates, numbers, collections, and more built into the browser.

In this post, we will visit these utilities, show how to use them and where they are already available.

`Intl.DateTimeFormat`

DateTimeFormat is a constructor for language-sensitive time formatting. It supports date, time, a combination of both and you can control each part of the result. The syntax to create a new formatter is:

new Intl.DateTimeFormat([locales[, options]])

If you omit both parameters, it will use the current browser locale and default options for such locale.

Throughout the article, I will use November 5th, 2020 at 01:02:03 AM GMT+1 (new Date("2020-11-05T00:01:02+01:00")) as the example date.

When to use it?

DateTimeFormat is useful if you want to format dates in several different places using the same formatting rules, as it allows to concentrate the options in a single place. For example, you can export it in your l10n/i18n context if using React.

For one-off formatting, you may prefer to use Date.toLocaleString and its partners, Date.toLocaleDateString and Date.toLocaleTimeString to avoid the extra step of instantiating the DateTimeFormat object. All of these functions take the same attributes the constructor for DateTimeFormat takes: locale and options. Let's see what those are.

`locale`

The first parameter, locales, is one or a list of possible locales for negotiation. Language negotiation is an intricate subject, and I don't want to dive into it yet, so check the MDN reference if you need details.

Here are some examples of how the locale will change the output:

const dtf = new Intl.DateTimeFormat();
dtf.format(date);
//=> "11/5/2020"
// equivalent to date.toLocaleDateString()

const dtf = new Intl.DateTimeFormat('pt-BR');
dtf.format(date);
//=> "05/11/2020"
// equivalent to date.toLocaleDateString('pt-BR')

Note the difference: the default, which in my case is 'en-US', uses the M/D/Y format. pt-BR, however, uses D/M/Y with zero left padded day and month values.

`options`

By default, DateTimeFormat only outputs the date, without the time. We can tweak using the options parameter, which may include the following attributes:

`year`, `month`, `day`

These attributes define how to format each part of the date individually.

For year, you can specify either:

numeric, which will display the year in full
2-digit, which will only display the last 2 digits of the year

const dtf = new Intl.DateTimeFormat('en', { year: 'numeric' });
dtf.format(date);
//=> "2020"
// equivalent to date.toLocaleDateString('en', { year: 'numeric' })
// you got it already, right?

const dtf = new Intl.DateTimeFormat('en', { year: '2-digit' });
dtf.format(date);
//=> "20"

month can be either numeric and 2-digit (zero-padded if lower than 10), but also has textual representations:

long, which will display the whole month name - short, which will display an abbreviation
narrow, which will display the first letter only (in English)

const dtf = new Intl.DateTimeFormat('en', { month: 'long' });
dtf.format(date);
//=> "November"

const dtf = new Intl.DateTimeFormat('en', { month: 'short' });
dtf.format(date);
//=> "Nov

const dtf = new Intl.DateTimeFormat('en', { month: 'narrow' });
dtf.format(date);
//=> "N"

Note that two months may have the same narrow representation in some languages, and it's not guaranteed to be a single character when not in English.

For day, there's only numeric and 2-digit (zero-padded).

const dtf = new Intl.DateTimeFormat('en', { day: 'numeric' });
dtf.format(date);
//=> "5"

const dtf = new Intl.DateTimeFormat('en', { day: '2-digit' });
dtf.format(date);
//=> "05"

Note that when you omit the options parameter, the default is assumed to be numeric for year, month, and day, but if you specify any combination, it will only output the values specified.

Depending on the combination of options, the output will be slightly different. You could expect that using { year: 'numeric', month: 'short', day: '2-digit' } would output Nov/05/2020 for that same date, however it does not:

const dtf = new Intl.DateTimeFormat('en', { year: 'numeric', month: 'short', day: '2-digit' });
dtf.format(date);
//=> "Nov 05, 2020"

`era`

If you are displaying dates more than 2000 years ago, you may be interested in using era. It can be long, short and narrow similar to how month works, and will display the current era (either AD or BC):

const dtf = new Intl.DateTimeFormat('en', { era: 'long' });
dtf.format(date);
//=> "11 5, 2020 Anno Domini"

const dtf = new Intl.DateTimeFormat('en', { era: 'short' });
dtf.format(date);
//=> "11 5, 2020 AD"

const dtf = new Intl.DateTimeFormat('en', { era: 'narrow' });
dtf.format(date);
//=> "11 5, 2020 A"

Note the full date is displayed too, not only the era.

`weekday`

This attribute controls if the weekday name should be displayed. It can be long, short and narrow similar to how month works:

const dtf = new Intl.DateTimeFormat('en', { weekday: 'long' });
dtf.format(date);
//=> "Thursday"

const dtf = new Intl.DateTimeFormat('en', { weekday: 'short' });
dtf.format(date);
//=> "Thu"

const dtf = new Intl.DateTimeFormat('en', { weekday: 'narrow' });
dtf.format(date);
//=> "T"

Note that two weekdays may have the same narrow representation in some languages, and it's not guaranteed to be a single character when not in English.

`hour`, `minute` and `second`

Both these options have only two possibilities, numeric and 2-digit. However, there are two catches.

First, for minute and second, numeric will behave the same as 2-digit unless only one of three options is specified:

const dtf = new Intl.DateTimeFormat('en', { minute: 'numeric', second: 'numeric' });
dtf.format(date);
//=> "01:02"

const dtf = new Intl.DateTimeFormat('en', { minute: 'numeric' });
dtf.format(date);
//=> "1"

Second, for 12-hour clocks, displaying hour will also append AM/PM to the output:

const dtf = new Intl.DateTimeFormat('en', { hour: 'numeric', minute: 'numeric', second: 'numeric' });
dtf.format(date);
//=> "12:01:02 AM"

You can control AM/PM behavior with the next options.

`hourCycle` and `h12`

These options control the hour cycle to use, that is if the clock has 24 hours a day or two 12-hour periods and whether it starts at 0 or 1. The defaults are locale-dependent.

`hourCycle`	output
`'h11'`	"0:01:02 AM"
`'h12'`	"12:01:02 AM"
`'h23'`	"00:01:02"
`'h24'`	"24:01:02"

Notes:

hourCycle: 'h12' is the default for US English
hour: '2-digit' is forced when using h23/h24

As for hour12, it will toggle between h11 and h23, or between h12 and h24 depending on the locale.

`locale`	`h12`	output
`'en'`	`false`	"12:01:02 AM"
`'pt-BR'`	`true`	"0:01:02 AM"

Notes:

US English uses h12 by default, therefore hour12: false sets hourCycle: 'h24'
BR Portuguese uses h23 by default, therefore hour12: true sets hourCycle: 'h12'

`timeZone`

The timeZone attribute is self-explanatory, and defines the time zone to use. The default is to use the system time zone:

const dtf = new Intl.DateTimeFormat('en', { ... });
dtf.format(date);
//=> "12:01:02 AM"

const dtf = new Intl.DateTimeFormat('en', { ..., timeZone: 'America/Sao_Paulo' });
dtf.format(date);
//=> "8:01:02 PM"

moving from GMT+1 to GMT-3

`timeZoneName`

It is responsible for the representation of the time zone name, and can be long or short. It can't be used together with timeStyle, which we will cover next:

const dtf = new Intl.DateTimeFormat('en', { timeZoneName: 'long' });
dtf.format(date);
//=> "12/5/2020, Coordinated Universal Time"

const dtf = new Intl.DateTimeFormat('en', { timeZoneName: 'short' });
dtf.format(date);
//=> "12/5/2020, UTC"

`dateStyle` and `timeStyle`

Now, in case you don't know, default date formats may differ between locales, so you can't rely on setting year: 'numeric' for a short date string since some locales would prefer year: '2-digit' for short dates, while others simply don't use 2-digit years, never.

For that reason, you can use dateStyle and timeStyle, which will set reasonable values for all date- and time-related options at once! Both can be full, long, medium and short and can't be mixed with other options, only together.

Say you want the most verbose representation of a date:

const dtf = new Intl.DateTimeFormat('en', { dateStyle: 'full', timeStyle: 'full' });
dtf.format(date);
//=> "Saturday, December 5, 2020 at 12:00:00 AM Coordinated Universal Time"

That is similar to setting every option to long or equivalent, with a single option.

Or maybe you want the most concise display for the given locale:

const dtf = new Intl.DateTimeFormat('en', { dateStyle: 'short', timeStyle: 'short' });
dtf.format(date);
//=> "12/5/20, 12:00 AM"

const dtf = new Intl.DateTimeFormat('pt-BR', { dateStyle: 'short', timeStyle: 'short' });
dtf.format(date);
//=> "05/12/2020 00:00"

Note that the style is different, as English uses { year: '2-digit', month: 'numeric' }, has a comma separator, and day period, but Brazilian Portuguese uses { year: 'numeric', month: '2-digit' }, has no comma separator, and 24-hour clock? This is simply not feasible with plain options, so dateStyle and timeStyle are really handy.

But there is a catch. dateStyle and timeStyle are recent additions, and only available in Firefox >= 79, Chrome >= 76, and are not available in Edge and Safari at the time of writing. You can polyfill with polyfill.io.

That pretty much sums up what I wanted to show about Intl.DateTimeFormat! I will write about formatToParts and formatRange, and about other utilities inside Intl such as ListFormat and RelativeTimeFormat, follow me to stay tuned!

Photo by Jon Tyson on Unsplash

Leverage tree shaking with modular Lodash

Ranieri Althoff — Fri, 17 Jul 2020 22:21:26 +0000

A follow up to replacing Redux with React Components, I'm using the ES module version of Lodash to leverage tree shaking with Parcel.

Lodash is the Swiss army knife of Javascript, but being so useful makes it huge. Analyzing our bundle with Bundle Buddy reveals Lodash is responsible for 70 KB of the bundle. Not the largest chunk, but one we can easily fix: it is not being tree shaken.

Tree shaking is the concept of removing dead code (that is, code paths that are never accessed) from the final bundle. We use only 8 functions from Lodash, namely: groupBy, keyBy, isEqual, sortBy, times, uniq, uniqBy and xor. Lodash has hundreds of functions and we don't need everything.

There are several manners of doing that, my chosen one is replacing with lodash-es and leaving dead code elimination to the bundler. You can also use babel-plugin-lodash but I didn't find that as easy to set up.

I then ran sed -i -e "s/'lodash'/'lodash-es'/" src/**.ts* to replace all imports, after replacing the package in package.json.

This reduced the JS bundle by over 50 KB, with lodash-es now using only 19 KB!

Cover image by Johann Siemens (see in Unsplash).

Replacing Redux with React Contexts

Ranieri Althoff — Thu, 25 Jun 2020 16:52:23 +0000

In my current project, we used to use Redux for things like user authentication, language preferences, viewport width, and in general sharing state between components deep down the tree.

Long ago, we started replacing the shared state with contexts, as it is easier to provide and manage state localized to just a part of the application. That way, the state does not leak upwards, that is, the login page does not have to have access to the to-do list.

A practical example, only relevant bits:

type SetLanguageAction = {
    type: 'SET_LANGUAGE'
    language: string
}

const language = (
    state: string = initialLanguage,
    action: SetLanguageAction
) => {
    if (action.type !== 'SET_LANGUAGE') {
        return state
    }

    localStorage.set('language', action.language)
    return action.language
}

// plus boilerplate to attach it to the store

With context, it becomes:

import React from 'react'

const Context = React.createContext({} as {
    language: string
    setLanguage: React.Dispatch<React.SetStateAction<string>>
})

const LanguageProvider: React.FC = ({ children }) => {
    const [language, setLanguage] = useLocalStorage('language', initialLanguage)

    return (
        <Context.Provider value={{ language, setLanguage }}>
            {children}
        </Context.Provider>
    )
}

const useLanguage = () => React.useContext(Context)
// and that's it!

See, the entire behavior is contained in a single file, and not spread across as is common with Redux (you would have actions.ts, reducers.ts to glue everything).

Additionally, you get full React hooks power, as Providers are React components. As an example, I got access to useLocalStorage (that's from react-use) and don't need to handle local storage by hand.

It helps isolate behavior, but it also helps with stricter typing. In user authentication, if the user state was inside the global state, it's type would be User | null, as the user data is initialized after data is loaded from the backend.

With a localized context, it can be User and we never have to check for nullability or stick ! after accessing the store, as I can suspend rendering while waiting for data to load (say if (!user) return null). It goes really well with SWR :)

Cover image by Timothy Meinberg (see in Unsplash).

Migrating existing code to a new password hashing algorithm

Ranieri Althoff — Thu, 04 Jun 2020 03:00:28 +0000

I maintain the node-argon2 and oftentimes people are afraid to use it due to having a codebase using another password hashing algorithm (e.g. PBKDF2, bcrypt) and how would it be to migrate to Argon2.

Even though the procedure below uses bcrypt and Argon2 as examples, it works to migrate between any two (or more) password hashing algorithms, as long as you can determine what algorithm a given hash uses. In this case, bcrypt hashes start with $2, and Argon2 hashes start with $argon2.

The idea behind it would also work for any language, not only Javascript, once you grasp it.

If your database uses another hash function for passwords, you can gradually migrate to Argon2 to improve security. To do that, you need to rehash your user's password as they log in.

Suppose we want want to migrate from bcrypt, with the following code:

import bcrypt from 'bcrypt'

router.post('/login', async ctx => {
  const { email, password } = ctx.request.body
  const user = await User.findOne({ email })

  const match = await bcrypt.compare(password, user.password)
  if (!match) {
    throw new Error('Unauthorized')
  }
  // user is authorized
  ...
})

You need to branch before checking the user password and verify what function the current password uses. Then, proceed to update if the password is still using the previous function.

import argon2 from 'argon2'
import bcrypt from 'bcrypt'

router.post('/login', async ctx => {
  const { email, password } = ctx.request.body
  const user = await User.findOne({ email })

  // bcrypt hashes start with $2a$ or $2b$
  // argon2 hashes start with $argon2i$, $argon2d$ or $argon2id$
  if (user.password.startsWith('$2')) {
    const match = await bcrypt.compare(password, user.password)
    if (!match) {
      throw new Error('Unauthorized')
    }

    // rehash password with argon2 and save to database
    user.password = await argon2.hash(password)
    await user.save()
  } else {
    const match = await argon2.verify(user.password, password)
    if (!match) {
      throw new Error('Unauthorized')
    }
  }
  // user is authorized and password is updated
  ...
})

And you're done! Your passwords will be gradually updated to use Argon2.

Making an algorithm 15x faster without parallelism

Ranieri Althoff — Fri, 15 May 2020 01:43:07 +0000

A couple of years ago, when investigating the performance of a game server, I noticed that a large chunk of the processing time was spent ciphering and deciphering data that was sent to or received by the client. It was especially high on busy servers, as the amount of work would increase linearly with the amount of players, and it was performed in a single thread, the dedicated network dispatcher.

The server in question uses an algorithm called XTEA, a 64-bit block cipher based on a Feistel network. It is very simple and easy to implement, achieving under 10 lines of C++ code:

constexpr uint32_t delta = 0x9E3779B9;

uint64_t encrypt_block(uint64_t data, const array<uint32_t, 4> &key) {
  unsigned left = data, right = data >> 32;
  uint32_t sum = 0u;
  for (auto i = 0u; i < 32u; ++i) {
    left += ((right << 4 ^ right >> 5) + right) ^ (sum + key[sum & 3]);
    sum += delta;
    right += ((left << 4 ^ left >> 5) + left) ^ (sum + key[(sum >> 11) & 3]);
  }
  return static_cast<uint64_t>(right) << 32 | left;
}

Deciphering is symmetrical, being essentially the code above reversed:

auto decrypt_block(uint64_t data, const array<uint32_t, 4> &key) {
  unsigned left = data, right = data >> 32;
  uint32_t sum = delta * 32;
  for (auto i = 32u; i > 0u; --i) {
    right -= ((left << 4 ^ left >> 5) + left) ^ (sum + key[(sum >> 11) & 3]);
    sum -= delta;
    left -= ((right << 4 ^ right >> 5) + right) ^ (sum + key[sum & 3]);
  }
  return static_cast<uint64_t>(right) << 32 | left;

I will be running tests on my i7 8809G, using 25 KB of random values and 2500 samples. -O3 and -march=native are imperative to the changes proposed.

reference code

The code found on the server to cipher a message uses a while loop to check for boundaries:

auto pos = 0ul, len = in.size();
while (pos < len) {
  in[pos] = encrypt_block(in[pos]);
  ++pos;
}

To set the baseline, it takes an average of 267μs to cipher/decipher a message, with a standard deviation of ~50μs. It accounts for ~87MB/s throughput.

`while` vs `for` loop

The first idea here will be replacing the while loop, I prefer using for loop for known boundaries and figured it might help the compiler unroll the loop.

for (auto pos = 0ul, len = in.size(); pos < len; ++pos) {
  in[pos] = encrypt_block(in[pos]);
}

I was not hopeful of that, and was right: the len value is invariant to the loop, so the compiler emits the same set of instructions.

To make the code a bit more idiomatic C++ and less C, we can use range-based for loop or std::transform (if you prefer a functional looking code):

for (auto &block : in) {
  block = encrypt_block(block);
}

But hey!

parallelism with execution policy

There is something interesting with C++17, a concept named Execution Policy. You can tag sequence algorithms to run parallel or unsequenced if possible, using execution::par and execution::unseq (only in C++20) respectively, and even execution::par_unseq for parallel AND unsequenced.

This code uses electronic codebook mode (ECB) and application is not sequenced, you can apply the cipher in any order. I wonder what happens if we use execution::par...

std::transform(std::execution::par, in.begin(), in.end(), in.begin(), encrypt_block);

That dropped the time from 267μs to 62μs to cipher/decipher a message, with a standard deviation of ~50μs. It accounts for ~334MB/s throughput. The same performance with execution::par_unseq, in case you are wondering.

That is a 4.3x improvement, but there's a catch: this high standard deviation is due to the worst cases taking up to 1300μs, 2.5x worse than the worst cases of the reference implementation, which take up to 550μs.

That's a red flag, it's a very inconsistently performing algorithm. If the server is especially busy, it might interfere with other threads and make the server as a whole slower.

Another issue you might consider is linking against a threading library - in my system, it requires the Intel Threading Building Blocks. So let's think of something else.

interleaving loops and automatic vectorization

One more trick upon my sleeve. Compilers are extremely advanced pieces of software, performing several optimizations that we most of the time take for granted, but you need to write code it understands and sometimes optimize on your own.

We can interleave the loops, hoisting the Feistel network rounds around the ciphering pass. That's possible because in ECB mode blocks are independent, it does not change the output if you transpose the application of the algorithm.

uint32_t sum = 0u;
for (auto i = 0u; i < 32u; ++i) {
  auto next_sum = sum + delta;
  for (auto &block : in) {
    uint32_t left = block, right = block >> 32;
    left += ((right << 4 ^ right >> 5) + right) ^ (sum + key[sum & 3]);
    right += ((left << 4 ^ left >> 5) + left) ^ (next_sum + key[(next_sum >> 11) & 3]);
    block = static_cast<uint64_t>(right) << 32 | left;
  }
  sum = next_sum;
}

This code looks, in my opinion, simpler and better to understand. Note I also hoisted sum += delta, that's required as we don't have a new sum value on every block. Instead, we use the same variable for all blocks at once.

This takes 55μs to cipher/decipher a message, down from previous 62μs and initial 267μs, with a standard deviation of ~26μs. It accounts for ~384MB/s throughput. That is a further 12% improvement, however, the worst-case takes 200μs, making it much more consistent and faster than the reference implementation on every run, even compared to its best-case run.

Why the improvement? It leverages what is called automatic vectorization: your processor has vector registers, and it allows applying a single instruction (be it a xor, an add or a shift) to several values at the same time.

The compiler will generate code using special registers named %ymmX and %xmmX, where X denotes register index. %xmm registers are 128 bits wide. %ymm registers are 256 bits wide and are available if your processor supports AVX (Intel Core except for 1st gen, AMD after Phenom II).

It will generate assembly using instructions such as vpxor %ymm0, %ymm1, %ymm1 and vpaddd %ymm2, %ymm1, %ymm1, instead of the traditional xor %edx, %eax and add %r14d, %eax. I won't display the assembly code here, it is so heavily optimized you won't really see what's happening.

The beauty here is that the compiler (I am using GCC 10.1.0) is smart enough to figure data might not always be aligned to the wide registers (i.e. input is not always a multiple of 128/256 bits), and it will generate code for that case: it uses wide registers while possible, then resort to a single value at a time.

So far, we have a 4.8x improvement, in line with the change in emitted machine code: the resulting code processes up to 4 blocks at a time (64-bit block in 256-bit registers), the rest can be attributed to loop analysis, as it is easier to unroll the loop and interleave instructions after we extracted an invariant (next_sum).

all `for` variables inside declaration

One last trick that I did not expect would help, I just tried it to save a few lines, is moving all for-related variables inside the declaration block:

for (auto i = 0u, sum = 0u, next_sum = sum + delta; i < 32u;
     ++i, sum = next_sum, next_sum += delta)

It further reduces the average to 51μs, the standard deviation to ~15μs, and the maximum time is now ~140μs. It runs consistently fast, processing 424MB/s. Neat!

In conclusion, the final version of the code is 5.23x faster than the reference implementation, does not impact the rest of the software and is just as short and clear:

constexpr uint32_t delta = 0x9E3779B9;

vector<uint64_t> encrypt(vector<uint64_t> in, const array<uint32_t, 4> &k) {
  for (auto i = 0u, sum = 0u, next_sum = sum + delta; i < 32u;
       ++i, sum = next_sum, next_sum += delta) {
    for (auto &block : in) {
      uint32_t left = block, right = block >> 32;
      left += ((right << 4 ^ right >> 5) + right) ^ (sum + key[sum & 3]);
      right += ((left << 4 ^ left >> 5) + left) ^
               (next_sum + key[(next_sum >> 11) & 3]);
      block = static_cast<uint64_t>(right) << 32 | left;
    }
  }
  return in;
}

vector<uint64_t> decrypt(vector<uint64_t> in, const array<uint32_t, 4> &k) {
  for (auto i = 0u, sum = delta * 32, next_sum = sum - delta; i < 32u;
       ++i, sum = next_sum, next_sum -= delta) {
    for (auto &block : in) {
      uint32_t left = block, right = block >> 32;
      right -= ((left << 4 ^ left >> 5) + left) ^ (sum + key[(sum >> 11) & 3]);
      left -=
          ((right << 4 ^ right >> 5) + right) ^ (next_sum + key[next_sum & 3]);
      block = static_cast<uint64_t>(right) << 32 | left;
    }
  };
  return in;
}

OpenCL and massive GPU vectorization

After the results for vectorizing the algorithm, I investigated if running in the GPU would scale the same way, considering my GPU (Radeon Vega M GH) has 24 compute units with 4 128-bit registers each, capable of ciphering 192 blocks (1536 bytes) at once! That would make XTEA almost instant.

The game server already used the Boost library, and it has a layer for OpenCL called boost::compute. OpenCL uses code units called kernels, itself implementing a subset of C, which makes it very easy to port code to OpenCL, as long as it uses primitives only (there's more to it):

auto encrypt(Data in, const compute::uint4_ &k) {
  BOOST_COMPUTE_CLOSURE(uint64_t, encrypt_block, (uint64_t data), (k, delta), {
    unsigned left = data, right = data >> 32;
    for (int i = 0, sum = 0, next_sum = delta; i < 32;
         ++i, sum = next_sum, next_sum += delta) {
      left += ((right << 4 ^ right >> 5) + right) ^ (sum + k[sum & 3]);
      right += ((left << 4 ^ left >> 5) + left) ^ (next_sum + k[(next_sum >> 11) & 3]);
    }
    return ((unsigned long long)right) << 32 | left;
  });

  compute::vector<uint64_t> out(in.begin(), in.end());
  compute::transform(out.begin(), out.end(), out.begin(), encrypt_block);
  compute::copy(out.begin(), out.end(), in.begin());
  return in;
}

auto decrypt(Data in, const compute::uint4_ &k) {
  BOOST_COMPUTE_CLOSURE(uint64_t, decrypt_block, (uint64_t data), (k, delta), {
    unsigned left = data, right = data >> 32;
    for (int i = 0, sum = delta * 32, next_sum = sum - delta; i < 32;
         ++i, sum = next_sum, next_sum -= delta) {
      right -= ((left << 4 ^ left >> 5) + left) ^ (sum + k[(sum >> 11) & 3]);
      left -= ((right << 4 ^ right >> 5) + right) ^ (next_sum + k[next_sum & 3]);
    }
    return ((unsigned long long)right) << 32 | left;
  });

  compute::vector<uint64_t> out(in.begin(), in.end());
  compute::transform(out.begin(), out.end(), out.begin(), decrypt_block);
  compute::copy(out.begin(), out.end(), in.begin());
  return in;
}

Note the key is changed from array<uint32_t, 4> to compute::uint4_t (a name I find unnecessarily confusing, could be vec4_uint32), representing 4 32-bit ints inside the GPU. Since the key is reused, I figured that a real application would precompute it instead of copying it to the GPU every time.

Using OpenCL requires two additional steps: copying the data to the GPU memory, achieved through the compute::vector container, and compute::transform algorithm; then, it needs to be copied back to main memory. Kudos to Boost for making it so easy!

The extra steps are costly, and this takes 108μs, on average, with a standard deviation of ~36μs and a maximum of ~560μs. It would be a disappointment, but if we ramp up the input size, the GPU massive parallelization really shines!

I set an input length of 500KB instead of the initial 25KB, with the following results:

The reference implementation takes ~5080μs
Vectorized takes ~1170μs
OpenCL takes ~403μs

By having a 20x larger input, running on the CPU will also multiply by 20 the run time, but since the GPU is capable of executing the same code on a much wider vector of data, it only requires 2.4x the time and takes the leadership here.

It achieves an amazing throughput of 1185MB/s, compared to 95MB/s for the reference implementation and 410MB/s for the CPU-vectorized implementation, for 250KB input. It will peak at 1450MB/s when I use 1572KB input size, as it hits the sweet spot of filling the entire cache (64KB each) for all 24 compute units.

Unfortunately, in the game server use case, about 99% of the inputs will be less than 32 bytes, and it is never larger than 25KB. At that size, the CPU vectorized version is at least 5 times faster than reference. However, for one wanting to cipher massive amounts of bytes, that's a 15x improvement :)

The code for this post and a benchmarking utility is available on GitHub.

Forem: Ranieri Althoff

Speed up Next.js build with Typescript and Tailwind CSS

Setting the baseline

CSS: @tailwindcss/jit

Outdated PostCSS plugins

Results

Typescript: esbuild & esbuild-loader

Conclusion

Perfectly localizing date & time with Intl.DateTimeFormat

Intl.DateTimeFormat

When to use it?

locale

options

year, month, day

era

weekday

hour, minute and second

hourCycle and h12

timeZone

timeZoneName

dateStyle and timeStyle