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

_>Только т.к. в этих языках это является мелкими дополнениями вокруг главного ядра uml, то в Хаскеле мы соответственно только эту обёртку и получим, без всей мощи ядра.

Не понятно, что это за невостребованное ядро.
Диаграмма классов это:
1) а) Группировка для функций/методов с делением на публичные и приватные. Востребована она в хаскеле? Да. Функции на приватные/публичные делятся? Да.
б) Стереотипы для классификации таких групп. обычные классы/интерфейсы/статические классы/модули/классы типов/рекорды и т.д. Востребовано это в хаскеле? Да.
2) Отношения между этими группами функций вроде наследования, аггрегации, имплементации и т.д.
Востребовано это в хаскеле? Конечно. К примеру между классами типов отношение наследования, а между инстансами и классами типов — отношение имплементации.
Всего хватает, "ядро" используется в полном объеме. Что не так-то?

_>И это ещё речь только про одну (пусть и главную) структурную диаграмму, а у главных диаграмм поведение с Хаскелем вообще нет шансов (ну это мы уже обсудили, я просто напоминаю, а то вы же не уточняете выше, что говорите только про диаграмму классов).

И активити и сиквенс-диаграммы с хаскелем использовать конечно можно. Я просто не вижу особого смысла в использовании аквтивити диаграмм — псевдокод для этого куда лучше, что мы и обсуждали.

_>>>Ну так тогда вас не затруднит кинуть ссылку на конкретное сообщение ваше сообщение? )
K>>Ну вот об этом я и говорю. Ведь мы же эти преобразования буквально в предыдущем посте обсуждали.
K>>http://rsdn.ru/forum/philosophy/5624883.1

Автор: Klapaucius
Дата: 29.05.14

_>Так это вы про map p.q говорили?

Нет, я говорил о преобразовании конвейера из all / map / takeWhile и т.д. в цикл, и вообще класс преобразований из последовательных проходов в один проход. Без контроля эффектов эти преобразования в общем случае некорректны.

_>Это как-то доказывает теоретическую невозможность повторения всех возможностей Хаскеля, но без обязательности ограничений (и соответственно без синтаксического пенальти)?

Это не доказывает невозможность, но показывает, что никаких оснований говорить о повторении всех возможностей которые дает контроль эффектов а ля хаскель пока нет.

K>>Это только та часть не осознает, которая конвейеры не использует.
_>Конвейеры очень разные бывают...

Это точно, те, кто использует только вырожденные конвейеры из 0 и 1-ой стадии — тоже не осознают.

K>>Да можно и при 10% равной считать.
_>Тогда к чему разговор о "страшной" погрешности измерения в 2% и обоснование этим усреднения результатов, вместо выборки минимального?

Не знаю, к чему этот разговор. Если мы сравниваем числа сравнимые с погрешностью измерений, значит их нужно статистически обрабатывать, а не просто "брать минимальные" — вот и все.
Никаких выводов на том, что этот подход неправильный я, в отличие от вас, не строю.
Никаких выводов на разнице в 10% я тоже не строю, моя цель была опровергнуть утверждение про какие-то "отличия в разы", так что для меня и 30% разница не принципиальна. Особенно если учитывать, что речь идет о нерелевантных примерах, не имеющих никакого отношения к поддержке иммутабельности.

_>В D int равен 32 битам.

Ну вот, т.е. разница будет уже за счет того, что в одном случае (D) int32, а в другом (хаскель) int64

_>И дело не только в регистрах, а просто в том что разные алгоритмы используются (с разной степенью вылизанности).

Бывает, конечно, что компиляторы для 32 и 64 вообще разные проекты вроде CLR-ного JIT, но GHC это не касается. Там вообще какой-то особенной "вылизанности" в кодогенераторе нет.

_>Так 32 битный код имеет пенальти на 64 битной системе.

Предположу, что оно незначительно в нашем случае.

_> тем более если задача такова, что 32 битный код может оказаться абсолютным лидером в сравнение.

Если учесть, что x64 версия отвечающая условиям задачи выделяет примерно в два раза больше памяти, не сложно предположить, что работает дольше.

_>Зато поработав с ним сразу ощущается что такое настоящий высокий уровень... )

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

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

_>Я не очень понимаю смысл в гонке виртуальных гигабайтов.

В моем примере они не виртуальные. Это самые обычные аллокации, сделанные стандартным аллокатором. Вы же предлагаете считать каждое изменение на месте новым размещением всего массива. Тут "аллокации" будут, конечно, виртуальными.

