Здравствуйте, VladD2, Вы писали:

VD>Портировали бы тесты производительности с нашего сайта (шутриков) под Окамл. Поглядели бы на реальный расклад сил на сегодня.

Сегодня за 15 минут для интересу написал на Окамле две программки, реализующие StringTest из набора с этого сайта. Из ваших тестов запускал только gcc, поскольку он у меня сразу запустился (пришлось, правда, добавить #include <malloc.h> и сделать using для cerr, cout, cin и endl.) Программки две, одна более императивная, с использованием string-buildera (здесь он называется Buffer), другая — более функциональная, со злополучной рекурсией (лень было лезть в документацию выяснять, как называется аналог той функции, которая у меня называется repeat_n_times) и с обычными строками. Сами программы приведены ниже, пока что результаты:

GCC           33.89
OCaml имп.    20.49
OCaml функ.   31.72

Время в секундах, машинка у меня слабая. Вот программы:

Первая:

let s = Sys.time();;
let n = 10000000;;
let ss = Buffer.create 0;;
let _ = 
for i = 1 to n do begin
   Buffer.reset ss;
   Buffer.add_string ss ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>";
   Buffer.add_string ss "Мама ";
   Buffer.add_string ss "мыла ";
   Buffer.add_string ss "раму";
   Buffer.add_string ss "\n"
 end
 done;
Printf.printf "%f\n" ( Sys.time() -. s);;

Вторая:

let s = Sys.time();;
let n = 10000000;;

let func s = 
   let ss = s in
   let ss1 = ss ^ ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>" in
   let ss2 = ss1 ^ "Мама " in
   let ss3 = ss2 ^ "мыла " in
   let ss4 = ss3 ^ "раму" in
   let ss5 = ss4 ^ "\n" in
   ss5;;

let rec repeat_n_times n f s = 
    if n = 0 then () else begin f(s); repeat_n_times (n - 1) f s end;;

let _ = repeat_n_times n func "";
Printf.printf "%f\n" ( Sys.time() -. s);;

На ОКамле я и вообще писал мало, и последний раз делал это больше года назад, поэтому программы выглядят, возможно, не идеально.

Dear INTP_mihoshi,


N_>> Вы очень ограничено мыслите.

INT>Зачем же, сразу "ограничено"

спасибо за поддержку

Ц>>>Как на ФЯ изменить состояние объекта
Ц>>>послать/принять сигнал
Ц>>>послать каждому объекту(произвольного типа) из списка

INT>В классическом ФЯ (например, Haskell) Все, действительно, так и происходит. Крутиться "на самом верху" цикл, в котором видны все глобальные переменные. Он занимается вводом-выводом и рулит всеми состояниями.

INT>В казуальных ФЯ, например, в *ML, есть mutable значения, которые являются аналогом обычных переменных.

Чисто теоретический вопрос.

Предположим, что я пишу десктоп на ФЯ ( имею право )
Как на Хаскеле и др. будет выглядеть сигнальная система ( окна, колбэки, сообщения )
Не додумаюсь ...
Но очень хочется взглянуть

На OCalm'e видел Web — пример, что ты или Gaperton посылали
почти понятно, но все же, что конкретно ...

Как это( + сигналы), к примеру, на Хаскеле ( можно ли ), Erlang'e ?

Здравствуйте, INTP_mihoshi, Вы писали:
INT>Имху Erlang по сфере применения — удачный функциональный Python
Не соглашусь, они разные. На Python не получится хорошо сделать то, что выходит на Erlang, и наоборот. Например, Python очень любят встраивать в приложения, как скриптовый язык, что с Erlang вообще не получится сделать, да и неудобен он будет. Ну, и хотел-бы я посмотреть на производительность Web-сервера, написанного на Python. Вот например, Yaws, написаный на Erlang-e по производительности в пиковых режимах легко обходит Apache (ссылку на тесты уже я давал).

Или такая задача. Делаем кластер из 100 машин, на каждой запускаем по процессу, которые объединяются в кольцо. После чего выключаем 10% машин, и смотрим, насколько быстро наши процессы восстановят кольцо. Сомневаюсь, что Python удобен для таких задач.

Ну, а если, с другой стороны, кто решит написать складской учет на Erlang, это будет номер (кстати, надо будет смеху ради попробовать). А на питоне — вроде как и нормально.

G>>Ни то ни другое не подходит для написания десктопных приложений, и удобными универсальными языками не являются. Универсален, выразителен и красив у нас Haskell. Но уж больно паршивый у него компилятор. Он, во-первых медленный. Во-вторых, производительность программ немного не та, что можно ожидать от статически типизированного языка.
INT>У меня большое подозрение, что медлительноость — плата за мощную систему типов Классы типов, полиморфизм по типам и Nil в каждом типе — удобно, стильно, но, видимо, дорого...
К счастью, это вряд ли. Clean-у это не сильно мешает выполняться быстро — а у него система типов очень близка к Хаскелю. От Хаскеля он отличается редким использованием монад (вместо них используется uniqueness typing, где это возможно). А в Хаскеле (речь идет о GHC) они похоже пока не научились эффективно компилировать монады (и неудивительно — это сплошные функции высокого порядка). Отсюда и медленный ввод-вывод, и медленные массивы. И вообще, везде где есть монады — медленно. Я недавно читал статью на эту тему. Там говорилось, что это в принципе возможно, для тех монад, о существовании которых компилятор будет знать. И предлагалась техника.

G>>Ну, а дальше — остается OCaml. Язык универсален, хуже чем с императивными языками не будет точно, так как он еще и императивный. Быстрый, функциональный, позволяющий вести разработку с минимальным риском. Будте уверены, производительности — хватит. А начет не хватать — всегда можно оптимизнуть. Одна беда. У меня пока аллергия на синтаксис OCaml, но это дело привычки.

INT>Не у одного тебя К счастью, в OCaml и синтаксис можно выбирать.
INT>здесь

The revised syntax is an alternative syntax for OCaml. Its purposes are 1/ fix some problems of the normal syntax (unclosed constructions sometimes introducing ambiguities, constructors arity, end of top level phrases and structure items, etc) 2/ avoid unjustified double constructions (":=" vs ``<-'', ``fun'' vs ``function'', ``begin..end'' vs parentheses) or concepts (types and types declarations) 3/ bring some ideas (lists, types). In a word, propose a syntax which be more logical, simpler, more consistent and easier to parse and to pretty print.
...
It is a syntax of the complete language, therefore it can be used for all OCaml programs: by the way, Camlp4 is itself completely written in that syntax. Notice that it is not a constraint: it is always possible to convert from and to the normal syntax, using the pretty print facilities of Camlp4.

Лучше так.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>Имху Erlang по сфере применения — удачный функциональный Python
G>Не соглашусь, они разные. На Python не получится хорошо сделать то, что выходит на Erlang, и наоборот. Например, Python очень любят встраивать в приложения, как скриптовый язык, что с Erlang вообще не получится сделать, да и неудобен он будет. Ну, и хотел-бы я посмотреть на производительность Web-сервера, написанного на Python. Вот например, Yaws, написаный на Erlang-e по производительности в пиковых режимах легко обходит Apache (ссылку на тесты уже я давал).


Может не в тему, но как же Zope?
Куда ещё "питонистей"?

Здравствуйте, Цунцуяби, Вы писали:

Ц>Чисто теоретический вопрос.

Ц>Предположим, что я пишу десктоп на ФЯ ( имею право )
Ц>Как на Хаскеле и др. будет выглядеть сигнальная система ( окна, колбэки, сообщения )
Ц>Не додумаюсь ...
Ц>Но очень хочется взглянуть

Ц>На OCalm'e видел Web — пример, что ты или Gaperton посылали
Ц>почти понятно, но все же, что конкретно ...

Ц>Как это( + сигналы), к примеру, на Хаскеле ( можно ли ), Erlang'e ?

В Haskelle можно посмотреть соответсвующие библиотеки на www.haskell.org. Например, Fudgets или FranTk. Что касается теории, то искать в гугле по словам functional reactive animation.

Erlang, вообще-то, не предназначен для создания графических интерфейсов. Это возможно, даже в дистрибутив включено приложение gs, позволяющее строить GUI, но не следует ожидать слишком многого. Следует учитывать, что Erlang не является чистым ФЯ, в нем возможны побочные эффекты функций. А понятие "сообщений" вообще встроено в язык. Словом, www.erlang.org

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Gaperton, Вы писали:

G>>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>>Имху Erlang по сфере применения — удачный функциональный Python
G>>Не соглашусь, они разные. На Python не получится хорошо сделать то, что выходит на Erlang, и наоборот. Например, Python очень любят встраивать в приложения, как скриптовый язык, что с Erlang вообще не получится сделать, да и неудобен он будет. Ну, и хотел-бы я посмотреть на производительность Web-сервера, написанного на Python. Вот например, Yaws, написаный на Erlang-e по производительности в пиковых режимах легко обходит Apache (ссылку на тесты уже я давал).

К>Может не в тему, но как же Zope?
К>Куда ещё "питонистей"?
В тему . Как он будет работать при 20000 одновременных соединений? У Yaws производительность остается постоянной после достижения максимума (при росте количества запросов), а у Apache сначала падает, а потом он вообще перестает работать. На 20000 тыщах он не работает вообще.

Здравствуйте, Цунцуяби, Вы писали:

Ц>Чисто теоретический вопрос.

Ц>Предположим, что я пишу десктоп на ФЯ ( имею право )
Ц>Как на Хаскеле и др. будет выглядеть сигнальная система ( окна, колбэки, сообщения )
Ц>Не додумаюсь ...
Ц>Но очень хочется взглянуть

Выглядеть будет так, как ты хочешь

Для Камла есть биндинг Tcl (и, кстати, OpenGL, если нужно)

Вот пример простейшей программы на labltk.
Взят здесь
Если будешь компилить — понадобятся довольно редкая ныне версия Tcl8.3 (сейчас проще найти 8.0 и 8.4)
Взять ее можно тут

open Camltk;;

let hello_quit () =
  let main_window = openTk () in
  let bouton_quit =
    Button.create main_window
      [Text "Quit"; Command closeTk] in     (* Делаем кнопку с текстом Quit, по нажатии выполняем closeTk*)
  let bouton_press = Button.create main_window [] in
  let rec action_press () =
    Button.configure bouton_press
      [Text "Hello!"; Command press_init]
  and press_init () =
    Button.configure bouton_press
      [Text "Press"; Command action_press] in 
(* Вторая кнопка переключает свой текст по нажатию между Hello! и Press*)
  press_init ();
  pack [bouton_press; bouton_quit] [Side Side_Left];
  mainLoop ();;

if !Sys.interactive then () else begin hello_quit(); exit 0 end;;

Смысл текста вроде [Text "Press"; Command action_press] такой: [ ; ; ] — это список. Слова с большой буквы — конструкторы значений. В данном случае функции Button.configure передается список действий, которые нужно сделать с кнопкой — Text меняет текст, а Command задает действие по нажатию.

Вот пример "сигналов" с параметром

let rafraîchir_couleur x = ...
...
Scale.configure vert [ScaleCommand rafraîchir_couleur]

ScaleCommand — что нужно делать при движении слайдера. В данном случае выполняется функция одного аргумента rafraîchir_couleur с переданным параметром.


Ц>Как это( + сигналы), к примеру, на Хаскеле ( можно ли ), Erlang'e ?
На Хаскелле все сложнее, но как-то выкручиваются Про Erlang не в курсе.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:
G>>Почему никто не использует функциональные языки

S>

S>На самом деле их никто не использует только потому, что в RSDN Mag до сих пор нет ни одной статьи на их тему. Я уверен, что как только выйдет хорошая статья с практическим примером того, как современная популярная прикладная задача на раз-два-три решается на функциональном языке, прикладники потянутся в эту сторону. Грамотный маркетинг — основа успеха.

Напоминает "Поездку в Америку", тот эпизод, где папаша объясняет Эдди Мерфи — чем его Мак Дуглас отличается от Мак Дональдса...

Здравствуйте, Цунцуяби, Вы писали:

Ц>Как это( + сигналы), к примеру, на Хаскеле ( можно ли ), Erlang'e ?

wait_for_onhook() ->
    receive %% блокирующий прием сообщения
        onhook -> 
            disconnect(),
            idle();
        {connect, B} ->
            B ! {busy, self()}, %% отправка сообщения процессу с ID = B
            wait_for_onhook(); %% повторить.
    after %% выход через 60 секунд со времени получения последнего сообщения.
        60000 ->
            disconnect(),
            error()
    end.

Запускаем процесс, посылаем ему сообщение.
Server = spawn( fun wait_for_onhook/0 ),
Server ! { connect, self() },
receive { busy, _ } -> uuugh end.

Здравствуйте, faulx, Вы писали:

А что у тебя за машина?

ЗЫ

Может переведель остальные тесты чтобы было комплексное сравнение? А то строковый тест больно сильно зависит от качества стринг-билдера (т.п. от алгоритма). Да и вообще нужен комплекстый взгляд. Синтетические тесты (сравнение скорости вызовов) можно опустить, так как смысла в них нет. Многие компиляторы просто выбрасывают такие вызовы.

Здравствуйте, Gaperton, Вы писали:

G>Ну, а дальше — остается OCaml. Язык универсален, хуже чем с императивными языками не будет точно, так как он еще и императивный. Быстрый, функциональный, позволяющий вести разработку с минимальным риском. Будте уверены, производительности — хватит. А начет не хватать — всегда можно оптимизнуть. Одна беда. У меня пока аллергия на синтаксис OCaml, но это дело привычки. Есть отчеты о завершенных проектах на OCaml (как для Erlang) — шлите ссылки. Интересно.

Если я ничего не путаю, то есть вот что:
http://www.mldonkey.org/
A OCAML client for multiple peer-to-peer networks

From: faulx
>переводил я. Лежит здесь:http://kchri.narod.ru/lecs.pdf

Самое то. Большое человеческое СПАСИБО.

Покритикую уж заодно, по мелочи
— на 9стр. ?u.u v ?> ?w.w v.
— от чего свободны и с чем связаны переменные, как не понимал, так и не понял. Почему их так назвали...
— вот эта "?", забыл как произносится. Очень неудобно, бывает, читать математику вроде "| x :: y" думая про-себя: "Ррр-аз, икс! Опа, игрек!".

Здравствуйте, fddima, Вы писали:

F> Возьми лисп — функциональный? Обработай на нем список без рекурсии пожалуйста... и после этого можно будет говорить о какой-либо эффективности. Приведенный мною примерчик — это вывод который делают практически все студенты реализовав одно и то же задание на "3" строчки на си и на лиспе При чем на лиспе это все выглядит гораздо неуклюже.

Это от незнания. На лиспе есть функции высшего порядка, применяющие другие функции к спискам.

А на том же С/С++ родить что-то с использованием алгоритмов STL — хотя бы for_each — тоже непосильно с непривычки.
Вот и тянутся руки к старому доброму for(...;...;...)

F> И потом я вообще не вижу разницы... я под подобным языком вижу исполняющее нутро которое по сути является императивным, но так устроено, что на нем нельзя писать императивным спсобом Короче сплошные ограничения Я конечно понимаю... закостенелось мышления, но все таки...

Сначала люди в течение десятков лет привыкали — переходили от математического образа мышления к алгоритмическому. А здесь требуется обратно перепривыкать.
Но если в первом случае ими двигала безысходность (фон-неймановская архитектура), то во втором безысходности нет. А человек — он как ёж, птица гордая. Не пнёшь — не полетит.

Здравствуйте, Цунцуяби, Вы писали:

Ц>Dear Gaperton,

Ц>Как на ФЯ изменить состояние объекта
Если писать в функциональном стиле — нельзя. Состояние объекта не меняется, он всегда пересоздается заново (или по крайней мере семантика такая).

Пример. Интерфейс очереди.

put_element( Queue, Element ) -> QueueWithElement.
get_element( QueueWithElement ) -> { QueueWithoutElement, Element }.

Обратите внимание — всегда возвращается новый объект. Функциональные структуры данных обладают свойством "транзакционности" (Окасаки). Т. е. если остался еще один "указатель" на старую структуру данных, то он всегда будет на нее указывать. Таким образом, побочные эффекты отсутствуют, что ведет к большей надежности программ (и потенциально — к меньшей производительности).

Queue1 = queue:new(),
Queue2 = queue:put( Element, Queue1 ).

Queue1 — пустая. Queue2 — содержит Element.

Ц>послать/принять сигнал
ProcessID ! AnyObjectOrStructureYouWant

receive
pattern1 -> result;
...
patternN -> result;
end.

Паттерн — запись аналогичная конструктору объекта. Пример:
[ X | List ] — добавляет Х к списку List и возвращает новый список. Но!
[ Head | Tail ] = List Разделяет список List на первый элемент Head и остальную часть Tail.
{ A, B, C } — создает tuple из трех элементов
{ A, B, C } = Z разделяет tuple Z на составляющие, позволяя получить доступ к элементам.

Ц>послать каждому объекту(произвольного типа) из списка
На Хаскеле это делается через type classes. В эрланге таких вещей нет (хотя реализовать похожее поведение можно). Один из вариантов:

process( [ H | T ] ) where is_integer( H ) -> ...
process( [ { tuple1, Value } | T ] ) -> ...

Функция process полиморфна по типам элементов списка. Применяется pattern matching.

Здравствуйте, Кодт, Вы писали:

К>Это от незнания. На лиспе есть функции высшего порядка, применяющие другие функции к спискам.
Есть. Но как они реализованы? Ведь стандартных функций нам по большому счету не хватит

К>А на том же С/С++ родить что-то с использованием алгоритмов STL — хотя бы for_each — тоже непосильно с непривычки.
К>Вот и тянутся руки к старому доброму for(...;...;...)
Угу... хотя применение for_each и классического for зависит от того, нужен ли нам итератор как отдельное целое, или не нужен. Разумеется если есть выбор. for each красивше записывается, а внутри все тот же итератор...

К>Сначала люди в течение десятков лет привыкали — переходили от математического образа мышления к алгоритмическому. А здесь требуется обратно перепривыкать.
Ну здесь требуется... а требуется ли вообще этот еще тот вопрос для грандиозного флейма не так ли?

К>Но если в первом случае ими двигала безысходность (фон-неймановская архитектура), то во втором безысходности нет. А человек — он как ёж, птица гордая. Не пнёшь — не полетит.
Мда... это уж точно... как ежик порою даже в тумане даже если пнешь — летит куда-то хрен знает куда %)

