История изменений
Исправление den73, (текущая версия) :
Достаточно того, что я у тебя нашёл двоемыслие. А именно, «улучшения производительности быть не может, за исключением одного примера». Ты же инженер, и должен понимать, что один контрпример ломает всю теорию. А у тебя получается «немножко беременна».
Когда я тебе говорю про инлайн, который в лиспе невозможен из-за отсутствия инфы о типах, ты говоришь мне про .Net, где его тоже, по твоим словам нет. А почему не про C++, где он есть? Стрёмно что ли с С++ сравнить? Далее ты выходишь на общие слова об умных указателях и заканчиваешь тем, что у тебя длиннее:
Я, в отличие от тебя...
Извини, это всё в сумме не выглядит убедительным ну никак, скорее выглядит так, что внутренне ты понимаешь, что CL тормозной, но боишься это осознать.
Но есть GC, с поколениями, и так далее.
Чтобы немного узнать о (негативном) влиянии GC на производительность хеш-таблиц в SBCL, изучи описание поля needs-rehash-p в хеш-таблице, и найди, где и как это поле используется. Здесь была тема несколько лет назад, где я это откопал и про это написал, но сейчас искать её лень.
И ещё одно, мне просто стыдно за вас с no-such-file, что вам надо такое объяснять. Ты хранишь в хеше, допустим, буквы. Достаёшь значение по ключу и записываешь в переменную типа «буква». При динамической типизации компилятор вставит проверку при присваивании, которую можно убрать только с помощью Safety 0. При статической проверка не нужна. Уж куда очевиднее, казалось бы? Но для вас и этого не существует. Пипец просто какой-то!
И это касается любых типизированных контейнеров, в т.ч. и массивов, для которых, кстати, есть такая прелесть, как upgraded-array-element-type - т.е. в плохих случаях даже для массива проверка типа в рантайме неустранима. В частности,
(upgraded-array-element-type 'cons)
T
То же касается заполнения хеш-таблицы.
Если кто-то говорит, что лисп «high performance», то все приведённые вещи являются однозначной целью для оптимизации, и если ты посмотришь в SBCL, то увидишь, что там повсеместно за такие оптимизации борются, повсеместно и агрессивно используют вывод типов и inline, выкидывают как можно больше веток в typecase статике. Т.е. то самое «дрочево на микрооптимизации», только его делает сам компилятор. И ты не хуже меня знаешь, что все примеры на «computer benchmark game» построены на статической типизации, и если её выкинуть, то производительность сразу грандиозно просядет. Ну вот что за детский сад тут происходит, вроде взрослые, опытные, компетентные люди, а такую хрень несёте!
И самое главное - ты написал свой видео-стриминг на дотнете, а не на CL. Что как раз лучше всего говорит о плачевном состоянии лиспового мира. Не смог продвинуть лисп заказчику-работдателю, да.
Исходная версия den73, :
Достаточно того, что я у тебя нашёл двоемыслие. А именно, «улучшения производительности быть не может, за исключением одного примера». Ты же инженер, и должен понимать, что один контрпример ломает всю теорию. А у тебя получается «немножко беременна».
Когда я тебе говорю про инлайн, который в лиспе невозможен из-за отсутствия инфы о типах, ты говоришь мне про .Net, где его тоже, по твоим словам нет. А почему не про C++, где он есть? Стрёмно что ли с С++ сравнить? Далее ты выходишь на общие слова об умных указателях и заканчиваешь тем, что у тебя длиннее:
Я, в отличие от тебя...
Извини, это всё в сумме не выглядит убедительным ну никак, скорее выглядит так, что внутренне ты понимаешь, что CL тормозной, но боишься это осознать.
Но есть GC, с поколениями, и так далее.
Чтобы немного узнать о (негативном) влиянии GC на производительность хеш-таблиц в SBCL, изучи описание поля needs-rehash-p в хеш-таблице лиспа, и найди, где и как это поле используется. Здесь была тема несколько лет назад, где я это откопал и про это написал, но сейчас искать её лень.
И ещё одно, мне просто стыдно за вас с no-such-file, что вам надо такое объяснять. Ты хранишь в хеше, допустим, буквы. Достаёшь значение по ключу и записываешь в переменную типа «буква». При динамической типизации компилятор вставит проверку при присваивании, которую можно убрать только с помощью Safety 0. При статической проверка не нужна. Уж куда очевиднее, казалось бы? Но для вас и этого не существует. Пипец просто какой-то!
И это касается любых типизированных контейнеров, в т.ч. и массивов, для которых, кстати, есть такая прелесть, как upgraded-array-element-type - т.е. в плохих случаях даже для массива проверка типа в рантайме неустранима. В частности,
(upgraded-array-element-type 'cons)
T
То же касается заполнения хеш-таблицы.
Если кто-то говорит, что лисп «high performance», то все приведённые вещи являются однозначной целью для оптимизации, и если ты посмотришь в SBCL, то увидишь, что там повсеместно за такие оптимизации борются, повсеместно и агрессивно используют вывод типов и inline, выкидывают как можно больше веток в typecase статике. Т.е. то самое «дрочево на микрооптимизации», только его делает сам компилятор. И ты не хуже меня знаешь, что все примеры на «computer benchmark game» построены на статической типизации, и если её выкинуть, то производительность сразу грандиозно просядет. Ну вот что за детский сад тут происходит, вроде взрослые, опытные, компетентные люди, а такую хрень несёте!
И самое главное - ты написал свой видео-стриминг на дотнете, а не на CL. Что как раз лучше всего говорит о плачевном состоянии лиспового мира. Не смог продвинуть лисп заказчику-работдателю, да.