Re[131]: Есть ли вещи, которые вы прницпиально не понимаете...
От: alex_public  
Дата: 15.07.14 19:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>То есть, писать нужно всё, что и в моём случае, плюс дополнительную страницу, которая будет перезагружаться каждый раз когда юзер будет открывать закладку. Экономия, теоретически, от силы пару секунд на первом посещении сайта.


Не дополнительную — начальная страница нужна и в твоём варианте. Вопрос только в том, размещаем мы в ней собственно данные или же она является статическим шаблоном.

I>Это если использовать Ангуляр. А что твоими темплейтами ? Они ведь "как jade", то есть ничего подобного ангуляру не умеют и работают на сервере.


Ещё раз, фреймворк vibe.d не имеет никакого отношения к работе на клиенте. Так же как скажем и node.js. Это серверный фреймворк, который может работать в паре с любым клиентским js фреймворком (а можно и вообще без него в случае простого отображения).
Re[128]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.14 08:09
Оценка:
Здравствуйте, alex_public, Вы писали:

_>О, ну так раз вы так разбираетесь, то конечно же без проблем озвучите среднее время необходимое на переключение в нулевое кольцо и среднее время необходимое для считывания одного кластера данных со стандартного жёсткого диска? )

на P4 переключение колец занимает ~500 тактов. Переключений между tcpip.sys и vibe.d будет несколько — детали зависят от того, что написано в коде страницы.
Считывание одного кластера с типичного винта — 5мс. Нерелевантно обсуждаемому вопросу, т.к. cache miss может случиться как для статики, так и для динамики (ведь скрипт откуда-то берётся, правда?). Речь идёт об отдаче контента из прогретого кэша, когда важен каждый context switch. В https.sys при наличии респонса в кэше его адрес, грубо говоря, напрямую уезжает в DMA для отправки в сетевую карту. Порвать его по производительности при помощи велосипеда — дохлый номер.

_>Ага, ага. Видимо её надо подучить и подавляющему большинству проектировщиков высоконагруженных систем, т.к. они все почему-то сидят на nginx или собственных велосипедах, а не на "Windows Server 2012 Web Edition". )

По лицензионным, а не архитектурным соображениям. И кроме nginx есть ещё несколько решений. Вообще, их существование в основном обеспечено крайне позорной архитектурой апача — дефолтного веб сервера в линукс мире. Про велосипеды у меня есть мнение, но оно нецензурное, и озвучивать я его не буду.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[127]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Cyberax Марс  
Дата: 16.07.14 08:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Одно переключение в юзермоду для вызова вашего vibe.d будет стоить больше, чем всё время его работы.

S>Надо понимать, что редкий сайт сейчас хранит гигабайты статики (если мы не говорим про специализированные контент-хостинги); это означает, что коробочная Windows Server 2012 Web Edition способна отдавать HTML быстрее, чем любые ваши интерпретируемые фреймворки.
Не надо переоценивать хаки в Windows. А отдача HTML прямо из ядра — это ни что иное, как грязный хак.

Nginx использует намного более вменяемую архитектуру — чтение и разбор HTTP-заголовка требует примерно одного системного вызова (чтение пары килобайт в буфер в userspace). Затем если nginx внутри себя находит закэшированные данные, то он их отдаёт в сокет через sendfile (в Винде есть аналог TransmitFile). Данные идут прямо из страниц файлового кэша — быстрее некуда.

Есть ещё HAProxy, специально заточенный на передвижение гигабайтов данных. Там используется чуть более продвинутый системный вызов — splice(2). В результате, при использовании карт с TCP Segmentation Offload и правильным DMA можно коммутировать потоки по 10Гб на одном ядре: http://www.haproxy.org/#perf ( http://www.haproxy.org/10g.html )

