Дмитрий Беляев

Во-первых, размер стека фиксирован, стек выделяется в момент запуска потока.
Во-вторых, компилятор и сам достаточно умный, чтобы переиспользовать стек под разные переменные использование которых не пересекается.
В-третьих, экономия на спичках, а читаемость ухудшается.

P.S. такую штуку действительно иногда используют, но ради того чтоб вызвать деструктор в нужной точке кода.

Звездочка здесь относится к типу, а не к имени, и означает, что это указатель, просто синтаксис C позволяет здесь поставить пробел в любом месте (или не ставить его вовсе)
По итогу, это функция match, которая принимает 2 аргумента - char и указатель на char, и возвращает так же указатель на char

В js строки в памяти хранятся в кодировке UTF16-LE (2-4 байта на символ, в большинстве случаев 2) и библиотека работает с байтами строки именно в ней
Библиотека на C++ принимает на вход std::vector при простом преобразовании строки в который Вы получите вектор байтов в текущей кодировке пользователя, скорее всего однобайтовой
Кодируйте строку на C++ в UTF16-LE перед шифрованием - тогда получите одинаковый результат

Попробовал написать рекурсивный фибоначи на чистом asm.js:

(function(std, env, heap) {
    'use asm';
    function fib(n) {
        n = n|0;
        if((n|0) < (2|0)) {
            return 1|0;
        }
        return (fib((n|0) - (1|0)) + fib((n|0) - (2|0)))|0;
    }
    return fib;
}(
    {},
    null,
    new ArrayBuffer(0)
));

Действительно медленнее чем на js
Причина очевидна: asm.js не оптимизируется никак, это готовые инструкции для виртуальной машины (например v8)
Обычный js перед компиляцией прогоняется через оптимизатор, который успешно преобразует хвостовые рекурсии в цикл

Делаем вывод, emscripten пока не умеет оптимизировать хвостовые рекурсии
И кстати какую опцию оптимизации вы отдавали в em++ ?

P.S. насчет производительности, у меня хэширующий алгоритм (crc64 с солью) после полного переписывания с js на asm.js дал прирост производительности в 21.7 раз (node 6.3.1 v8 5.0.71.57)