_>Я не про нагрузку на память, а про принципиальный факт использования иммутабельных объектов. А то ведь вы помнится и с этим спорили...

"Принципиальный факт" заключается в том, что объект, ссылающийся на изменяемый массив, иммутабельным не является. Хотя конструирование миллиона таких объектов действительно от конструирования миллиона иммутабельных отличаться по производительности не будет.

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

DM>И в исходном вызове передавать честные лямбды или иные функции. Это передача по имени, незаслуженно забытая многими языками.

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

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

S>Простите, я потерял нить. Что такое "клиентские js шаблоны"?

Ну например те же самые angular шаблоны. Собственно это просто html страницы без данных и скриптов. И соответственно они отлично генерируются серверными шаблонизаторами, заточенными под создание html. Более того, такие шаблонизаторы (jade и т.п.) частенько применяют и в случае отдачи клиентских шаблонов как файлов, просто тогда это происходит на компьютере разработчика и предназначено для удобства разработки.

S>Вы поймите, что для статики уже написаны правила и код, которые очень хорошо работают из коробки. Если вы пишете хэндлер, который отдаёт статический файл "вручную", то вам придётся сильно нагнуться для того, чтобы достичь производительности nginx или lighttpd.

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

S>А что такое "обычным образом"? Он рассчитан на встраивание в инфраструктуру IIS или на самостоятельную работу? Есть ли в нём output cache? Использует ли он TransmitFile/splice для оффлоада отправки в железо?

Нет, рассчитан на самостоятельную работу, без дополнительных серверов. Хотя естественно в случае огромного количества статики никто не мешает поставить nginx в режиме прокси на выходе. Правда если сайт только из статики, то тогда непонятно зачем vibe.d тут вообще.

Кэша выходного нет. Хотя для динамики его тривиально реализовать, с учётом встроенного интерфейса к redis'у. Правда не уверен в его полезности, т.к. в большинстве случаев основными тормозами такого кода будут обращения к базе данных и лучше уж кэшировать там. Тем более, что в случае vibe.d стандартной встроенной базой является MongoDB.

Да, для отдачи статических файлов используется sendFile.

S>Конечно прицепился. Потому что "подобный шаблонизатор" никак не сможет обойти по быстродействию отдачу шаблона из статического файла. Ну, то есть если мы возьмём одиночный запрос, то один из response time шаблонизатора может оказаться короче, чем один из response time классического HTTP-демона. Благодаря изначально неравным условиям — например, шаблонизатор прогрет, а статический хэндлер запускается из прогретого кэша.
S>А если мы будем симулировать реальную нагрузку и смотреть на response time и throughput, то шаблонизатор всегда будет не лучше, чем статический хэндлер. Природу не обманешь.

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

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

S>И в чёи, интересно, такие картинки могут убедить? Что большинство вебсайтов строится людьми, не имеющими ни малейшего представления о производительности, так что даже самый уродский сервер, который только можно себе представить, доминирует на рынке с большим отрывом?
S>Простите, это вообще ничего не доказывает в техническом плане.

Почему на первом месте Apache и какова его клиентская база я вполне себе представляю. А вот сравнение тенденции других участников уже весьма интересно... )

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

G>Если не меняется, то сгенерируй один раз и положи файлом, тогда IIS с его отдачей из ядра порвет любую реализацию.

Вот именно по поводу этого тут и был небольшой спор. Потому как "отдача из ядра IIS" работает быстрее шаблонизатора (речь про выдачу статики с помощью него!) только при наличие ряда условий (типа наличия данных в кэше и т.п.).

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

K>Не понятно, что это за невостребованное ядро.
K>Диаграмма классов это:
K>1) а) Группировка для функций/методов с делением на публичные и приватные. Востребована она в хаскеле? Да. Функции на приватные/публичные делятся? Да.
K>б) Стереотипы для классификации таких групп. обычные классы/интерфейсы/статические классы/модули/классы типов/рекорды и т.д. Востребовано это в хаскеле? Да.
K>2) Отношения между этими группами функций вроде наследования, аггрегации, имплементации и т.д.
K>Востребовано это в хаскеле? Конечно. К примеру между классами типов отношение наследования, а между инстансами и классами типов — отношение имплементации.
K>Всего хватает, "ядро" используется в полном объеме. Что не так-то?