Это НАМНОГО более прямой подход, так как единственно критичный по скорости примитив (передача потенциально большого буфера) ускоряется с помощью специализированного механизма, доступного всем. Так что я могу реализовать свой протокол (SPDY или HTTP2), который будет сравним в скорости с http.sys, не дожидаясь пока Microsoft проснётся.
Sapienti sat!
Re[128]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.14 10:35
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это НАМНОГО более прямой подход, так как единственно критичный по скорости примитив (передача потенциально большого буфера) ускоряется с помощью специализированного механизма, доступного всем. Так что я могу реализовать свой протокол (SPDY или HTTP2), который будет сравним в скорости с http.sys, не дожидаясь пока Microsoft проснётся.

Давайте вернёмся на шаг назад.
Обсуждается вопрос скорости отдачи в HTTP статики по сравнению со скриптовыми фреймворками. Вопрос передачи гигабайтных пакетов по TCP/IP тут неинтересен — мы не будем переизобретать веб.
Речь идёт не о типичном для соврменных веб-приложений ворклоаде: миллионы запросов, где response size в пределах десятка-сотни килобайт.
Вот, собственно, релевантный кусок чуши:

Вообще то все http-демоны отдают статику как раз с диска. И решения типа размещения этого диска в оперативке я довольно редко вижу. Чаще применяются прокси между демоном и сетью, кэширующие запросы в оперативке. Но в любом случае это всё чуть уступает по скорости прямой записи как в vibe.d.

Я пытаюсь объяснить, что "отдача статики с диска" — адски оптимизированная операция. Есть разные стратегии оптимизации — http.sys, сплайсы, sendfile.
Порвать это при помощи шаблонизатора с "прямой записью" — дохлый номер.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[132]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.07.14 11:42
Оценка:
Здравствуйте, alex_public, Вы писали:

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


I>>То есть, писать нужно всё, что и в моём случае, плюс дополнительную страницу, которая будет перезагружаться каждый раз когда юзер будет открывать закладку. Экономия, теоретически, от силы пару секунд на первом посещении сайта.


_>Не дополнительную — начальная страница нужна и в твоём варианте. Вопрос только в том, размещаем мы в ней собственно данные или же она является статическим шаблоном.


Именно дополнительную. У меня эта страница просто статика, а тебе надо писать код что бы её отдавать.


I>>Это если использовать Ангуляр. А что твоими темплейтами ? Они ведь "как jade", то есть ничего подобного ангуляру не умеют и работают на сервере.


_>Ещё раз, фреймворк vibe.d не имеет никакого отношения к работе на клиенте. Так же как скажем и node.js. Это серверный фреймворк, который может работать в паре с любым клиентским js фреймворком (а можно и вообще без него в случае простого отображения).


У меня ощущение что ты не читаешь. Я как раз и говорю про "не имеет никакого отношения к работе на клиенте"

Покажи как ты будешь отдавать свои темплейты которые "никакого отношения к работе на клиенте" да вместе с данными.

P.S. Node.js это просто платформа, не надо её тащить этот баззворд во все мессаги, это базовый функционал операционной системы. node.js может и умеет рабоать по разному. Шаблоны можно процессить на сервере ,а можно и на клиенте. Оба варианта ничем не противоречат node.js
Re[112]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Klapaucius  
Дата: 16.07.14 11:50
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Не вижу логической связи между утверждениями в конце фразы и в начале. Фраза теоретически могла бы быть справедливой при одном из двух условий:

_>1. Хаскель — это ООЯ с расширениями.
_>2. В ООЯ с расширениями только эти расширения и используют, а классической частью вообще не пользуются.
_>Но насколько я знаю, оба эти утверждения не верны.

Нет, ни первого ни второго для этого не нужно. Достаточно чтоб все, что требовалось для отображения на диаграммах хаскеля покрывалось средствами испытанными в разных языках с расширениями ООП. А так оно и есть.

_>О, вы уже начинаете признавать то, о чём я говорил всё это время...


Я это и сказал в самом начале.