Здравствуйте, ON, Вы писали:

ON>From: faulx
>>переводил я. Лежит здесь:http://kchri.narod.ru/lecs.pdf

ON>Самое то. Большое человеческое СПАСИБО.

ON>Покритикую уж заодно, по мелочи
ON>- на 9стр. ?u.u v ?> ?w.w v.
Ну конечно, \lambda w.w v. Опечатка. Вообще, практически вся теория по лямбда-исчислению просто переведена с Харрисона, ссылку на оригинал я давал. Можно в спорных случаях обращаться туда.

ON>- от чего свободны и с чем связаны переменные, как не понимал, так и не понял. Почему их так назвали...

Название такое. Перевод bounded и free variables. Может, воспринимать связанные переменные, как локальные?

ON>- вот эта "?", забыл как произносится. Очень неудобно, бывает, читать математику вроде "| x :: y" думая про-себя: "Ррр-аз, икс! Опа, игрек!".

Этого замечания не понял. Если можно, поподробнее.

Вообще, спасибо за критику. Перевод, повторяю, корявый, делал для себя, чтобы читать по нему лекции студентам. К этому курсу еще прилагаются шесть лабораторных, в них даются основы Haskell-а. Если интересует, тоже могу выложить.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, faulx, Вы писали:

VD>А что у тебя за машина?