Нет, основой является совсем не это, а связь между функциями и данными (даже не типами, а экземплярами данных!), с которыми они работают. Всяческие преобразования этой взаимосвязи (типа наследования), а так же пересечение с соседними взаимосвязями (типа композиции/агрегации) является уже следствие. Ну а приватные/публичные методы или тем более стереотипы — это вообще уже мелочи. Да, они актуальны для работы автоматических генераторов код<->диаграмма, но архитектуру задают совсем не они.

K>Нет, я говорил о преобразовании конвейера из all / map / takeWhile и т.д. в цикл, и вообще класс преобразований из последовательных проходов в один проход. Без контроля эффектов эти преобразования в общем случае некорректны.

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

Или же подразумевается, что компоновщик/компилятор сможет взять произвольную чужую функцию типа FilterXXX(array, pure func) с циклом по array внутри и как-то интегрировать её внутрь цикла допустим внутри map'a? ) Если так, то это конечно довольно интересно, но я пока о таком не слышал.

Кстати, забавно что в gcc есть как раз обратная автоматическая возможность (опция ftree-loop-distribution).

K>Это не доказывает невозможность, но показывает, что никаких оснований говорить о повторении всех возможностей которые дает контроль эффектов а ля хаскель пока нет.

"Пока нет" — это справедливо. ) Я кстати даже не уверен, что это "пока" когда-нибудь исправится, т.к. что-то не очень много желающих заниматься этим направлением. Но главное то, что теоретическая возможность вполне есть, причём без всяких ужасных ограничений на язык (типа хаскельских). О чём я собственно и говорил.

_>>Конвейеры очень разные бывают...
K>Это точно, те, кто использует только вырожденные конвейеры из 0 и 1-ой стадии — тоже не осознают.

А как насчёт таких http://www.rsdn.ru/forum/philosophy/5676154

Автор: alex_public
Дата: 06.07.14

? )

K>Не знаю, к чему этот разговор. Если мы сравниваем числа сравнимые с погрешностью измерений, значит их нужно статистически обрабатывать, а не просто "брать минимальные" — вот и все.

Ну так вы не правильно статистически обрабатываете — не учитываете, что отклонение измерения от истинного значения идёт только в одну сторону. )

K>Пролог конечно вызывает, по началу, яркие впечатления у неподготовленного программиста, но представления о настоящем высоком уровне он составить никак не поможет.

Не, я с ним очень давно знаком и он мне всегда нравился. ) Но ни разу не было возможности применить его по делу — я же исключительно практик, а не теоретик, играющийся с маргинальными языками. А тут вот неожиданно нашлось применение (правда для этого пришлось встраивать в C++ приложение и добавлять свои предикаты), причём получилось всё крайне удачно и удобно.

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

K>В моем примере они не виртуальные. Это самые обычные аллокации, сделанные стандартным аллокатором. Вы же предлагаете считать каждое изменение на месте новым размещением всего массива. Тут "аллокации" будут, конечно, виртуальными.

Вообще то в том моём коде по сути используется своеобразный аналог функции realloc из C. Так вот если заменить его на просто alloc, то по сути ничего не изменится. Кроме просевшего быстродействия, т.к. все эти виртуальные гигабайты резко станут реальными. Т.е. в данном случае мы имеем дело именно с оптимизацией. Просто ручной, а не автоматической. Ну так про отсутствие в D готовых библиотек подобной оптимизации мы уже говорили, но как видно, их написание не представляет вообще никакого труда.

K>"Принципиальный факт" заключается в том, что объект, ссылающийся на изменяемый массив, иммутабельным не является. Хотя конструирование миллиона таких объектов действительно от конструирования миллиона иммутабельных отличаться по производительности не будет.

Я уже не раз повторял: область памяти, на которую ссылается такой объект является абсолютно неизменной всё время жизни объекта. Почему вы ставите "в ответственность" такому объекту изменение памяти следующей непосредственно за его блоком, мне не понятно.

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

_>Ну например те же самые angular шаблоны. Собственно это просто html страницы без данных и скриптов.
Тогда почему вы называете их "js", если они html?

_>И соответственно они отлично генерируются серверными шаблонизаторами, заточенными под создание html.
Продолжаю непонимать — в чём тут роль серверного шаблонизатора?

_>Хы, так никто не ставит себе такие цели. ) Зачем писать с нуля то, что уже есть, отлично работает и полностью доступно. Тут пишутся другие решения для других целей. Но при этом одной из побочных функций у них идёт и такая функциональность, так сказать для комплекта. По поводу её эффективности надо смотреть (не измерял), но пример Cyberax с несколькими строками на Питоне весьма показателен... )
Пример ничего не говорит про то, как замечательно пример с несколькими строками хэндлит conditional get и range requests.