Я не согласен, что это выглядит намного страшнее, чем в других языках (если не считать упомянутые мной "карательные" наименования, которые легко исправить). Монадический код часто, но не всегда, требует синтаксической обвязки для "стыковки" в отличие от функций вида a -> b в хаскеле, и потому код с мутабельными ссылками/массивами может выглядеть многословнее, чем хаскель-код с иммутабельными. Но в большинстве языков обычно наворочено столько синтаксического мусора без всякого смысла вообще, что на этом фоне и монадический хаскель-код выглядит вполне пристойно. <...>
Т.е. раз у хаскеля нерастраченный на всякую ерунду синтаксический бюджет — какие-то редкие уродства погоды не делают, особенно если сравнивать с языком, сыплющим всюду синтаксический мусор лопатой. Поскольку С++ как раз такой, код на нем даже в тех областях, где он силен смотрится страшнее, чем хаскель-код, демонстрирующий самые неприглядные стороны хаскеля.
Гипотетическую возможность сделать синтаксис лучше, чем в хаскеле я, разумеется, не отрицаю.
<...>
Я пишу не о том, что код синтаксически лучше выглядит в какой-то другой области, а о том, что даже тот самый код, про который вы говорите "весь в большой монаде", если я, конечно, правильно понял, что вы имели в виду, синтаксически лучше, чем код на типичном императивном языке, синтаксис которого как будто придуман, чтоб покарать любого, кто захочет на этом языке что-то написать, не говоря уж о том, чтоб прочесть.


_>И похоже что лучше всего использовать тут в аргументации OCaml (кстати один из моих фаворитов когда-то


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


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


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

_>Ну так тогда вас не затруднит кинуть ссылку на конкретное сообщение ваше сообщение? )


Ну вот об этом я и говорю. Ведь мы же эти преобразования буквально в предыдущем посте обсуждали.
http://rsdn.ru/forum/philosophy/5624883.1
Автор: Klapaucius
Дата: 29.05.14


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

_>Хорошая отмазка. )))

Это констатация фактов.

_>Может тогда стоит вообще прекратить дискуссию? )


Дискуссию на заявленные темы мы еще и не начали. Вообще, дискуссия предполагает 1) реакцию на ответ, а не полное его игнорирование и простое повторение вопроса, на который уже ответили. 2) адекватную реакцию на вопрос, а не ответ на вопрос, который никто не задавал.

_>А вот как раз это мы действительно уже обсуждали и я уже отвечал) Но могу повториться — мне не нравится что это навязанное ограничение (тем более оно выглядит глупо, т.к. при переходе от академических задач к практике, 90% кода уплывает в монады).


Как раз наоборот, при написании вычислителей факториалов и чисел Фибоначчи хаскель не имеет принципиального преимущества перед ML-ями. Ну ладно, имеет благодаря ленивости, и это даже в некотором смысле благодаря IO, но сейчас разговор не об этом. При работе с таким кодом и в ML-ях применим equational reasoning (с оговорками, но это и в хаскеле так, их там немногим меньше), и вообще это, в основном, хороший ФП код.
Совсем другое дело, когда дело доходит до решения системных задач. Тут разница принципиальна и выразительность и контроль над сложностью у хаскеля существенно выше, чем у языков, где контроля эффектов нет. Потому, что в хаскеле эффекты первоклассны, типизированны (не достаточно легковесно, правда) и комбинируемы (с оговорками, как принципиального характера, так и связанными с убогостью хаскеля — его системы типов в первую очередь). Поймите меня правильно, система контроля за эффектами хаскеля имеет множество недостатков, критиковать ее можно и нужно, но с позиции других, превосходящих систем контроля за эффектами, а не с позиции отсутствия такой системы. Тут разница, как между языками типизированными и бестиповыми — это разные лиги, тут даже сравнивать нечего.


_>Никто не мешал добавить в язык те же самые возможности, но опционально.


В данном случае практически значимой разницы между "опциональность" и "отсутствие возможности" нет.


_>Как в том же D. Хотя в нём это направление совсем не разработано,


Ну так в том и дело, что нет никакого использования сведений о чистоте рантаймом, например.

_>но я не вижу никаких теоретических препятствий на пути к достижению в точности хаскелевских результатов,


Достижение хаскельных результатов затруднительно хотя-бы потому, что не планируется.

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

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

_>но при этом без всяких "синтаксических пенальти". )


