select * from и select count(*) from — это две большие разницы.
Более того, select count(*) from и select count(field) from вернут разные результаты, если в поле field есть стоки с NULL.
Т.е. всё выполняется порядка полсекунды? Автор, твой тест показывает погоду в унитазе.
Хотя бы потому, что при таком времени сильно влияет время запуска рантайма. А на это, в свою очередь, сильно влияет файловый кэш, расположение файлов на диске и т.п. Оказался у тебя Ruby 1.9 в кэше — и всё, «выигрыш».
Не знаю, вполне возможно Ruby 1.9 вновь окажется впереди, если время работы теста увеличить (ну хотя бы до 10 сек! А лучше до минуты). Но этим цифрам доверять нельзя.
Во-первых, если вычислять числа последовательно или почти последовательно (т.е. если количество чисел, обрабатываемых последовательно одним выч. узлом, сильно меньше, чем сами числа), то при переходе от n на n+m (где m сильно меньше n) корень легко пересчитывается: единичка либо прибавляется, либо нет :)
Во-вторых, в качестве альтернативы можно сравнивать p<=sqrt(n), а можно p*p<=n, и тут тоже можно придумать всякие оптимизации… ;)
Под линуксом можно использовать Émaçs, в котором, используя разные Input Method, можно вводить самые рáзные символы. А есть ещё nxml-móde, где можно вставить любой юникодный символ по имени (с completion). Мне хватает :)
В функции factorial, приведённой в качестве примера хвостовой рекурсии, рекурсия вовсе не хвостовая. Конечно, хорошо, что LLVM умеет преобразовывать такую рекурсию в цикл (если это действительно так), но получается, что LLVM может оптимизировать не только хвостовую рекурсию, но и другие частные случаи общей рекурсии.
Более того, select count(*) from и select count(field) from вернут разные результаты, если в поле field есть стоки с NULL.
И что эта статья делает на главной?
Хотя бы потому, что при таком времени сильно влияет время запуска рантайма. А на это, в свою очередь, сильно влияет файловый кэш, расположение файлов на диске и т.п. Оказался у тебя Ruby 1.9 в кэше — и всё, «выигрыш».
Не знаю, вполне возможно Ruby 1.9 вновь окажется впереди, если время работы теста увеличить (ну хотя бы до 10 сек! А лучше до минуты). Но этим цифрам доверять нельзя.
Во-вторых, в качестве альтернативы можно сравнивать p<=sqrt(n), а можно p*p<=n, и тут тоже можно придумать всякие оптимизации… ;)
Код не смотрел, но есть такая вещь, как презумпция вменяемости авторов jQuery :)