_>Нет, рассчитан на самостоятельную работу, без дополнительных серверов. Хотя естественно в случае огромного количества статики никто не мешает поставить nginx в режиме прокси на выходе. Правда если сайт только из статики, то тогда непонятно зачем vibe.d тут вообще.
Ну, тогда не стоит рассчитывать, что он хоть кого-то порвёт на отдаче статики.

_>Кэша выходного нет. Хотя для динамики его тривиально реализовать, с учётом встроенного интерфейса к redis'у. Правда не уверен в его полезности, т.к. в большинстве случаев основными тормозами такого кода будут обращения к базе данных и лучше уж кэшировать там.
Кэширование — сложная штука. В общем случае кэширование должно быть расположено как можно ближе к клиенту. Лучше всего — клиентский кэш. Хуже всего — файловый кэш сервера базы данных.

_>Да, для отдачи статических файлов используется sendFile.

_>Ну так если мы предположим ситуацию (вполне реальную кстати), что шаблонизатор и прогретый кэш отдают статическую страницу за одно и то же время, то с учётом редких случаев непрогретого кэша/промахов кэша, в среднем можем получить чуть большее время, чем у шаблонизатора.
У шаблонизатора будет примерно столько же случаев непрогретого кэша и промахов.

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

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

G>>Если не меняется, то сгенерируй один раз и положи файлом, тогда IIS с его отдачей из ядра порвет любую реализацию.

_>Вот именно по поводу этого тут и был небольшой спор. Потому как "отдача из ядра IIS" работает быстрее шаблонизатора (речь про выдачу статики с помощью него!) только при наличие ряда условий (типа наличия данных в кэше и т.п.).
Ну если файл статичен, то его не будет в кеше ровно один раз.

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

S>Тогда почему вы называете их "js", если они html?

Потому что они потом используются из клиентских js фреймворков в качестве шаблонов.

S>Продолжаю непонимать — в чём тут роль серверного шаблонизатора?

Эээ, он их генерирует? )

S>Пример ничего не говорит про то, как замечательно пример с несколькими строками хэндлит conditional get и range requests.

Ну так эти несколько строк и не задумывались как конкурент nginx'у на рынке. )))

S>Ну, тогда не стоит рассчитывать, что он хоть кого-то порвёт на отдаче статики.

А тут кто-то предлагал vibe.d для отдачи файлов с диска? )

S>У шаблонизатора будет примерно столько же случаев непрогретого кэша и промахов.

С чего это? После загрузки приложения в память у него будет стабильное время выдачи результата.

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

G>Ну если файл статичен, то его не будет в кеше ровно один раз.

Если мы говорим про тот же IIS, то это не так. Я же кидал уже тут ссылку. Там и стратегия засовывания в кэш более сложная и не всё можно засунуть в кэш, работающий в ядре (а в ином случае шаблонизатор явно не медленнее будет) и т.п.

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

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

G>>Ну если файл статичен, то его не будет в кеше ровно один раз.

_>Если мы говорим про тот же IIS, то это не так. Я же кидал уже тут ссылку. Там и стратегия засовывания в кэш более сложная и не всё можно засунуть в кэш, работающий в ядре (а в ином случае шаблонизатор явно не медленнее будет) и т.п.
А ты её сам читал? Если файл на диске, то надо очень постараться чтобы не попал в кеш. Собственно если ты специально не будешь портить настройки IIS, то он статику будет отдавать очень быстро.

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

G>А ты её сам читал? Если файл на диске, то надо очень постараться чтобы не попал в кеш. Собственно если ты специально не будешь портить настройки IIS, то он статику будет отдавать очень быстро.

Я и не говорю, что там всё плохо. Но и с твоим "если файл статичен, то его не будет в кеше ровно один раз" тоже совсем не совпадает.

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

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

G>>А ты её сам читал? Если файл на диске, то надо очень постараться чтобы не попал в кеш. Собственно если ты специально не будешь портить настройки IIS, то он статику будет отдавать очень быстро.

_>Я и не говорю, что там всё плохо. Но и с твоим "если файл статичен, то его не будет в кеше ровно один раз" тоже совсем не совпадает.

Твое мнение не совпадает или что? Думаешь я не настраивал IIS для максимального быстродействия и не оптимизировал веб-приложения?
То что ты пишешь — фантастика чистой воды.

Для скорости веб-приложений важно:
1) Кеширование
2) Работа с хранилищем данных
...
10) скорость работы кода