В подходе как в Ди пенальти все равно есть — это аннотации чистоты.

_>Ну лично мне кажется, что красивее написать q{a>b} или даже "a>b", но естественно можно и (x, y)=> x>y, если вам почему-то нравится только такой вариант. Как видите опять же полная свобода в языке.


Мне не нравится, не это, а вот это:
bool WhileAny(string F1, string F2, T)(immutable T[] a, T v, int i=0)
{
    if(i>=a.length||binaryFun!F1(a[i], v)) return false;
    if(binaryFun!F2(a[i], v)) return true;
    return WhileAny!(F1, F2)(a, v, i+1);
}


_>Думаю, что часть осознаёт, а часть нет.


Это только та часть не осознает, которая конвейеры не использует.

_>Однако при этом большинство в любом случае подразумевают один и тот же объект при упоминание данного термина. )))


С этим у мейнстрим-терминологии как раз проблемы. Когда два мейнстрим-программиста используют один термин, можно вполне рассчитывать на то, что подразумевают они разные объекты.

_>Если результат измерения производительности будет отличаться на пару процентов, то можно смело считать производительность равной. )))


Да можно и при 10% равной считать.

_>Ооо, кстати, действительно разница в результатах может быть от игр с разрядностью. Там и компиляторы по разному работают...


Тут большее значение имеет не то, что компиляторы по разному компилируют (на x64 регистров больше и т.д.) а то, что на x64 программа на хаскеле просто выделяет больше памяти из-за того, что "нативные" типы там всегда равны машинному слову и все "объекты" соотвествующим образом выровнены в памяти. На практически важный вопрос о том, что из себя int в Ди на x64 представляет вы, кстати, не ответили.

_>В идеале надо отдельно проводить два тестирования:

_>1. компилировать в 32 битный код и запускать на машине с 32 битной ОС. Кстати, свои измерения для D я как раз так и делал.
_>2. компилировать в 64 битный код и запускать на машине с 64 битной ОС.

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

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


Пролог в качестве встроенного ДСЛ — это уже другая история. Но говорить о какой-то особой можности пролога как ЯП общего назначения — достаточно смешно.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[114]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Klapaucius  
Дата: 16.07.14 11:59
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Объём действительно не большой


Ну так о чем тогда разговор? Все эти размещения — на грани погрешности измерения. То, что тест действительно измеряет — скорость изменения мутабельного массива, т.е. к поддержке иммутабельности никакого отношения не имеет.

_>т.к. большего для данной задачки и не надо.


Надо. Прямо в формулировке задачи и написано что надо больше.

_>И его всегда можно увеличить, если очень надо.


Ну так увеличте до 300 гигов и посмотрим, 1) уменьшит ли этот объем оптимизации до 16 2) с какой скоростью все будет работать при 16 ГБ иммутабельных объектов.

_>Но мы в данном случае спорили совсем о другом. Так вы наконец то признаёте, что в том моём решение выделялось около миллиона полноценный иммутабельных объектов? )


С самого начала признавал, что некая нагрузка на память размещением ничтожного числа "иммутабельных" (довольно сложно считать объект иммутабельным, если он ссылку на мутабельный массив хранит) объектов тут имитируется, но на производительность примера это все почти никак не влияет.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[129]: Есть ли вещи, которые вы прницпиально не понимаете...
От: alex_public  
Дата: 16.07.14 13:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>на P4 переключение колец занимает ~500 тактов. Переключений между tcpip.sys и vibe.d будет несколько — детали зависят от того, что написано в коде страницы.

S>Считывание одного кластера с типичного винта — 5мс.

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

S>Нерелевантно обсуждаемому вопросу, т.к. cache miss может случиться как для статики, так и для динамики (ведь скрипт откуда-то берётся, правда?).


Нет, в случае vibe.d "скрипт" — это нативный бинарный код, вкопилированный в http сервер.

S>Речь идёт об отдаче контента из прогретого кэша, когда важен каждый context switch. В https.sys при наличии респонса в кэше его адрес, грубо говоря, напрямую уезжает в DMA для отправки в сетевую карту. Порвать его по производительности при помощи велосипеда — дохлый номер.