Пентиум 3, 450 мгц, 256 мб.

VD>ЗЫ

VD>Может переведель остальные тесты чтобы было комплексное сравнение? А то строковый тест больно сильно зависит от качества стринг-билдера (т.п. от алгоритма). Да и вообще нужен комплекстый взгляд. Синтетические тесты (сравнение скорости вызовов) можно опустить, так как смысла в них нет. Многие компиляторы просто выбрасывают такие вызовы.

Честно говоря, лень. Может, сделаю со временем. Я же говорю, на ОКамле давно не писал, вспоминается со скрипом. Вот эта ссылка, надеюсь, знакома? Там тестов гораздо больше, и языков тоже.

AF> А это другая крайность. Крайности, как известно, вредны
AF> Как вредно писать только на C/C++/C# или Haskell, так я думаю ещё вреднее — изучать каждыя язык — просто времени на написание кода не отсанется.
Как и Вы, я не сторонник крайних мер и не призываю к изучению языков в ущерб работе. Тем не менее, думаю, полезно периодически вытаскивать голову из своей ниши и смотреть, что же нового появилось вокруг. В книге "Pragmatic Programmer" авторы рекомендуют изучать новый язык каждые полгода. Возможно, это чересчур, но рациональное зерно в этом есть .

Как самый простой пример из собственного опыта: в бытность студентом мне часто приходилось писать утилиты по обработке текста. Я писал из на С++, считая, что лучше языка в природе нет. Сейчас я бы выбрал для этих задач, например, Ruby. На нем мои тогдашние задачи решаются на порядок быстрее.