Хоть заоптимизируй до невозможности свои нативные модули, но пара настроек в IIS и подкручивание запросов к базе, порвут в какашки любой код.

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

_>Эээ, он их генерирует? )
Из чего он их "генерирует"?

_>А тут кто-то предлагал vibe.d для отдачи файлов с диска? )
Ещё четыре поста назад вы наивно полагали, что vibe.d способен каким-то магическим образом обойти коробочные http-сервера в отдаче статики (которая как правило сводится к "отдаче файлов с диска").

_>С чего это? После загрузки приложения в память у него будет стабильное время выдачи результата.
Ну так и после загрузки файла в кэш у сервера будет стабильное время выдачи результата. Ровно вплоть до вытеснения файла из кэша.
Что работает ровно так же и для приложений. Понятие "загрузки приложения в память", на которое вы опираетесь, последний раз было актуально примерно во времена MS DOS. Современные оси загружают код приложений по требованию, точно так же, как и данные.

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

G>Твое мнение не совпадает или что? Думаешь я не настраивал IIS для максимального быстродействия и не оптимизировал веб-приложения?
G>То что ты пишешь — фантастика чистой воды.

Нет, описание работы кэша IIS не совпадает с твоими высказываниями. )

G>Для скорости веб-приложений важно:
G>1) Кеширование
G>2) Работа с хранилищем данных
G>...
G>10) скорость работы кода

G>Хоть заоптимизируй до невозможности свои нативные модули, но пара настроек в IIS и подкручивание запросов к базе, порвут в какашки любой код.

Потестируем?

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

S>Из чего он их "генерирует"?

Из серверного шаблона (типа jade).

_>>А тут кто-то предлагал vibe.d для отдачи файлов с диска? )
S>Ещё четыре поста назад вы наивно полагали, что vibe.d способен каким-то магическим образом обойти коробочные http-сервера в отдаче статики (которая как правило сводится к "отдаче файлов с диска").

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

S>Ну так и после загрузки файла в кэш у сервера будет стабильное время выдачи результата. Ровно вплоть до вытеснения файла из кэша.

Ну так тот же IIS скажем работает с кэшем совсем не так тривиально, как вы тут описали. А вот загрузка приложения в память именно так. )))

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

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

G>>Твое мнение не совпадает или что? Думаешь я не настраивал IIS для максимального быстродействия и не оптимизировал веб-приложения?
G>>То что ты пишешь — фантастика чистой воды.

_>Нет, описание работы кэша IIS не совпадает с твоими высказываниями. )

G>>Для скорости веб-приложений важно:
G>>1) Кеширование
G>>2) Работа с хранилищем данных
G>>...
G>>10) скорость работы кода

G>>Хоть заоптимизируй до невозможности свои нативные модули, но пара настроек в IIS и подкручивание запросов к базе, порвут в какашки любой код.

_>Потестируем?

Тестируй.

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

_>Из серверного шаблона (типа jade).
Масло масленое. Какие параметры подставляются в шаблон?

_>Ничего подобного. Речь шла про отдачу шаблонизатором (который, как мы уже обсуждали, не сильно отличается по быстродействию от кэша), а не про отдачу файлов с диска.
Ок, давайте сначала. Что именно у вас собирается отдавать шаблонизатор? Готовый маркап? Тот, который вместо 5 килобайт шаблона и 20 килобайт данных содержит 100 килобайт разметки? Или всё же он у вас отдаёт отдельно шаблон, отдельно данные?

_>Ну так тот же IIS скажем работает с кэшем совсем не так тривиально, как вы тут описали. А вот загрузка приложения в память именно так. )))
Ещё раз: Усложнения IIS по работе с кэшем позволяют ему порвать ваш шаблонизатор, даже если последний будет прогрет. Потому что он, в отличие от шаблонизатора, умеет хэндлить conditional get и partial requests. А с точки зрения кэша файловой системы данные ведут себя совершенно одинаково, хоть они лежат внутри .exe, хоть в отдельном файлике. Ну, разве что кодировка строковых констант может отличаться — в файлухе можно использовать UTF-8, дружелюбный к HTML, а в data segment обычно константы пишутся в кодировке, выбранной компилятором. Я не в курсе, что выбрано в D, подозреваю, что UCS-2 — в духе времени. Плюс возможности частичного обновления — при хранении файликов отдельно мы можем инвалидировать кэш локально; в случае монолитного exe замена Copyright(c) 2013 на Copyright(c) 2014 вызовет сброс всего кэша в ноль. Но это — малосущественные детали.