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

ALKS, сложная динамическая страница становится сложной не от того что это её внутренняя природа, а от того при её генерации надо обработать много данных. А откуда эти данные возьмутся? Правильно, из БД. Так что довод не теряет актуальности. 

это всё есть в python'e...даже больше В) 

Это ты о языке с двухмерным синтаксисом? 
Есть у Ruby одно свойство, которое есть только у двух языков программирования -- это объекто-ориентированный язык (второй, точнее первый, Smalltalk). Все остальные "объекто-ориентированные" языки всего лишь гибриды. 

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

Далее насчет БД и солжных динамических страниц, ты прав только отчасти. То насколько быстро язык взаимодействует с БД зависит от самого языка от написанных на нем драйверов как минимум. Кроме того, кто сказал что динамические страницы это только БД? например часто во время генерации страницы применяеться XML Transformation и многие другие ресурсоемкие решения, скорость которых напрямую зависит от производительности интерпретатора и эфективности работы с памятью(а и то и другое откровенно слабые места Ruby, на данный момент). При 50(условно) запросах в секунду далеко не факт, что узким местом будет БД, точнее факт что не будет, потому что у систем с подобными загрузками очень развиты всевозможные системы кэширования. Я знаю о чем я говорю, я как раз в разработке подобные системы и участвую. 

Этот довод, про неважность скорости для этого класса задач, он в пользу бедных. Я очень хорошо помню, как тоже самое говорили в отношении первых версий Java годах этак 96 - 98, когда интерпретатор Java страдал такими же проблеммами производительности. 

ALKS, скажи, как давно ты принимаешь участие в разработке упоминаемой системы? Сколько ещё человек принимают в этом участие? Сколько средств уже вложено в разработку и сколько ещё будет вложено? И сколько стоит сервер способный обрабатывать эти 50 запросов в секунду?

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

запускаеться на совершенно обычном сервере т.е. нет не на совсем обычном - это не сервер это вертуальный хост VMWare: 2х процессорный 4 Gb памяти. это абсолютно банальная машина. на таком хосте висит от 4 до 10 магазинов каждый из которых запущен как отдельный процесс. всего таких серверов у нас 4 на данный момент. общий трафик на пиках куда как больше 50 запросов на каждый сервер, это динамических страниц. а на HTTP сервер скажем нагрузка более чем на порядок большая. (уточняю: HTTP сервер установлен на кажом хосте ) .
на 1 магазин пик где-то 15 реквестов в секунду. БД вынесена на отдельный бокс такой же( только уже настоящий а не вертуальный. у вертуальных хостов очень паршивая скрость подсистемы ввода вывода - БД ставить нельзя  ) 2 сервера БД обслуживают все хосты. (причем 1 сервер БД обслуживает 3 хоста, и оставшийся - один, так уж получилось  )

никакого кластеринга и лоад-балансинга нету.

вообщем хардверная конфигурация очень простая. такие сервера стоят совершенные копейки. единственно конечно канал у нас толстый. точно не скажу, но порядка 40Mbit бэндвич.

p.s. Camel, 50 запросов в секунду, это совершенно обычная загрузка. это даже не средний уровень это меньше. крупные локальные порталы в европе например amazon.de или ebay.de имеют загрузка на 2 порядка большую, но там уже да - железо не такое простое. 

О чём я и говорю! Стоит ли ломать голову и копья в спорах о производительности, если железо копейки стоит. 

Camel, ты попался 

1. сервак стоит не дорого, а вот его хостинг - дорого.
2. чем больше серваков, тем дороже саппорт. стоимость сапорта серверов возрастает с их ростом не ленейно.
3. напрмиер, наши клиенты платят нам относительно фиксированную сумму за магазина + оплачивают траффик. причем суммы не звездные. мы кровно заинтересованы в том чтобы сервер тянул как можно больше магазинов - это наши прямые доходы.
  

Это сообщение отредактировал(а) ALKS - 25.5.2006, 17:04

А сколько стоит разработка? Сколько магазина платят вам за ПО, а сколько за железо и трафик?

разработка не стоит практически ничего. мы не продаем софт. клиент платит однакратную фиксированную стоимость за дизаин сайта и так скажем "запуск". это называеться "setup fee". за железо он не платит ничего - только оплачивает свой собственный трафик. ну и он еще кое что платит за процессинг заказов. ну скажем для примера $1 за каждый ордер.

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

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

и еще одно  - это очень распостранненая модель бизнеса, в сфера продажи IT услуг, а не IT софта . 

Ок, задам тот же вопрос другими словами: сколько вы вложили денег в разработку ПО (в зарплату программистов) и сколько вкладываете в железо и в оплату трафика? 

