[У меня гениальнейшая идея!] Кто сказал, что компилируемые языки не подходят для Web?

Он по идее память шарит. Вы сам видели в top/htop 10 ГБ занятой апачем памяти?

Вы сам видели в top/htop 10 ГБ занятой апачем памяти?

Он звонарь, с потерей ориентации.

Где я говорил про апач? И зачем 2000 fork'ов?
Cassandra, например, написана на яве, есть тесты производительности в сравнении с другими базами данных. Она не проигрывает. (Вообще, там опционально используется оптимизация работы с памятью на системах, где она доступна).

и почему еще никто не упомянул https://github.com/alsonkemp/turbinado/wiki

>Зачем думаешь всякие nginx придумали

Чтобы статику эффективнее отдавать.

Сам недавно тестил apache+php-fpm и nginx+php-fpm - разницы в скорости, потреблении памяти и cpu пратически не заметил (все ресурсы отжирал пых-пых). А вот со статикой nginx намного эффективнее себя показал.

И да, кто использует апач с prefork модулем - ССЗБ :)

Паршивая идея. Кресты непригодны для обработки текста.

>Где изъян в моей конгениальной идеи, которая может положить конец тормозам интерпретаторов?

Тормоза из-за динамической типизации а не из-за интерпретирования. Скрипты на языке со статической типизацией тот еще анекдот.

Кэп, ты?

Жава, на которой написана половина интернета - компилируемый язык. Все уже придумано. Кури маны.

Где изъян в моей конгениальной идеи

в том, что это идея не нова чуть более, чем полностью

Тред читать лень. Никто не говорил, просто нынче человеческое время стоит дороже машинного, на интерпретируемых писать выгоднее.

Видел суровую вебморду к тулзе для проверки на уязвимости (названия не вспомню), так она была написана на сях с использованием XSLT (да-да, настоящие мужики используют XSLT и правильно делают, велосипеды не нужны :) ).

Что такое SCGI - не знаю. У меня было требование, чтобы работало с минимумом настроек сервера. Делал CGI + C++, и делил на 2 части - одна серверная - делает фоновые задачи, другая клиентская - CGI, обращается к серверной по самописному RPC, и генерирует HTML.

Работало это весьма неплохо, но архитектура получилась немного кривоватая, но тут не веб и не плюсы виноваты, а только то, что я - ССЗБ.

http://www.webtoolkit.eu/wt

http://www.kernel.org/doc/man-pages/online/pages/man2/fork.2.html

Вобщем, в нотесах указано, что начиная с glibc 2.3.3 fork() вызывает clone(), которая используется в обычных posix threads. Собственно, как раз об этом я подумал, думая над ответом на вопрос :) Таким образом, сейчас нет особой разницы между форком и потоком в линуксе. И то и другое работают с памятью примерно одинаково. Следовательно, все может упираться в процессорное время, но это также обходится включением кэша. ИМХО, поэтому, нвнешний апач с модулями кэширования не должен проигрывать в скорости nginx. P.S. По вопросу - не видел.

Я, конечно, понимаю твоё желание писать для веба на нормальном языке. Но написание кода - это ещё не всё. Как ты будешь новую версию выкатывать? У жабы есть для этого средства, для похапе подойдёт тупо /bin/mv. А для плюсов? Не останавливать же серв, пусть даже и на секунду, юзвери недовольны будут.

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

http://www.ksplice.com/doc/ksplice.pdf

А когда я сказал в школе в 14 лет, что хочу писать сайт на С++, на меня посмотрели, как на идиота.

Да это понятно. Но работающее отлаженное решение есть? Нету, надо изобретать. Изобретёшь - поделись :)

Хех, я вот в колледже говорил: «А давайте вместо пераццкого Windows 2003 Server на роутер колледжа поставим Debian GNU/Linux!» - ты не поверишь, на меня посмотрели так же.

Вывод: учителя и преподаватели - не последняя инстанция, и далеко не всегда правая.

//я учуял в твоём сообщении стёб, и тем не менее оно неубедительно.

Главное, в такой ситуации не сильно настаивать. А то потом сам же себя проклянешь, когда будут дергать «ой, а где енто здесь ворд?».

А для плюсов? Не останавливать же серв, пусть даже и на секунду, юзвери недовольны будут.

А ведь ещё в прошлом тысячелетии КЛ умел изменять свой образ на лету.

З.Ы. Теперь это тред про лисп.

Тут был недавно тред о вашем Лиспе. :-\

Про Java забыл.

Где я ошибаюсь?

Щас я тебе вообще страшную вещь расскажу. Можно даже проблемы с утечкой памяти решить одним махом. Нужно под каждый запрос выделять блок памяти и и на запросы выделения памяти отдавать из этого блока, а по завершению весь этот блок удалять целиком. Еще можно прикрутить корутины. Быстро получится. Только практически всю инфраструктуру придется с нуля разрабатывать.

подойдет slab allocator

не отправилось в первый раз

лисп может быть очень быстр - tepedee - сервер на CL, DRAGONFLY - веб фреймворк на newlisp

P.S. хочу веб-фреймворк на ассемблере

> Кто сказал, что компилируемые языки не подходят для Web?

Открой для себя С# и ASP.NET (про Java тут уже сказали, так что.. Кстате ЛОР сделан на яве).

Вообще-то кое-кто уже реализовывал движок ЛОРа на C++.

Компилируемые языки менее удобны из-за отладки. А в вебе это очень и очень нужно. К тому же на компилируемых языках труднее дорабатывать сайты, так как может возникнуть надобность внезапно изменить или дополнить функциональность. Особенно это актуально для пыхокодеров, которые часто делают ошибки и которым часто указывают переиначить код. А работают они за миску супа.

В принципе никто не мешает сделать компилятор в кэш-бинарники для ускорения выполнения сайтов, но это уже усложнение серверной части.

Кроме того есть ещё и жаба - она по сути компилируема в байт-код VM.

Для лиспа, кстати, есть веб-фреймворк.

ХЗ. А это разве не kernel space? Вообще обычно используют APR MemoryPool или Boost Pool

>напиши компилятор похапе в натив

http://habrahabr.ru/blogs/php/125597/

>> Кто сказал, что компилируемые языки не подходят для Web?

Открой для себя С# и ASP.NET

Ну, если строго формально подходить, то и Python, и PHP, и Ruby 1.9 (до него — не знаю) — компилируемые языки (с интерпретируемой виртуальной машиной).

> Ну, если строго формально подходить, то и Python, и PHP, и Ruby 1.9

Если ещё более строго подходить, то у С# и С++ больше общего, чем у питона и ПХП с С++ же (за руби не скажу): статическая типизация.

Только это уже к вопросу компиляции не относится.

> Компилируемые языки менее удобны из-за отладки.

Лолшто? Для справки: компиляция позволяет выявить целый класс ошибок несоответсвия типов/неправильного использования объектов на этапе компиляции, в то время как для интерпретируемых языков для этого нужно писать кучу тестов или ловить баги в рантайме.

> Только это уже к вопросу компиляции не относится.

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

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

Подотрись своим справочником. В реальности всё несколько иначе.

Я скорее подотрусь твоим очень информативным постом.

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

>Ну отчасти таки относится

Статическая типизация бывает и у интерпретируемых языков. Динамическая — у компилируемых.