По поводу производительности Лиспа в вычислительных задачах была интересная статья:

http://http.cs.berkeley.edu/~fateman/papers/lispfloat.ps

Ответ на »сообщение 2547« (Руслан Богатырев)
___________________________

Безусловно летал, но, согласитесь, если хотите быть до конца корректным, Лисп на нелисповой архитектуре (которые мы все у себя имеем) вряд ли способен конкурировать с теми средствами, которые под эту мейнстрим-архитектуру заточены. Приходится подстилку класть. Увы-увы.

Похоже, что моя предыдущая проповедь пропала зря... Если уж так велика потребность поучаствовать в дискуссии, почему бы не ознакомиться с реальным положением вещей, прежде чем производить мегабайты флуда, опровергать который в сотый раз становится просто неинтересно?

Во-первых, софт проекта RAX работал на самом обычном железе (в этой дискуссии уже упоминались и сайт NASA с отчетом об эксперименте, и сайт разработчика системы, Erann Gat --- кому интересно, найдет сам) в среде LispWorks (доработанной, подробности см. там же).

Во-вторых, о "подстилке". Коль скоро здесь не принято самостоятельно изучать предмет спора, прежде чем делать выводы, придется показывать "на пальцах". Берем самую обычную бесплатную версию LispWorks 4.3 и пробуем в ней следующий примерчик:

(defun f (a b)
  (+ (* a b) 3.14))

Набрать его можно прямо в окне listener'а, после чего сделать