Только вот http серверы то так не работают... Для начала они должны определить местанохождение целевого файла (а для этого обычно надо прочитать с диска и исполнить всякие конфиги, типа .htaccess с rewrite правилами), проверить его наличие (а иначе выдать сообщение об ошибке) и соблюдение прав доступа. И только после всего этого можно давать команду на его отправку сеть. Сколько у нас тут набирается обращений к диску? ))) И кстати, даже если взять самый упрощённый сервер вообще без изменяемых конфигов и т.п., то всё равно потребуется не один запрос, т.к. поработать с файловой системой всё равно придётся. )

S>По лицензионным, а не архитектурным соображениям. И кроме nginx есть ещё несколько решений. Вообще, их существование в основном обеспечено крайне позорной архитектурой апача — дефолтного веб сервера в линукс мире. Про велосипеды у меня есть мнение, но оно нецензурное, и озвучивать я его не буду.


Гугловские велосипеды тоже подходят под нецензурное? )
Re[133]: Есть ли вещи, которые вы прницпиально не понимаете...
От: alex_public  
Дата: 16.07.14 13:32
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Именно дополнительную. У меня эта страница просто статика, а тебе надо писать код что бы её отдавать.


В том то и дело, что не надо. Ну если конечно ты не называешь кодом jade шаблон. Просто многие используют их и для генерации статики, потому что намного удобнее работать с ним, чем с чистым html. Т.е. грубо говоря, если сами шаблоны мы делаем на jade (или аналоге), то с помощью vibe.d переделка статики в динамику будет стоить ровно 0 усилий.

I>Покажи как ты будешь отдавать свои темплейты которые "никакого отношения к работе на клиенте" да вместе с данными.


Не понял, какие шаблоны ты хочешь увидеть и где? )

I>P.S. Node.js это просто платформа, не надо её тащить этот баззворд во все мессаги, это базовый функционал операционной системы. node.js может и умеет рабоать по разному. Шаблоны можно процессить на сервере ,а можно и на клиенте. Оба варианта ничем не противоречат node.js


Естественно. Только вот работа на клиенте находится уже не в компетенции node.js (так же как и вне компетенции vibe.d).
Re[113]: Есть ли вещи, которые вы прницпиально не понимаете...
От: alex_public  
Дата: 16.07.14 14:14
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Нет, ни первого ни второго для этого не нужно. Достаточно чтоб все, что требовалось для отображения на диаграммах хаскеля покрывалось средствами испытанными в разных языках с расширениями ООП. А так оно и есть.


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

_>>Ну так тогда вас не затруднит кинуть ссылку на конкретное сообщение ваше сообщение? )

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


Так это вы про map p.q говорили? ))) Дааа, бедненько с примерами... Ну и кстати в случае map'а я так и не увидел примера практической пользы от контроля эффектов в данном случае.

_>>Как в том же D. Хотя в нём это направление совсем не разработано,

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

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

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


Конвейеры очень разные бывают...

_>>Если результат измерения производительности будет отличаться на пару процентов, то можно смело считать производительность равной. )))

K>Да можно и при 10% равной считать.

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

K>Тут большее значение имеет не то, что компиляторы по разному компилируют (на x64 регистров больше и т.д.) а то, что на x64 программа на хаскеле просто выделяет больше памяти из-за того, что "нативные" типы там всегда равны машинному слову и все "объекты" соотвествующим образом выровнены в памяти. На практически важный вопрос о том, что из себя int в Ди на x64 представляет вы, кстати, не ответили.


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

K>Не вижу смысла в замерах на 32 битной виндоус. Достаточно разные рерсии на 64-х битной запускать.


Так 32 битный код имеет пенальти на 64 битной системе. Лучше измерять по чистому, тем более если задача такова, что 32 битный код может оказаться абсолютным лидером в сравнение. )

