LINUX.ORG.RU
Ответ на: комментарий от anonymous

> Я готов Вам поверить. Но абсолютные числа, без сравнения с числами
> для варианта на Си, смысла не имеют.

C:
	Command being timed: "./arr-c"
	User time (seconds): 0.53
	System time (seconds): 0.43
	Percent of CPU this job got: 97%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.99
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 0
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 76928
	Voluntary context switches: 1
	Involuntary context switches: 76
	Swaps: 0
	File system inputs: 0
	File system outputs: 0
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

Т.е. порядка 1-й секунды. Лисп мне, кстати, до 1.6 удалось разогнать
;)

> Возможно, Вы использовали другой вариант программы; 

Нет.

> напутали с коэффициентами; 

Нет.

> не сбрасывали кэш. 

Да это пофиг. 300мб на моей машине в дисковый кэш полностью входит, а
читают обе программы эти данные одинаково, через один sys_read().

> Хотелось бы также взглянуть на загрузку ядер. Вряд ли Лисп
> самостоятельно, через libastral.so распараллеливает вычисления на
> ядра, но тем не менее.

Обе программы на одном ядре выполняются.

> Призываю Вас разобраться в этом. Мне самому интересны объективные
> данные, я вовсе не заинтересован в подтасовке, поэтому и привожу
> исходники и методологию, доступную для каждого.

Вот сишное сложение массива:

  4006b8:       0f b6 04 13             movzbl (%rbx,%rdx,1),%eax
  4006bc:       48 83 c2 01             add    $0x1,%rdx
  4006c0:       48 01 c1                add    %rax,%rcx
  4006c3:       48 81 fa 00 00 c0 12    cmp    $0x12c00000,%rdx
  4006ca:       75 ec                   jne    4006b8 <main+0x68>

Вот лисповое:

;      850: L2:   488BC1           MOV RAX, RCX
;      853:       48C1F803         SAR RAX, 3
;      857:       480FB6440201     MOVZX RAX, BYTE PTR [RDX+RAX+1]
;      85D:       48C1E003         SHL RAX, 3
;      861:       4801C6           ADD RSI, RAX
;      864:       4883C108         ADD RCX, 8
;      868: L3:   4839D9           CMP RCX, RBX
;      86B:       7CE3             JL L2

Видно, что помимо самого сложения и обслуживания цикла есть две
лишних операции. В терминах ir2 sbcl они зовутся MOVE-TO-WORD/FIXNUM
и MOVE-FROM-WORD/FIXNUM. Возникают лишние операции от того, что в
лиспе нельзя напрямую задать тип "число в машинном виде", поэтому
компилятор мучается с вручную объявленным типом fixnum, которому
нужно boxing/unboxing делать. Если решить этот момент (сделать
нормальное выведение типа для функции сложения элементов массива
известного типа), то исчезнет 4-я команда.

Ещё реализация функции map для вектор оперирует с итератором
внутреннего типа index, который на самом деле fixnum. Если
оптимизировать этот момент, то исчезнут первые две команды.

Ещё мне не очень нравится в обоих вариантах использование movzx,
можно использовать add r8, m8 и adc rXX, 0. Но тут нужно сравнить оба
варианта, т.к. на интеловской архитектуре команды очень странно
работают.

А по вашему странному графику могу сказать, что в измерении есть
ошибка. Характер графика должен быть, как на графике с потреблением
памяти.

mv ★★★★★
()
Ответ на: комментарий от mv

> Т.е. порядка 1-й секунды. Лисп мне, кстати, до 1.6 удалось разогнать ;)

Ну то есть Лисп в 1.6 раз медленнее Си, или что?

tailgunner ★★★★★
() автор топика
Ответ на: комментарий от r

>> Ну то есть Лисп в 1.6 раз медленнее Си, или что?

> Если так - то это фигня.

Ну это для явапрогеров фигня. Или если данная программа пускается раз в <редко>. А если это фильтр в системе ~РВ, это не фигня ни разу.

tailgunner ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

>Ну это для явапрогеров фигня. Или если данная программа пускается раз в <редко>. А если это фильтр в системе ~РВ, это не фигня ни разу.

Хорошо - фигня кроме специфичных случаев где данная скорость - важнейший показатель.

r ★★★★★
()
Ответ на: комментарий от tailgunner

> А если это фильтр в системе ~РВ, это не фигня ни разу.

Если это фильтр, то его на ассемблере с использованием sse напишут. Если уж совсем всё так плохо :)

mv ★★★★★
()
Ответ на: комментарий от tailgunner

> Вы меня таки заставите поставить SBCL, волке :/

Ставь x86-64. Обычный x86 хуже (регистров мало, gc хуже, fp через fpu, а не sse2, модных фишек типа relative addressing нет).

mv ★★★★★
()
Ответ на: комментарий от mv

> А по вашему странному графику могу сказать, что в измерении есть ошибка. Характер графика должен быть, как на графике с потреблением памяти.

Ну, тут я загнул, т.к. память выделяется в таком же количестве (с тем же коэффициентом), плюс константный размер рантайма, а вот сама обработка данных медленнее :) Поэтому кривые на графике будут расходится, но не с таким диким коэффициентом.

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.