(compile 'f)
(disassemble 'f)

В ответ получаем примерно следующее:

2145567A:
      0:      3B25BC150020    cmp  esp, [200015BC]  ; T
      6:      7637            jbe  L2
      8:      80FD02          cmpb  ch, 2
      11:      7532            jne  L2
      13:      55              push  ebp
      14:      89E5            move  ebp, esp
      16:      50              push  eax
      17:      8B4DFC          move  ecx, [ebp-4]
      20:      0A4D08          orb  cl, [ebp+8]
      23:      752B            jne  L3
      25:      8B4508          move  eax, [ebp+8]
      28:      C1F808          sar  eax, 8
      31:      0FAF45FC        imul  eax, [ebp-4]
      35:      701F            jo    L3
L1:  37:      B97C004521      move  ecx, 2145007C    ; 3.14
      42:      0AC8            orb  cl, al
      44:      7523            jne  L4
      46:      89C7            move  edi, eax
      48:      81C77C004521    add  edi, 2145007C    ; 3.14
      54:      7019            jo    L4
      56:      FD              std 
      57:      89F8            move  eax, edi
      59:      C9              leave
      60:      C20400          ret  4
L2:  63:      E8A420BFFE      call  20047762        ; #<function 20047762>
L3:  68:      FF7508          push  [ebp+8]
      71:      8B45FC          move  eax, [ebp-4]
      74:      E879F757FF      call  209D4E42        ; #<function 209D4E42>
      79:      EBD4            jmp  L1
L4:  81:      894508          move  [ebp+8], eax
      84:      B87C004521      move  eax, 2145007C    ; 3.14
      89:      C9              leave
      90:      E991F757FF      jmp  209D4E6A        ; #<function 209D4E6A>
      95:      90              nop 
      96:      90              nop 
      97:      90              nop 

Многовато, если не сказать грубее... Динамическая типизация во всей красе. Однако, все в наших руках. Добавляем такое магическое заклинание:

(defun f (a b)
  (declare (type double-float a b))
  (+ (* a b) 3.14))

Реализация функции становится гораздо приятнее:

20695052:
      0:      3B25BC150020    cmp  esp, [200015BC]  ; T
      6:      7628            jbe  L1
      8:      80FD02          cmpb  ch, 2
      11:      7523            jne  L1
      13:      55              push  ebp
      14:      89E5            move  ebp, esp
      16:      50              push  eax
      17:      FF7508          push  [ebp+8]
      20:      B502            moveb ch, 2
      22:      8B45FC          move  eax, [ebp-4]
      25:      FF1598BA2720    call  [2027BA98]      ; SYSTEM::*$DOUBLE$DOUBLE
      31:      894508          move  [ebp+8], eax
      34:      B502            moveb ch, 2
      36:      B8B4D76720      move  eax, 2067D7B4    ; 3.14
      41:      C9              leave
      42:      FF25D8C52720    jmp  [2027C5D8]      ; SYSTEM::+$DOUBLE$DOUBLE
L1:  48:      E8DB269BFF      call  20047762        ; #<function 20047762>
      53:      90              nop 

Уже гораздо лучше, но можно добиться большего:

(defun f (a b)
  (declare (optimize (speed 3) (safety 0) (debug 0) (space 0) (float 0)))
  (declare (type double-float a b))
  (+ (* a b) 3.14))

Дает нам

20673522:
      0:      55              push  ebp
      1:      89E5            move  ebp, esp
      3:      83EC14          sub  esp, 14
      6:      C7042445140000  move  [esp], 1445
      13:      8B7D08          move  edi, [ebp+8]
      16:      DD4704          fldl  [edi+4]
      19:      DD4004          fldl  [eax+4]
      22:      DEC9            fmulp st(1), st
      24:      DD0590786820    fldl  [20687890]      ; 3.14
      30:      DEC1            faddp st(1), st
      32:      FF75F0          push  [ebp-10]
      35:      FF75EC          push  [ebp-14]
      38:      8B75F4          move  esi, [ebp-C]
      41:      8975EC          move  [ebp-14], esi
      44:      8B75F8          move  esi, [ebp-8]
      47:      8975F0          move  [ebp-10], esi
      50:      8B75FC          move  esi, [ebp-4]
      53:      8975F4          move  [ebp-C], esi
      56:      8B7500          move  esi, [ebp]
      59:      8975F8          move  [ebp-8], esi
      62:      83ED08          sub  ebp, 8
      65:      8B750C          move  esi, [ebp+C]
      68:      897504          move  [ebp+4], esi
      71:      DD5D0C          fstpl [ebp+C]
      74:      C74508450C0000  move  [ebp+8], C45
      81:      B501            moveb ch, 1
      83:      C9              leave
      84:      FF2510671120    jmp  [20116710]      ; SYSTEM::RAW-FAST-BOX-DOUBLE

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

А сейчас --- раскроем страшную тайну. :-) Надежность такого кода, вообще говоря, не выше аналогичного сишного. Но (вот она, тайна!) никто не заставляет писать его вручную. Средствами Лиспа определяется соотв. DSL, который возьмет на себя генерацию всех этих объявлений, и в который никто не мешает включить статическую типизацию, хоть с выводом типов в стиле Haskell (что может оказаться и не нужным --- хорошие Лисп-трансляторы уже включают в себя элементы type inference), хоть с явной типизацией, как в Обероне. Кроме обобщенного контроля типов, которого уже достаточно, чтобы вернуть потерянную надежность, можно добавить столько domain-specific проверок, сколько мы сможем себе вообразить. Добавим к этому возможность domain-specific оптимизаций и адаптивность --- возможность перекомпиляции кода прямо во время его исполнения.

Ответ на »сообщение 2553« (Руслан Богатырев)
___________________________

Где же начнется "просадка"? Уж не на работе ли с динамической памятью?

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

Так может, разговоры о преимуществе на каких-то тестах -- это просто попытка самоуспокоения, а не поиск истины?


ИМХО, любые тесты производительности, кроме профилирования реальных программ в реальных условиях их эксплуатации --- это самообман.

Ответ на »сообщение 2557« (Geniepro)
___________________________

Маклисп был также первой Лисп-системой, для которой создан хороший транслятор. Транслятор генерирует машинную программу, получившую имя LAP (List Assembly Program), в форме списков. Машинный код в виде списков легко обрабатывать и результирующий код для числовых задач получался эффективней, чем у лучших фортрановских трансляторов PDP-10 (Fateman 1973, Steele 1977). Это объясняется "разумностью" маклиспа при обработке выражений и оптимизации кода.

Это объясняется отсутствием в Фортране динамических структур данных (списков).
IMHO, написание оптимизатора на Обероне (и Паскале) ничуть не сложнее, чем на Лиспе.
Что касается Оберона (КП) -- имеется собственный опыт.

Ежели кому интересно, сравнение языков Objective Caml и Standard ML
Два языка одного семейства, но довольно-таки много отличий:

Standard ML and Objective Caml, Side by Side

Comparing Objective Caml and Standard ML

Ответ на »сообщение 2558« (AVC)
___________________________

Это различие постоянно подчеркивается Виртом в разных его статьях. Вот что, например, он пишет в статье "От разработки языка программирования к созданию компьютера":

Прошу прощения за неточность: "От разработки языка программирования к созданию компьютера" -- не статья, а тьюринговская лекция Вирта в 1984 г.

Ответ на »сообщение 2567« (Jack Of Shadows)
___________________________

>>>Поскольку вы в теме, то ждать Руслана нет нужды. Чем Вирт обьяснял решение о невключении перечислимых типов?

Я хотел подождать Руслана, т.к. лично у меня остаются некоторые сомнения.
Но вот объяснение Вирта из статьи "От Modula к Oberon".

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


Т.е. Вирт предвидел некоторые проблемы с перечислимыми типами в будущем.
Вопрос, насколько он был прав, остается открытым.
Иногда Вирт передумывает (например, вернул FOR в Оберон-2); Гуткнехт же включил-таки перечислимые типы в Zonnon.

>>>Про церковь святого Вирта - прошу прощения.

Never mind. :)