K>И тут еще забавно, что на первоначальное мое предложение замерять релевантные примеры в двух версиях (32 и 64) вы ответили, что слишком много работы, а к замерам разных версий совершенно нерелевантных примеров с таким энтузиазмом отнеслись. Вы для начала напишите пример соответствующий заданию и его измерьте.


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

K>Пролог в качестве встроенного ДСЛ — это уже другая история. Но говорить о какой-то особой можности пролога как ЯП общего назначения — достаточно смешно.


Зато поработав с ним сразу ощущается что такое настоящий высокий уровень... )
Re[115]: Есть ли вещи, которые вы прницпиально не понимаете...
От: alex_public  
Дата: 16.07.14 14:35
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Ну так увеличте до 300 гигов и посмотрим, 1) уменьшит ли этот объем оптимизации до 16 2) с какой скоростью все будет работать при 16 ГБ иммутабельных объектов.


Я не очень понимаю смысл в гонке виртуальных гигабайтов. Но если вы так хотите... Я там поставил счётчик в операторе ~ и получил, что суммарно он выделил в том нашем тесте 2323609629564 байт. Так кто тут у нас отстающий по виртуальным выделениям? )))

K>С самого начала признавал, что некая нагрузка на память размещением ничтожного числа "иммутабельных" (довольно сложно считать объект иммутабельным, если он ссылку на мутабельный массив хранит) объектов тут имитируется, но на производительность примера это все почти никак не влияет.


Я не про нагрузку на память, а про принципиальный факт использования иммутабельных объектов. А то ведь вы помнится и с этим спорили...
Re[113]: Есть ли вещи, которые вы прницпиально не понимаете...
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 16.07.14 17:57
Оценка: 6 (1)
Здравствуйте, Klapaucius, Вы писали:

_>>Ну лично мне кажется, что красивее написать q{a>b} или даже "a>b", но естественно можно и (x, y)=> x>y, если вам почему-то нравится только такой вариант. Как видите опять же полная свобода в языке.


K>Мне не нравится, не это, а вот это:

K>
K>bool WhileAny(string F1, string F2, T)(immutable T[] a, T v, int i=0)
K>{
K>    if(i>=a.length||binaryFun!F1(a[i], v)) return false;
K>    if(binaryFun!F2(a[i], v)) return true;
K>    return WhileAny!(F1, F2)(a, v, i+1);
K>}
K>


Это можно заменить на
bool WhileAny(alias F1, alias F2, T)(...)
...
if (F2(a[i], v)) return true;

И в исходном вызове передавать честные лямбды или иные функции. Это передача по имени, незаслуженно забытая многими языками.
Re[134]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.07.14 03:15
Оценка:
Здравствуйте, alex_public, Вы писали:

_>В том то и дело, что не надо. Ну если конечно ты не называешь кодом jade шаблон. Просто многие используют их и для генерации статики, потому что намного удобнее работать с ним, чем с чистым html. Т.е. грубо говоря, если сами шаблоны мы делаем на jade (или аналоге), то с помощью vibe.d переделка статики в динамику будет стоить ровно 0 усилий.


Каким образом динамика на серверной стороне будет стоить 0 усилий ?

I>>Покажи как ты будешь отдавать свои темплейты которые "никакого отношения к работе на клиенте" да вместе с данными.


_>Не понял, какие шаблоны ты хочешь увидеть и где? )


Те что "как jade", про которые ты говорил или vibe.d.

_>Естественно. Только вот работа на клиенте находится уже не в компетенции node.js (так же как и вне компетенции vibe.d).


Это как бы очевидно, потому совершенно не ясно, для чего ты тащишь баззворд в каждое сообщение.
Re[130]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.07.14 03:24
Оценка: +1
Здравствуйте, alex_public, Вы писали:

S>>Речь идёт об отдаче контента из прогретого кэша, когда важен каждый context switch. В https.sys при наличии респонса в кэше его адрес, грубо говоря, напрямую уезжает в DMA для отправки в сетевую карту. Порвать его по производительности при помощи велосипеда — дохлый номер.


_>Только вот http серверы то так не работают...


И давно IIS перестал быть http сервером ?

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


