Здравствуйте, remark, Вы писали:
R>Но важный момент — насколько сложно без этой помощи? нет, не в абстрактных терминах, а в терминах реального программиста реализующего что-то реальное, сколько времени у него ушло? сколько моральных сил у него ушло? результат какого качества удалось получить? Далее — насколько это помощь именно в том, в чём разработчику хотелось и требуется?
Мне как реальному программисту FP вообще и immutable стиль в частности реально помогает. И даже не в распараллеливании. А просто в процессе кодирования.
R>Так же хороший вопрос — а что если компилятор мне не помагает, а мешает?
Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>Но важный момент — насколько сложно без этой помощи? нет, не в абстрактных терминах, а в терминах реального программиста реализующего что-то реальное, сколько времени у него ушло? сколько моральных сил у него ушло? результат какого качества удалось получить? Далее — насколько это помощь именно в том, в чём разработчику хотелось и требуется?
IT>Мне как реальному программисту FP вообще и immutable стиль в частности реально помогает. И даже не в распараллеливании. А просто в процессе кодирования.
R>>Так же хороший вопрос — а что если компилятор мне не помагает, а мешает?
IT>Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
Здравствуйте, remark, Вы писали:
IT>>Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
R>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
Это следствие ограниченности. Тот компилятор, который мне раньше вроде бы как не мешал сейчас мешает, а тот который раньше мешал реально помогает. Парадокс. Про C++ я вообще молчу. Я почти 15 лет считал плюсы абсолютным совершенством, пока не увидел другой мир. И оказалось, что плюсы — это поле с граблями, а виртуозное владение плюсами — это всего лишь виртуозное хождение по граблям. Короче, не начинай
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, fddima, Вы писали:
F> Просто тут вот, я с появления темы ждал высказывания Влада, о "преимуществах", и таки оно прозвучало... в иммутабельности! Честно говоря и самому оно в голову пришло. А следом... пришло и другое — получается как несколько лет назад, кричим лозунги, а что они значат — мы не понимаем, то память не ресурс, теперь ФП популяризируется, однако доводов нет. Никаких нет.
Доводов мильён. В том числе и в этом форуме. В частности, я приводил код, который легко параллелится и в три раза короче императивного аналога. Но, проблема в том, что чтобы эти доводы увидеть нужно открыть глаза, а не посильнее зажмуриться.
F>Никаких адекватных не сравнений и тестов. Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации.
У иммутабельности, как я уже говорил, есть ещё одно преимущество. В этом стиле банально легче писать код, т.к. весь контекст до неприличия постоянен и мне не откуда ждать подвоха. Если я могу дотянуться до одной и той же переменной из двух веток кода, то мне даже думать не надо, в ней будет одно и тоже значение, что нельзя сказать об императиве, где я должен всегда держать в голове весь контекст со всеми его состояниями. Такая же ситуация с модификацией кода. Достаточно затолкать уже существующий рабочий блок кода в существующий контекст, чтобы бы быть уверенным, что этот блок будет работать без сюрпризов.
Но как тебе это продемонстрировать и какие тесты и сравнения показать, я не знаю
F> Меня конечно можно упрекнуть в том или ином искажении реальности, просто каждая гарная фича несёт за собой расплату. И как сборка мусора несёт за собой свои нюансы, так и иммутабельность. Просто мне не нравится что её подают как решение проблем распараллеливания.
Думаю, ты сам себе придумал про решение проблем. Иммутабельность помогает в решении этих проблем и помогает не слабо, но не решает их.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
М-да... Интересно, кто вот это написал ?
>Тот же самый алгоритм расчёта нелюбимых тобой процентов, который я привёл, ускоряется в разы в зависимости от количества ядер путём внесения маленького изменения в код, состоящего из вызова одного метода AsParallel.
Так ускоряется в разы в зависимости от количества ядер путём внесения маленького изменения или все же необходим целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр ?
Здравствуйте, fddima, Вы писали:
F> Просто тут вот, я с появления темы ждал высказывания Влада, о "преимуществах", и таки оно прозвучало... в иммутабельности! Честно говоря и самому оно в голову пришло. А следом... пришло и другое — получается как несколько лет назад, кричим лозунги, а что они значат — мы не понимаем, то память не ресурс, теперь ФП популяризируется, однако доводов нет. Никаких нет. Никаких адекватных не сравнений и тестов. Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации. F> Меня конечно можно упрекнуть в том или ином искажении реальности, просто каждая гарная фича несёт за собой расплату. И как сборка мусора несёт за собой свои нюансы, так и иммутабельность. Просто мне не нравится что её подают как решение проблем распараллеливания.
Просто есть люди, которые с радостью кидаются на каждое новое "изобретение". Оно им нравится по двум причинам. Во-первых, оно новое, а это им импонирует. Во-вторых, оно, как правило, упрощает написание кода, а это для них немаловажно. Что же касается производительности (или расхода памяти и т.д.) — это они просто во внимание принимать не хотят. Ситуация чем-то напиминает ситуацию в экономике — когда цена на нефть $150, можно все себе позволить, а когда она $50 — надо очень аккуратно действовать и понапрасну деньгами не сорить. Мы в последнее десятилетие имели тот же бешеный рост производительности и объема памяти, в результате чего приличная часть этого ресурса была израсходована на всякие вещи, упрощающие жизнь программиста , а не улучшающие качество программ. В итоге сейчас мы имеем ситуацию, когда программное обеспечение потребляет намного больше ресурсов, чем реально необходимое. Проще говоря, нам дали самолет, а мы на нем в магазин ездим, но поскольку в магазин летать незачем, то этот самолет мы используем как автомобиль.
Когда же эпоха тучных коров заканчивается и наступает эпоха тощих коров, тогда начинают вспоминать, что и с тощих коров можно все же и молоко и мясо получить, если их правильно кормить и доить. И тогда начинают заботиться не столько о том, насколько удобно доярке вставать в 5 утра, а о том, какой цикл дойки коров является наилучшим.
Именно это получилось с памятью. Память резко возросла, и появилось желание тратить ее бесконтрольно. "Память больше не ресурс". Появилось такое желание — есть такие средства. Тратим 100 Мб там, где надо 20Мб — чего ее жалеть! Если бы ее действительно 20 было — еще как бы жалели, а когда ее не то 2048, не то 4096 — незачем! Используем ее расточительно до не могу. Сейчас то же самое про ядра начали. Есть ядра — надо их использовать. Как именно — не так важно, получается ли при этом линейная зависимость производительности от их числа или же мы имеем ситуацию, когда они друг с другом ссорятся, а в итоге производительность очень слабо растет — это тоже не так важно. В целом рост все же будет, конечно, по сравнению с однопоточным приложением, а поэтому можно и объявить, что мы, мол, достигли успеха, и посмотрите, какими простыми средствами!
А вот когда приходится решать задачи, в которых нужно от компьютера взять все, что он может (как твой рейтрейсер) — тогда все эти рассуждения летят к чертовой бабушке.
Что будет дальше — зависит от двух факторов. Первый — это как будет расти производительность компьютеров, а второй — какие задачи будут на повестке дня. Если быстродействие будет так же расти, как оно росло — неэффективные решения будут жить и процветать. Если задачи не будут требовать эффективного использования ресурсов — тоже. Если же рост производительности замедлится (это скорее всего), а задачи усложнятся (а вот это большой вопрос) — тогда все эти неэффективные решения полетят к той же бабушке, а на повестку дня выйдут опять-таки эффективные решения. Если все же надо летать, то надо из этого двигателя выжать 800 км/час, даже если пилоту будет намного сложнее работать, чем водителю Жигулей.
F> И у мну с Мамутом возник вопрос — а что происходит-то с реальными параметрами в функции? раз оно иммутабельно их можно не копировать? Дима ответ не знал, кроме того что в процессах там всегда копирование, а что внутри — бог его знает. Всё зависит от компилятора/интерпретатора ФП получается. Как мне это напоминает долгие рассказы в этом форуме про возможности оптимизатора дотнета... а на практике ж ничего нет.
Будет потребность — будет оптимизатор. Пока ее нет — не будет. А потребность будет, когда станет ясно, сколько из-за его отсутствия теряем, и когда нам это потерянное жалко станет, потому что именно его и не хватать будет. Как с твоим рейстрейсером — ты его "оптимизировал", переведя с Эрланга на С++
F> Если кого-то прямо или косвенно обидел, то не со зла.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Просто есть люди, которые с радостью кидаются на каждое новое "изобретение". Оно им нравится по двум причинам. Во-первых, оно новое, а это им импонирует. Во-вторых, оно, как правило, упрощает написание кода, а это для них немаловажно. Что же касается производительности (или расхода памяти и т.д.) — это они просто во внимание принимать не хотят. Ситуация чем-то напиминает ситуацию в экономике — когда цена на нефть $150, можно все себе позволить, а когда она $50 — надо очень аккуратно действовать и понапрасну деньгами не сорить. Мы в последнее десятилетие имели тот же бешеный рост производительности и объема памяти, в результате чего приличная часть этого ресурса была израсходована на всякие вещи, упрощающие жизнь программиста , а не улучшающие качество программ. В итоге сейчас мы имеем ситуацию, когда программное обеспечение потребляет намного больше ресурсов, чем реально необходимое. Проще говоря, нам дали самолет, а мы на нем в магазин ездим, но поскольку в магазин летать незачем, то этот самолет мы используем как автомобиль. PD>Когда же эпоха тучных коров заканчивается и наступает эпоха тощих коров, тогда начинают вспоминать, что и с тощих коров можно все же и молоко и мясо получить, если их правильно кормить и доить. И тогда начинают заботиться не столько о том, насколько удобно доярке вставать в 5 утра, а о том, какой цикл дойки коров является наилучшим.
Не знаю, не знаю.
По моим впечатлениям, люди делятся на два, условно говоря, лагеря.
Первый лагерь — это люди, которым важно, чтобы решение работало вообще хоть как-нибудь.
Им неинтересно улучшать существующее решение до тех пор, пока их не бьют палкой, и неинтересно выбирать более хорошее решение из нескольких альтернатив.
Им вообще мешают альтернативы, потому что они требуют думать и делать выбор.
Такие люди не бросаются ни на какие изобретения, просто потому, что им это неинтересно. Они и под С++ пишут строго на С, потому что учить новое им ленивее, чем писать по-старому.
Другая категория людей — те, которым интересно получать более правильные решения. Такой человек может при выборе решения предпочитать рантайм-эффективность, удобство для пользователя, или простоту в поддержке. Это уже не так важно — важен сам интерес к улучшению.
Вот такие люди как раз бросаются на новые изобретения, потому что им интересно улучшить свои решения.
Вот простой пример — люди смотрят на 4GB памяти и говорят "о, круто. Раньше мы не могли себе позволить выполнять глобальные оптимизации в компиляторе потому, что ему не хватало памяти, и приходилось ограничиваться локальным анализом. Теперь мы можем проводить глобальные оптимизации, и получать код, потребление памяти которым в рантайме гарантированно минимально".
Вон, у Ершова есть пример для детей о том, как задача распределения памяти под переменные программы сводится к раскраске рёбер графа. Ну так и возможность решать эту задачу напрямую зависит от того, насколько большие графы может себе позволить ворочать компилятор.
Или говорят "о, раньше у нас не было средства на лету генерировать код, и приходилось заниматься оптимизацией вслепую, либо применять интерпретатор. Теперь у нас есть среда со встроенным компилятором; это позволит нам генерировать программы, которые гарантированно рвут по производительности оба старых варианта".
Вот подскажи мне, как эксперт по C++, какая там самая быстрая библиотека регулярных выражений? Используется ли там runtime-кодогенерация?
PD>Именно это получилось с памятью. Память резко возросла, и появилось желание тратить ее бесконтрольно.
Не то чтобы прямо так желание. Появилась возможность не думать о памяти вообще; и некоторые люди из первой категории стали этим злоупотреблять.
Ты просто сваливаешь в одну кучу два разных явления. В одном случае люди осознанно используют доступную память, например организуют агрессивное кэширование для достижения высокой производительности. А в другом люди просто забивают память, не думая ни о чем вообще.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Именно это получилось с памятью. Память резко возросла, и появилось желание тратить ее бесконтрольно. "Память больше не ресурс". Появилось такое желание — есть такие средства. Тратим 100 Мб там, где надо 20Мб — чего ее жалеть! Если бы ее действительно 20 было — еще как бы жалели, а когда ее не то 2048, не то 4096 — незачем! Используем ее расточительно до не могу. Сейчас то же самое про ядра начали. Есть ядра — надо их использовать. Как именно — не так важно, получается ли при этом линейная зависимость производительности от их числа или же мы имеем ситуацию, когда они друг с другом ссорятся, а в итоге производительность очень слабо растет — это тоже не так важно. В целом рост все же будет, конечно, по сравнению с однопоточным приложением, а поэтому можно и объявить, что мы, мол, достигли успеха, и посмотрите, какими простыми средствами!
Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура.
А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому.
Это "по-другому" как раз и выльется в использование еще большего объема памяти.
PD>Что будет дальше — зависит от двух факторов. Первый — это как будет расти производительность компьютеров, а второй — какие задачи будут на повестке дня. Если быстродействие будет так же расти, как оно росло — неэффективные решения будут жить и процветать. Если задачи не будут требовать эффективного использования ресурсов — тоже. Если же рост производительности замедлится (это скорее всего), а задачи усложнятся (а вот это большой вопрос) — тогда все эти неэффективные решения полетят к той же бабушке, а на повестку дня выйдут опять-таки эффективные решения. Если все же надо летать, то надо из этого двигателя выжать 800 км/час, даже если пилоту будет намного сложнее работать, чем водителю Жигулей.
Что значит "эффективные"?
PD>Будет потребность — будет оптимизатор. Пока ее нет — не будет. А потребность будет, когда станет ясно, сколько из-за его отсутствия теряем, и когда нам это потерянное жалко станет, потому что именно его и не хватать будет. Как с твоим рейстрейсером — ты его "оптимизировал", переведя с Эрланга на С++
Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти.
Здравствуйте, gandjustas, Вы писали:
G>Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура.
Гм. Никто не мешает перейти на x64 архитектуру, где ограничений нет никаких практически. Но почему-то не переходят. Точнее, 64-битные версии XP и Vista используются уже довольно широко, а вот 64-битные программы все же пока менее популярны, и намного менее.
G>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому.
+1
G>Это "по-другому" как раз и выльется в использование еще большего объема памяти.
-1. Совсем не обязательно.
PD>>Что будет дальше — зависит от двух факторов. Первый — это как будет расти производительность компьютеров, а второй — какие задачи будут на повестке дня. Если быстродействие будет так же расти, как оно росло — неэффективные решения будут жить и процветать. Если задачи не будут требовать эффективного использования ресурсов — тоже. Если же рост производительности замедлится (это скорее всего), а задачи усложнятся (а вот это большой вопрос) — тогда все эти неэффективные решения полетят к той же бабушке, а на повестку дня выйдут опять-таки эффективные решения. Если все же надо летать, то надо из этого двигателя выжать 800 км/час, даже если пилоту будет намного сложнее работать, чем водителю Жигулей. G>Что значит "эффективные"?
PD>>Будет потребность — будет оптимизатор. Пока ее нет — не будет. А потребность будет, когда станет ясно, сколько из-за его отсутствия теряем, и когда нам это потерянное жалко станет, потому что именно его и не хватать будет. Как с твоим рейстрейсером — ты его "оптимизировал", переведя с Эрланга на С++
G>Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти.
А я о памяти и не говорил в этом случае. fddima не дал мне никаких оснований о ней говорить.
Мне кажется, мы здесь просто о разных вещах говорим. Ты — о подходе со стороны разных категорий разработчиков (и в общем ты прав, хот с деталями можно поспорить), я — о ситуации с ресурсами и задачами. Эти области пересекаются, но не совпадают.
Насчет библиотеки по регулярным выражениям — я с ними дел не имею и они мне даром не нужны. У меня совсем другие задачи, текстовой обработкой я не занимаюсь. Спроси тех, кто с ними работает.
Здравствуйте, gandjustas, Вы писали:
G>Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура.
Не уверен. G>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается.
Имхо, это связано с тем, что это быстродействие просто нечем нагрузить. Какой толк от увеличения тактовой частоты вдвое, если память всё равно не успевает "подвозить" данные?
G>Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому.
Тут есть небольшая тонкость. Одно дело — несколько процессоров, другое — несколько ядер. G>Это "по-другому" как раз и выльется в использование еще большего объема памяти.
Вот в этом месте мне не до конца понятно. Ну вот увеличишь ты объем памяти до 64Гб. А толку, если ее доставка в CPU займет в 16 раз больше времени, чем для 4Гб? Независимо от того, о скольких CPU мы говорим.
G>Что значит "эффективные"?
Это значит, что решения будут учитывать latency памяти, приколы с шедулингом на соседних ядрах и далёких процессорах, а также разнообразные подходы к перестройке алгоритма в зависимости от окружения.
Ситуация примерно такая же, как с многомерными индексами в СУБД. Для размерности =1 известны превосходные решения с логарифмическими характеристиками; для двух есть приемлемые решения; для размерностей выше десяти прямой перебор оказывается быстрее, чем любой индекс.
G>Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти.
Не очень понятно, что такое "быстрый/медленный". Если мы будем заниматься математическими микробенчмарками — эрланг проиграем. А если задачами массового обслуживания, то на плюсах придется сильно попотеть для догоняния Эрланга.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
PD>Из этой ситуации есть два выхода.
PD>1. Поменять компилятор. PD>2. Поменять того, кто с этим компилятором работает.
Ответ неверный, садись, два. Правильный ответ — время от времени нужно апгрейтить мозги, а не пользоваться всю жизнь устаревшей моделью сороколетней давности.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так ускоряется в разы в зависимости от количества ядер путём внесения маленького изменения или все же необходим целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр ?
Что именно тебе не понятно в первом или во втором высказывании?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура. S>Не уверен.
Возможно.
G>>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. S>Имхо, это связано с тем, что это быстродействие просто нечем нагрузить. Какой толк от увеличения тактовой частоты вдвое, если память всё равно не успевает "подвозить" данные?
Ни разу не видел чтобы программа серьезно тормозила из-за низкого быстродейсвтия самой памяти (синтетические тесты с кеш-промахами не в счет).
G>>Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому. S>Тут есть небольшая тонкость. Одно дело — несколько процессоров, другое — несколько ядер.
Нутут еще одна тонкость. Одно дело фичиеские ядра в процессоре, а другое дело логические. Но эти тонкости покачто мало интересуют.
G>>Это "по-другому" как раз и выльется в использование еще большего объема памяти. S>Вот в этом месте мне не до конца понятно. Ну вот увеличишь ты объем памяти до 64Гб. А толку, если ее доставка в CPU займет в 16 раз больше времени, чем для 4Гб? Независимо от того, о скольких CPU мы говорим.
Обычно средние затраты на считывание-запись в памяти очень малы по сравнению выполнением какого-либо алгоритма.
G>>Что значит "эффективные"? S>Это значит, что решения будут учитывать latency памяти, приколы с шедулингом на соседних ядрах и далёких процессорах, а также разнообразные подходы к перестройке алгоритма в зависимости от окружения. S>Ситуация примерно такая же, как с многомерными индексами в СУБД. Для размерности =1 известны превосходные решения с логарифмическими характеристиками; для двух есть приемлемые решения; для размерностей выше десяти прямой перебор оказывается быстрее, чем любой индекс.
Ну и как в СУБД нам совершенно необязательно чтобы алгоритм учитывал все, досаточно чтобы он работал не намного хуже теоретического предела.
G>>Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти. S>Не очень понятно, что такое "быстрый/медленный". Если мы будем заниматься математическими микробенчмарками — эрланг проиграем. А если задачами массового обслуживания, то на плюсах придется сильно попотеть для догоняния Эрланга.
Рассматривался рэйтресер — программа, которая много считала.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Во-вторых, оно, как правило, упрощает написание кода, а это для них немаловажно.
Вы так говорите, как будто это что-то плохое. Сокращать затраты на написание кода, удобство поддержки, тестирования и отладки — это очень важно.
PD>Что же касается производительности (или расхода памяти и т.д.) — это они просто во внимание принимать не хотят.
Это Вы так зря. Преждевременная оптимизация — это дело неблагодарное. А выбор якобы более быстрого и экономного по памяти средства разработки без рассмотрения специфики задачи — это и есть преждевременная оптимизация. Оптимизировать надо то, что является узким местом. Зачем оптимизировать свой код, если большую часть процессорного времени и памяти съедает СУБД, веб-сервер или что-нить подобное?
PD>приличная часть этого ресурса была израсходована на всякие вещи, упрощающие жизнь программиста , а не улучшающие качество программ.
Качество программы — это не только ее требования к ресурсам, но и юзабилити, отсутствие багов, функциональность, стоимость и т.п. А последние четыре пункта часто напрямую зависят от того, насколько хорошо живется программисту.
PD>Тратим 100 Мб там, где надо 20Мб — чего ее жалеть!
Смотря на что тратится память.
PD>А вот когда приходится решать задачи, в которых нужно от компьютера взять все, что он может (как твой рейтрейсер) — тогда все эти рассуждения летят к чертовой бабушке.
Интересно, а как бы в этой задаче выглядел OCaml?
PD>какие задачи будут на повестке дня.
С чего бы разнообразию задач сократиться?
Если нам не помогут, то мы тоже никого не пощадим.