Ответ на »сообщение 2564« (Антон Григорьев)
___________________________
И могу совершенно точно сказать, что нехваткой времени у Вирта отсутствие перечислимого типа здесь никто не объяснял.


Поскольку вы в теме, то ждать Руслана нет нужды. Чем Вирт обьяснял решение о невключении перечислимых типов ?

Про церковь святого Вирта - прошу прощения.

Ответ на »сообщение 2565« (AVC)
___________________________
Я тоже следил за этим обсуждением. К сожалению точных слов не помню. Но говорилось о том что Вирт считал перечислимые типы вешью полезной, но внесение их в компилятор сильно усложнило бы его, и привело бы к увеличению обьема работ, на что у него не было рессурсов (желания, времени, команды интерпретируйте как вам угодно.)
Факт остается. Вирт не считал перечислимые типы вредным или ненужным механизмом.

Ответ на »сообщение 2563« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2562« (AVC)
___________________________
А где именно Вирт объясняет исключение перечислимого типа "отсутствием времени"?

Многократно пробегало в обсуждениях оберона. Руслан даст вам точную ссылку.


Ну что же, дождемся Руслана.
Лично я сильно сомневаюсь в такой причине отсутствия перечислимого типа в Обероне.
Во-первых, где-то читал объяснение Вирта, в котором ни слова не было о нехватке времени.
Во-вторых, насколько я понимаю, компилятор Оберона делался на основе уже готового компилятора Модулы-2, где перечислимый тип был.
В-третьих, даже если бы Вирт сдал свой Оберон "с недоделками", то у него (и у Мессенбека) было достаточно времени на внесение соответствующих исправлений в Оберон-2.

Ответ на »сообщение 2563« (Jack Of Shadows)
___________________________

Многократно пробегало в обсуждениях оберона. Руслан даст вам точную ссылку.

Многократно пробегало совсем другое объяснение. Так как перечислимые типы я очень люблю и их отсутствие в Обероне меня не радует, я внимательно следил за всем, что их касается. И могу совершенно точно сказать, что нехваткой времени у Вирта отсутствие перечислимого типа здесь никто не объяснял.

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

Ответ на »сообщение 2562« (AVC)
___________________________
А где именно Вирт объясняет исключение перечислимого типа "отсутствием времени"?

Многократно пробегало в обсуждениях оберона. Руслан даст вам точную ссылку.