Один раз, потом все это попадает в кеш и далее смотри у Синклера после "при наличии респонса в кеше"

> И только после всего этого можно давать команду на его отправку сеть. Сколько у нас тут набирается обращений к диску? ))) И кстати, даже если взять самый упрощённый сервер вообще без изменяемых конфигов и т.п., то всё равно потребуется не один запрос, т.к. поработать с файловой системой всё равно придётся. )


Судя по нагрузочным тестам, мой HDD каким то образом ухитряется читать кластеры за 0мс. Не подскажешь, что за чудо ? И да, "кластеры", это не ошибка.

_>Гугловские велосипеды тоже подходят под нецензурное? )


У гугла нет велосипедов и все работает очень похоже на http.sys, только в профиль.
Re[130]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.14 05:46
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Нет, в случае vibe.d "скрипт" — это нативный бинарный код, вкопилированный в http сервер.

Вы понимаете, что если у нас весь контент сайта весит 1GB, то нативного бинарного кода, "вкомпилированного в http сервер", будет тоже 1GB + исполняемый код? И что дисковая активность в обоих случаях определяется соотношением этого размера и размера доступной памяти? Или вы те уроки в школе, где рассказывали про swap и виртуальную память, прогуляли?

_>Только вот http серверы то так не работают... Для начала они должны определить местанохождение целевого файла (а для этого обычно надо прочитать с диска и исполнить всякие конфиги, типа .htaccess с rewrite правилами), проверить его наличие (а иначе выдать сообщение об ошибке) и соблюдение прав доступа.

Ещё раз: мы говорим о прогретом кэше. В этом случае всё, что "проверяет" веб-сервер — это наличие готового response в памяти. После чего отдаёт адрес этого response в драйвер http или tcp, который без участия CPU запихивает респонс в сеть.
_>И только после всего этого можно давать команду на его отправку сеть. Сколько у нас тут набирается обращений к диску? ))) И кстати, даже если взять самый упрощённый сервер вообще без изменяемых конфигов и т.п., то всё равно потребуется не один запрос, т.к. поработать с файловой системой всё равно придётся. )
Столько обращений к диску, сколько произошло cache miss. В современном мире это часто означает "никогда".

_>Гугловские велосипеды тоже подходят под нецензурное?

Не переживайте — рядовому разработчику достичь уровня гугловских велосипедов не светит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[135]: Есть ли вещи, которые вы прницпиально не понимаете...
От: alex_public  
Дата: 19.07.14 13:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Каким образом динамика на серверной стороне будет стоить 0 усилий ?


Ну так если статические страницы генерируются у нас jade'ом (где-то на компьютере разработчика) и потом отдаются с сервера каким-нибудь nginx'ом, то переход к динамике с помощью vibe.d не будет стоить практически ничего.

I>Те что "как jade", про которые ты говорил или vibe.d.


Так я же уже показывал или там было что-то непонятное?

_>>Естественно. Только вот работа на клиенте находится уже не в компетенции node.js (так же как и вне компетенции vibe.d).

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

Потому как я не пойму с чего ты постоянно приплетаешь клиентские js фреймворки в тему про vibe.d.
Re[131]: Есть ли вещи, которые вы прницпиально не понимаете...
От: alex_public  
Дата: 19.07.14 13:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Вы понимаете, что если у нас весь контент сайта весит 1GB, то нативного бинарного кода, "вкомпилированного в http сервер", будет тоже 1GB + исполняемый код? И что дисковая активность в обоих случаях определяется соотношением этого размера и размера доступной памяти? Или вы те уроки в школе, где рассказывали про swap и виртуальную память, прогуляли?


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

S>Ещё раз: мы говорим о прогретом кэше. В этом случае всё, что "проверяет" веб-сервер — это наличие готового response в памяти. После чего отдаёт адрес этого response в драйвер http или tcp, который без участия CPU запихивает респонс в сеть.