в разработку софта вложен по крайне мере миллион, точнее сказать не могу. но это на протяжении многих лет и это очень много различных систем а только видимый пользователю фронт-энд. это и ERP системы и очень много всякого. никто не сможет сказать сейчас размер инвестиций. кроме-того многое было оплачено не нами. если клиент просит какую-то функциональность которой нету - он за платит за её разработку. хостинг серверов, вертуальные хосты и траффик стоит более 10000 в месяц(я знаю что просто голый виртуал сервер стоит сам по себе $300 в месяц) причем это фиксированные затраты мы плятим их по любому есть у нас работа и прибыл или нет. плюс всячиские нюансы. вообщем в год выходит $150000.

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

M Cr@$h

Тема выделена из разговора о задачах, решаемых Ruby

МОгу добавить что тут еще есть и кеширование которое хорошо работает насчет скорости разработки так руби на рельсах дает скорость в несколько раз больше чем на других языках  
сам писал на PHP Perl 
руби рулит однозначно после знакомства сразу на него перешел  и новые проекты делаю уже на нем при чем заметно быстрее
так что и дешевле и быстрее и тд 
настраивать надо еще уметь

off
Смотрел недавно тесты... сравнивали апач, монгрел, вебрик, нгинх и лайтхттпд.
железо 2хголовый ксеон кажись... 2.4

в общем, лайтхттпд показал наилучшие результаты - а именно 956 реквестов-пер-секунда. IMHO очень и очень неплохо...

/off

Блин, устроили тут войну.
На деле всё просто - если производительность играет важную роль - выбираем высокопроизводительный язык и жертвуем удобством и скоростью разработки. Иначе работаем с удобными, но не настолько производительными языками.

Будущее, бесспорно, за удобством и скоростью разработки. Иначе все писали бы на ассемблере.

Самое забавное, что «высокая производительность» ассемблера — сильно раздутый миф. Конечно, можно на ассемблере написать копирование массива данных аж на 20% быстрее, чем простой memcpy на C (при том, что оптимизация меньше 40% как правило яйца выдеенного не стоит). Но реализовать сложный, нетривиальный алгоритм, который сократит вычисления на порядок… 

Serkys
Вы не совссем правы... это толькo студенты выбирают язык исходя из религиозных принципов, моды, перспективности, "удобства".... это из любопыства и потому что у них ещё огонь горит. 

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

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

а "удобность" это поверьте вещ субъективная... Есть же люди которым удобно только в vi и на чистом С. и уверяю - великолепный пишут код.

max_lapshin
уууу.... про асемблер это вы зря 
просто фирменный и до предела  вылезанный компилятор Intel С++(для примера) генерирует до крайности оптимизированный код. под процесооры Intel само собой. вот вы и не видите разницы в производительности программы на С++ и той же программы на ASM. (И даже больше вам скажу, запросто может случиться что прога на ASM будет ещё и медленней работать ибо рядовому программеру трудно сравниться с 20лет разрабатываемым сотнями людей С++ компилятором, зачастую) Но это хе хе не значит что даже такой совершенный (без всяких скидок) компайлер способен разрулить всё.

Читал я год назад удивительно увлекательную статью о том как ребята писали программу для расчётов на гиганских массивах целочисленных даных. так вот несколько функций в несколько 10ков строк каждая написанных на ASM c активным использованием команд процессора SSE подняла производительность приложения более чем на порядок. (к слову само приложение писали на Java) 
Никто не пишет приложения на ASM уже много 10ков лет (последний случай который я помню это OS Nowell Netware 2.0, которая была на ~30% написана на ASM) но ASM вставки и мелкие функции применяються сплош я рядом. любой серьезный графический редактор, 3D рендер, ГИС система, движек любой современной игры - без всяких сомнений. 
 
так что не стоит о "сильно раздутых мифах". всё таки прямой доступ к CPU иногда решает очень сильно... настолько сильно что можно закрыть глаза и на читабельностиь и на трудоемкость разработки и поддержки.

р.с. сорри за оффтоп, не удержался 

Если 2-х процовый кластер серъезная статья расходов, лечитесь.

Рельса для тех кто бережот свайо время.

И вообще-задели за живое.

90% людей которые пишут что Руби мол тормозит забывают 2 вещи.

1) Ява которую они пропагандируют тормозила нифига не меньше.
2) У большынцтва гаварунов нет ни одного (!!! убил бы) приложения которое в одиночку загрузит 1 сервер.
3) Что о серьозных приложениях то  investment banking company JPMorgan Chase юзает рельсу в полный рост и особо не 3.14здит о том какие у них серьозныи системы и отвецтвенные участки для проверенных временем языков... (Руби 10 лет ужо скоро)

Хм, недавно прочитал про то что теперь руби можно юзать под .net framework.
ruby.net
Что вы скажете про это?
Конечно, это не официальная реализация от Майкрософт, а только любительский проект, но всё же. Вот здесь можно почитать что говорит Майкрософт о поддержке динамических языков, в том числе руби.

Пока что, Ruby.NET — лишь тестовая разработка. JRuby куда как более развит, но он ещё не в состоянии пройти все тесты рельсов + его использование пока что чересчур сложное.