А вообще-то, мне кажется, серьезному программисту следует достаточно хорошо ориентироваться в различных подходах/парадигмах программирования. Даже если программист выбрал для себя объектный подход раз и навсегда, это не значит, что он имеет моральное право недоуменно пучить глаза при словах "функциональное программирование". В конце концов, расширение кругозора в большинстве случаев себя оправдывает .

AF> Это слова увлечённого программста (и совершенно прекрасные как для специалиста), а не менеджера или инвестора, который реально реализует промышленные проекты. Посмотри на всякие переходы туда — сюда ИХ глазами. Представь — что ты бы платил за подобные развлечения свои деньги, а не какого то дяди.
Опять же, я не говорю о необоснованном выборе языка. Представляя себя на месте инвестора или менеджера, я бы, думаю, голосовал бы за самое эффективное средство разработки. Именно потому, что мне дороги мои деньги. BTW, и не обвиняйте меня в наивности, а правда ли, что это задача менеджера — выбирать средство разработки?

AF> Причём таки переходят же. Иначе никаких ФЯ в телекоме не было бы. Просто на практике всё чуть сложнее, чем прочитать описание языка и написать пару программ.
Мне нравятся такие тенденции . Возможно, они выведут нас из того застоя, в котором находится software индустрия

Здравствуйте, mister-AK, Вы писали:

MA>но был у меня один предмет в ВУЗе — там триггеры изучали... так вот, что-то спор между императивным подходом и функциональным уж очень мне напоминает спор между описанием модели работы автомата (триггера) конечный он или бесконечный, Милли или Мура, не важно.. НО тем не менее двумя вариантами — статической формулой (что соответствует концепции ФЯ) или системой динамических формул (что соответствует концепции ИЯ) Как говорилось профемморами — последнее намного прощще, так как представляет собой как раз ту модель мира, в которой мы живем, т.е. учитывает чудодейтвенное присутствие времени а над первой моделью какой-нить попавшейся сложной системы из этих автоматов можно биться и биться до изнеможения, но добиться умопомрачительной компактности её представления на все века вперед — а вот в результате всё зависит от того, случится ли менять систему когда-нить... ведь всё течет, всё меняется.

Протяжённость времени и пространства — это иллюзия, хотя и чрезвычайно навязчивая.
Уравнение Шрёдингера сворачивает присутствие времени и пространства из "оттуда-туда" в единомоментное "всегда-и-везде" чудодейственно равное "здесь-и-сейчас"...

Здравствуйте, faulx, Вы писали:

F>Пентиум 3, 450 мгц, 256 мб.

Понятно. Тогда gcc у тебя еще быстро сработал. Видимо библиотека std чуть другая.

F>Честно говоря, лень. Может, сделаю со временем. Я же говорю, на ОКамле давно не писал, вспоминается со скрипом. Вот эта ссылка, надеюсь, знакома? Там тестов гораздо больше, и языков тоже.

Знакома. Там вообще чушь какая-то. Используются разные алгоритмы. Время меряется не участка кода, а всего приложения (утилитой).