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

IT>В плане эффективных оптимизаций я доверяю компиляторам гораздо больше, чем Дворкину.

А компиляторы что, какие-то небожители пишут что ли?

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

AVK>Мне кажется, это только ты постоянно пытаешься соскочить с темы. А вот твои собеседники все таки говорят все о том же.

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

Я не пытаюсь соскочить с темы, я пытаюсь развить тему.

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

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

Нет, не кажется. Если тебе нечего сказать по теме — ну так и скажи.

Pzz>Я не пытаюсь соскочить с темы, я пытаюсь развить тему.

А выглядит это именно как попытка опять раздуть очередной винилин. Могу посоветовать только воспользоваться советом Антона и пойти в КСВ, там у тебя найдутся более сговорчивые партнеры.

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

AVK>Нет, не кажется. Если тебе нечего сказать по теме — ну так и скажи.

Хамить, мне кажется, совсем уж не обязательно. Если вам кажется, что я говорю не по теме, ну не читайте, кто ж просит?

AndrewVK,

AVK>Но, это, ты можешь продолжать и дальше, если хочешь. Я просто намекнул на крайне низкую, по моему мнению, эффективность подобных примеров при объяснении преимуществ ФП для неподготовленных людей.

Хорошо, Андрей, намёк понял.

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

AVK>>Нет, не кажется. Если тебе нечего сказать по теме — ну так и скажи.

Pzz>Хамить, мне кажется, совсем уж не обязательно.

Здесь нет никакого хамства.

Pzz> Если вам кажется, что я говорю не по теме, ну не читайте, кто ж просит?

Ты сам в этом признался

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

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

Pzz>>А если так: для любой программы на языке высокого уровня существует эквиавалентная программа на ассемблере, которая работает не хуже?

PD>А может, проще — для любой программы на языке ВУ существует эквивалентная программа на ассемблере, которая работает так же. Потому что программа на языке ВУ не работает вообще, а работает в конечном счете ассемблерный (машинный) код, порожденный из нее с помощью компиляторов. линкеров и прочих JIT'ов. Вот и возьмем эту эквивалентную программу в машинных кодах. Теперь одно из двух — либо ее нельзя улучшить (когда она уже в кодах), либо можно. Если верно первое — это значит, что компилятор и прочие создали такой код, который является идеальным, его же нельзя улучшить, так ? Из этого утверждения логически следует, что разрабатывать новые версии компилятора по крайней мере для этого процессора незачем, так как существующий компилятор уже создает идеальную программу. Если второе — доказано как минимум то, что существует программа, лучшая, чем создает компилятор. Это не помешает, конечно, улучшить компилятор, но после этого мы опять вернемся к исходной позиции. Вот и все доказательство теоремы.

Как написал IT это утверждение частично верно для одного наперед взятого компьютера/окружения.
Более того вы не учли что оптимальность машинного кода может зависить не только от программы, но и от входных данных. Яркий пример этому генерация сборок в ORMах для маппинга.

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

IT>>В плане эффективных оптимизаций я доверяю компиляторам гораздо больше, чем Дворкину.

Pzz>А компиляторы что, какие-то небожители пишут что ли?

Им я тоже доверяю больше, чем Дворкину.

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

Pzz>В качестве дидактического примера.
Плохой пример.

Pzz>Сколько раз вы еще зададите этот вопрос?
Столько, сколько раз ты попытаешься съехать с темы.

Pzz>Мы давно уже отошли от обсуждения,
"Мы — это кто?" (с) Лично я от обсуждения никуда не ухожу.

Pzz>То, что использование более высокоуровнего API всегда и по волшебству дает более эффективный результат — это неверное утверждение.
Кто такое утверждал и где?

Pzz>Я вам привел опровергающий пример.
А я доказал, что он не опровергающий.

Pzz>А я говорю, что привел. Что дальше делать будем?
Ну, приведи еще, с предыдущим у тебя промашка вышла.

Pzz>Почему?
По совокупности обстоятельств.

Pzz>Мы говорим о философии программирования.
Видимо, не со мной.

Pzz>Почему бы не говорить об этом на примере SQL-сервера?
Потому что реализация SQL-сервера не имеет к этому разговору отношения.

Pzz>Еще одно волшебство.
Удивительное рядом.

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

Pzz> Теперь вот БД, живущая в файле, оказывается более живучей, чем сам файл.
Именно так, просто она живет не в одном файле и реализует кучу механизмов обеспечения согласованности и отказоустойчивости.

Pzz>То, что ее чинить при необходимости проще.
Это тоже заблуждение. Вся индустрия БД на протяжении лет пятидесяти пахала на то, чтобы просто и качественно восстанавливаться после сбоя, тут наработок больше чем в любой другой области.

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

Pzz>>Мы давно уже отошли от обсуждения,
IB>"Мы — это кто?" (с) Лично я от обсуждения никуда не ухожу.

Тогда в чем предмет нашего обсуждения? В том, что мейлер, хорошо написаный на C# работает быстрее, чем мейлер, плохо написаный на C++. Ок. Работает. Быстрее. И чо?

Pzz>>То, что использование более высокоуровнего API всегда и по волшебству дает более эффективный результат — это неверное утверждение.
IB>Кто такое утверждал и где?