Вы собственно про какой кэш то? ) Если про аппаратный в дисках, то это действительно очень эффективная вещь, только вот маленький он. А если вы про некое подобие, организуемое операционной системой в оперативной памяти, то тут уже совершенно другой расклад. Причём в случае винды там совсем всё мрачно... )))
Re[136]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 20.07.14 13:02
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Каким образом динамика на серверной стороне будет стоить 0 усилий ?


_>Ну так если статические страницы генерируются у нас jade'ом (где-то на компьютере разработчика) и потом отдаются с сервера каким-нибудь nginx'ом, то переход к динамике с помощью vibe.d не будет стоить практически ничего.


Это враньё.

I>>Те что "как jade", про которые ты говорил или vibe.d.


_>Так я же уже показывал или там было что-то непонятное?


Ты ничего не показал. Я вот никак не могу понять, что же будет отдаваться на клиент — html со всеми данными, просто темплейт или какие то данные вместе с темплейтом.

Судя по твоим косвенным намёкам, отдавать надо Html со всеми данными. А это, внезапно, исключает 90% оптимизаций. А следовательно "не будет стоить практически ничего" есть просто враньё.

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


_>Потому как я не пойму с чего ты постоянно приплетаешь клиентские js фреймворки в тему про vibe.d.


Для сравнения. Работа с темплейтами на клиенте означает, что серверу надо исключительно данные отдавать.
Если на серверве, то отдавать надо в сотни раз больше чисто из за того, что данные унуте html. Кроме того, это вызывает проблемы например с кешированием, делает невозможным использование большинтсва других оптимизаций. Например, CDN тебе так же не поможет.
Re[132]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 20.07.14 15:58
Оценка:
Здравствуйте, alex_public, Вы писали:

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


Ну да, в среднем это гораздо больше будет. Я вот книги в epub формате вижу, около 100мб в зипе. Надо объяснять, что зип жмёт текст примерно 10 к 1 ?
Книг может быть очень много. Вопрос — обо что встанет сделать веб-интерфейс для небольшой библиотеки, скажем в 1-10 тыс книжек ?

S>>Ещё раз: мы говорим о прогретом кэше. В этом случае всё, что "проверяет" веб-сервер — это наличие готового response в памяти. После чего отдаёт адрес этого response в драйвер http или tcp, который без участия CPU запихивает респонс в сеть.


_>Вы собственно про какой кэш то? )


Да любой кеш не в твою пользу. С правильной статикой запросы вообще могут и не доходить до сервера, их будет отдавать ктото из посредников в цепочке или CDN, а в твоём случае этого нет и быть не может.

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


Не рассказывай ерунды. http://www.webperformance.com/load-testing/blog/2011/11/what-is-the-fastest-webserver/
Re[132]: Есть ли вещи, которые вы прницпиально не понимаете...
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.07.14 05:07
Оценка:
Здравствуйте, alex_public, Вы писали:
_>Ну во-первых как раз размеры то у шаблонизаторов и результатов их работы по любому разные и в таком диком случае это явно очень хорошо проявилось бы.
Мы, вроде бы, говорим про server-side шаблонизатор vs client-side. Для client-side шаблон является "статическим файлом", достаточно маленького размера. Его очень легко держать в кэше, как на клиентской стороне, так и на серверной. Для server-side шаблон существует только в памяти сервера, при отдаче он умножается на размер данных. Его нельзя кэшировать на клиенте, т.к. он "размазан" по результату.

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

Ок, отлично, этот вопрос можно закрыть. Давайте представим себе "нормальный сайт", который влезает в лимиты ваших представлений. Пусть это будет 25MB.

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

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

Я — про http кэш, который является частью любого современного сервера. В винде, начиная емнип с 2003, этот кэш работает в режиме ядра. В lighttpd и nginx он работает в юзермоде, но тоже очень неплохо. На случай промаха мимо http-кэша (например, из-за неудачного vary-by), пойдёт обращение к файловой системе, а там свой кэш. И в случае хоть винды, хоть невинды, там всё очень даже хорошо — для характерных размеров сайтов, как мы выяснили в предыдущем абзаце, 100% контента уже лежит в памяти. Даже если это VPS с 500MB памяти.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.