А что именно вы утверждаете?

Pzz>> Теперь вот БД, живущая в файле, оказывается более живучей, чем сам файл.
IB>Именно так, просто она живет не в одном файле и реализует кучу механизмов обеспечения согласованности и отказоустойчивости.

Расскажите мне еще сказку. Про то, как данные можно волшебным образом растолкать по файлам так, что они способны пережить смерть underlying file system.

Pzz>>То, что ее чинить при необходимости проще.
IB>Это тоже заблуждение. Вся индустрия БД на протяжении лет пятидесяти пахала на то, чтобы просто и качественно восстанавливаться после сбоя, тут наработок больше чем в любой другой области.

А индустрия ФС, наверное, все это время сухари сушила?

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

Pzz>Тогда в чем предмет нашего обсуждения?
В примере Синклера.

Pzz> В том, что мейлер, хорошо написаный на C# работает быстрее, чем мейлер, плохо написаный на C++. Ок. Работает. Быстрее. И чо?
Нет. В том что мейлер написанный с применением высокоуровневых абстракций работает быстрее, чем написанный в рукопашную с применением хардкорных оптимизаций.

Pzz>А что именно вы утверждаете?
1. Что пример Антона опровергает тезис Павла о неприменимости высокоуровневых абстракций при решении практических задач.
2. Что внутренне устройство сиквела не имеет к этому примеру никакого отношения.

Pzz>Расскажите мне еще сказку.
За сказками — не ко мне, добро пожаловать в реальный мир.

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

Pzz>> В том, что мейлер, хорошо написаный на C# работает быстрее, чем мейлер, плохо написаный на C++. Ок. Работает. Быстрее. И чо?
IB>Нет. В том что мейлер написанный с применением высокоуровневых абстракций работает быстрее, чем написанный в рукопашную с применением хардкорных оптимизаций.

Ну я и говорю, хорошо написаный работает лучше, чем плого написаный, не важно, на чем написан.

Pzz>>А что именно вы утверждаете?
IB>1. Что пример Антона опровергает тезис Павла о неприменимости высокоуровневых абстракций при решении практических задач.

Я что-то не припомню, чтобы Павел такое утверждал.

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

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

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

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

Pzz>Я что-то не припомню, чтобы Павел такое утверждал.
Я в принципе подозревал, что ты не только меня не читаешь.

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

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

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

А кто-то предлагает "выпиливать в ручную на низком уровне, оптимизируя все подряд"?

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

AVK>Как так, специалист по Немерле, и не знает, как тамошний компилятор устроен? ЕМНИП там есть функциональное RB-tree, неплохо работающее в том числе и в таких сценариях. Опять же — если не страдать пуризмом, то можно использовать классы с изменяемым состоянием, если они хорошо оттестированы, и демонстрируют эту изменяемость в крайне ограниченных пределах.
Вот статейка на эту тему.
Из нее следует что таки лучше страдать пуризмом.
Дешевле обойдется.

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

Pzz>А кто-то предлагает "выпиливать в ручную на низком уровне, оптимизируя все подряд"?
Да, Павел. И ты, судя по всему, активно отстаиваешь эту позицию, если конечно, внимательно прочитал за что споришь.

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

WH>Вот статейка на эту тему.
WH>Из нее следует что таки лучше страдать пуризмом.
WH>Дешевле обойдется.

Ты не мог бы вкратце рассказать суть? Читать 22 страницы текста как то лень.

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

Pzz>>А кто-то предлагает "выпиливать в ручную на низком уровне, оптимизируя все подряд"?
IB>Да, Павел. И ты, судя по всему, активно отстаиваешь эту позицию, если конечно, внимательно прочитал за что споришь.

Внимательно я не в состоянии прочитать — я как раз занят выпиливанием вручную того, что за меня ни один фреймворк не выпилит

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

Здравствуйте, Pzz, Вы писали:
Pzz>Какая разница, о разработчиках чего идет речь? Факт в том, что SQL реализует весьма высокоуровневую штуку, а пользоваться при реализации приходится уровнем абстракции даже более низким, чем то, с чем имеют дело обычные программы: не файлами, а блоками на диске.
Еще раз повторяю: ни с какими блоками на диске никто не возится. Сиквел использует ровно те же примитивы файловой системы, что и обычная прикладная программа.

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

PD>Нет, давай критерий. Ты же мою программу хочешь сравнить, так что давай критерий, а не слова. Это я на слова имею право, если буду доказывать теорему о существовании — она по определению не говорит, как это найти. А ты готов программу сравнивать. Критерий давай!

S>>Показываю, следим за руками:
S>>При запуске на 1 (одном) ядре, эта программа тратит X вычислительных ресурсов (временем я оперировать не буду, т.к. оно зависит много от чего еще).
S>>При этом непараллельная версия, которую ты привел, тратит X-delta ресурсов (например, потому что в ней нет WaitforMultipleObjects, нет динамического распределения памяти, да и вообще обращений к структурам chunk).

S>>Значит, она заведомо хуже, чем теоретически достижимый предел.

PD>Дай сначала определение ресурса (время тебя не устраивает, тогда что же это ?), тогда и поговорим. А пока это попытка доказать что-то с неопределенными утверждениями , используемыми для доказательства.
Слив засчитан.