Здравствуйте, IT, Вы писали:
R>>Что ты называешь заведомо кривым? Я уже перестаю улавливать параллель между аналогией и предметом нашего разговора.
IT>Что тут непонятного? Инструмент, которым ты пользуещься, кривой по определению.
Расскажи это людям, которые делают для тебя ОС, ран-таймы не кривых языков, и реализации продвинутых фич в не кривых языках, которые обеспечили наше общение на RSDN и т.д.
Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
Здравствуйте, IT, Вы писали:
IT>Это потому, что для этого нет адекватных средств. Точнее уже есть. Вот прямо сейчас я делаю язык для своих задач и работать он будет быстрее и надёжднее кода, написанного ручками, просто потому, что в ручном коде я должен беспокоиться ещё и о поддержке этого кода, в в сгенерированном мне это до лампочки.
Вот именно. Это то, о чём я тебе и говорю. Ты создаёшь средство, которое позволит писать программы на языке с высоким уровнем абстракции,
не используя промежуточных уровней, а используя кодогенерацию написанную специально для конкретного класса задач.
А теперь представь себе, что он генерирует код не для конкретно .NET или конкретно JVM, а для конкретной аппаратной платформы,
и даже для конкретного компьютера (с его конкретным числом ядер, размером памяти, кэша и прочее).
А теперь представь себе, что изготовители CPU тоже просекли фишку с адаптируемостью, и стали делать адаптируемые (конфигурирумые под
конкретные задачи) процессоры. И ты можешь писать макросы, которые будут при компиляции учитывать эти возможности.
Ты можешь оценить степень оптимизации подобного приложения по сравнению с существующими?
Вот код который я пишу, если бы я из него генерировал нэйтивный код, работал бы в разы быстрее. Потому как я на уровне компилятора (точнее, даже на уровне своих абстракций) могу доказать, что куча рантайм проверок не нужна, и организовать размещение данных в памяти намного эффективнее (дело даже не в её экономии, а и в скорости последовательного доступа, а не размазанности данных по хипу, и многих других возможностях). И занимал бы раза в 2-3 меньше памяти, следовательно и в кэш бы влазил лучше.
То есть просто за счёт отказа от ограничений JVM я бы уменьшил требования к ресурсам в несколько раз.
А если ещё сделать аппаратную поддержку часто используемых у меня примитивов — это ещё в несколько раз.
Грубо говоря — на порядок — легко.
А если поменять архитектуру процессора, который сейчас оптимизирован под максимально быстрое выполнение одного треда, то на том-же количестве транзисторов можно сделать раз в 10 больше ядер. Что ускорило бы выполнение моего кода раза в 3-4 как минимум.
IT>У вас какая-то неправильная практика
Понятно. Раз мои задачи не такие как твои, то и я какой-то неправильный.
IT>Это ты про "Hellow, World!"? А ты не пробовал сравнивать бизнес приложения, написанные на Java и на C? Как-нибудь попробуй.
См. выше.
IT>Ты хочешь сказать, что Aero в Висте написано на джаве?
Я хочу сказать, что он нафиг не нужен для выполнения 99% задач. А таскать его приходится всем.
Здравствуйте, remark, Вы писали:
IT>>Что тут непонятного? Инструмент, которым ты пользуещься, кривой по определению.
R>Расскажи это людям, которые делают для тебя ОС, ран-таймы не кривых языков, и реализации продвинутых фич в не кривых языках, которые обеспечили наше общение на RSDN и т.д.
Зачем мне это кому-то ещё рассказывать? Я рассказываю тебе. Ты сам много ОС, ран-таймов и продвинутых фич в языках написал, особенно, которые обеспечили наше общение на RSDN? Мне почему-то кажется ровно ни одной. Так откуда тебе знать какие ресурсы на это положены и сколько девелоперских жизней загублено?
R>Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mkizub, Вы писали:
M>А если поменять архитектуру процессора, который сейчас оптимизирован под максимально быстрое выполнение одного треда, то на том-же количестве транзисторов можно сделать раз в 10 больше ядер. Что ускорило бы выполнение моего кода раза в 3-4 как минимум.
Ну и какой из этого вывод?
IT>>У вас какая-то неправильная практика
M>Понятно. Раз мои задачи не такие как твои, то и я какой-то неправильный.
Я не говорил про задачи, я говорил про практику
IT>>Ты хочешь сказать, что Aero в Висте написано на джаве?
M>Я хочу сказать, что он нафиг не нужен для выполнения 99% задач. А таскать его приходится всем.
А при чём тут тогда разговоры о JVM?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
IT>>>Что тут непонятного? Инструмент, которым ты пользуещься, кривой по определению.
R>>Расскажи это людям, которые делают для тебя ОС, ран-таймы не кривых языков, и реализации продвинутых фич в не кривых языках, которые обеспечили наше общение на RSDN и т.д.
IT>Зачем мне это кому-то ещё рассказывать? Я рассказываю тебе.
Ясно, придётся говорить прямо: я имел в виду, что большая часть базовых уровней в программном стеке (драйвера, ОС, ран-таймы языков, сетевые сервера, сервера баз данных и т.д.) написаны на С/С++. Все эти вещи составляют основу в т.ч. и твоего ПО. Я правильно понимаю, что ты хочешь сказать, что это всё дерьмовое, кривое и работает ненадёжно?
IT>Ты сам много ОС, ран-таймов и продвинутых фич в языках написал, особенно, которые обеспечили наше общение на RSDN? Мне почему-то кажется ровно ни одной. Так откуда тебе знать какие ресурсы на это положены и сколько девелоперских жизней загублено?
Что бы понять, что на С/С++ можно создавать хорошее ПО не обязательно писать именно это. Я пишу другое, никаких жизней при этом не губится, и ПО получается вполне качественное, никаких особых проблем не встречается, память не течёт и т.д.
R>>Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
IT>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
Ну а ты что делаешь со своим ФЯ? Ты его бесконечно выпрямляешь? Тратишь на это тысячи человеко-лет?
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, IT, Вы писали:
IT>>У вас какая-то неправильная практика
M>Понятно. Раз мои задачи не такие как твои, то и я какой-то неправильный.
Не переживай, я по мнению IT тоже, видимо, неправильный — делаю только куски дерьма и пользуюсь кривыми по-определению инструментами...
Здравствуйте, remark, Вы писали:
R>Ясно, придётся говорить прямо: я имел в виду, что большая часть базовых уровней в программном стеке (драйвера, ОС, ран-таймы языков, сетевые сервера, сервера баз данных и т.д.) написаны на С/С++. Все эти вещи составляют основу в т.ч. и твоего ПО. Я правильно понимаю, что ты хочешь сказать, что это всё дерьмовое, кривое и работает ненадёжно?
Я хочу сказать, что если это и работает более менее надёжно, то только потому, что на это положены ресурсы неадекватные современным средствам разработки. К тому же это всё наследие, с которым приходится мириться, т.к. всё сразу переписать невозможно. Но былая популярность и легами не делает эти приложения супер надёжными и некривыми. К тому же большинство из них внутри могут оказаться редкосным дерьмом и кривизной. Да и надёжность вымученная, и не надёжная такая надёжность. На переполнении буферов выросла вся вирусная индустрия. Надёжность в операционках он нашёл, блин.
R>Что бы понять, что на С/С++ можно создавать хорошее ПО не обязательно писать именно это. Я пишу другое, никаких жизней при этом не губится, и ПО получается вполне качественное, никаких особых проблем не встречается, память не течёт и т.д.
Я тебя поздравляю. Ты довёл до совершенства своё умение ходить по граблям. Только грабли от этого никуда не делись.
IT>>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
R>Ну а ты что делаешь со своим ФЯ? Ты его бесконечно выпрямляешь? Тратишь на это тысячи человеко-лет?
Ты можешь продемонстрировать кривизну ФЯ? Давай, а мы послушаем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, remark, Вы писали:
R>Не переживай, я по мнению IT тоже, видимо, неправильный — делаю только куски дерьма и пользуюсь кривыми по-определению инструментами...
Присоединяюсь к компании неправильных . Впрочем, по мнению IT, судя по всему, есть для любой задачи 2 подхода — один его, другой неправильный
Здравствуйте, remark, Вы писали:
R>Иногда это может помочь, иногда помешать. Это палка о двух концах. Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
А попробую я некоторые соображения изложить. Благо SQL тут хороший пример , да и LinQ от него недалеко ушел.
В некотором смысле SQL — это понижение размерности задачи на 1. Иными словами, там, где в классических языках мы должны писать цикл, здесь обходимся без цикла
SELECT * FROM table WHERE cond // Где тут цикл, куда он пропал ?
for(int i = 0; i < table.size; i++)
if(table[i].cond)
result.Add(table[i];
Конечно, SQL сервер отнюдь не обязательно устроит линейный просмотр , но идея от этого не изменится. Как ни пиши — в императивном языке без цикла не обойдешься. А почему не обойдешься-то ? Потому что он тут по самой сути задачи присутствует. Ну нельзя выборку из таблицы сделать, не устроив хоть какого-то цикла.
Но SQL от нас все это скрывает. Программист на SQL (не очень хороший может , по крайней мере в теории, вообще не знать, что тут есть цикл. Но он все равно есть! SQL сервер сделал его за нас.
Налицо явное упрощение и SQL рулит! И LinQ как его наследник тоже.
Ну а если еще ORDER или GROUP добавить, то SQL с LinQ вообще рулят. Потому что на императивном языке тут и цикл будет посложнее, а может, и не один цикл понадобится.
Пока все замечательно.
Проблемы начинаются как только потребуется делать что-то, что не укладывается в условие "понизить размерность на единицу". Например, при необходимости работать с этой таблицей не как с массивом из фиксированного числа столбцов и произвольного числа строк, а наоборот. Или вообще с неопределенным числом и того, и другого. Или в ситуации, когда речь идет о каком-то произвольном движении — например, некие окна в этой матрице, плавно меняющие свои координаты и размеры. И т.д. И т.п. В этом случае парадигма понижения размерности на единицу начинает работать против программиста. Потому что с этими окнами хорошо бы ее понизить на 2 (и, кстати, такой язык сделать можно). А для более сложных алгоритмов ее вообще понижать не надо, поскольку это только проблемы создаст, а надо остаться на исходном уровне, и, простите, все ручками да ручками, потому что тут такая игра с индексами в этом массиве, что IEnumerable здесь имеет не больше смысла, чем топор для краснодеревщика.
Но! Для многих и очень многих (в особенности бизнес-)задач, понижение размерности на 1 оказывается очень удобным приемом. Отсюда и процветание SQL — для этих задач. Отсюда и (возможное) процветание LinQ. Те действия, которые адекватно укладываются в схему "понизить размерность на 1", могут быть очень хорошо внутри хоть SQL, хоть LinQ сделаны (иными словами, императивную часть сделали за нас), так что быстродействие будет вполне приличным. Как только мы уйдем от "понизить размерность на 1" — начнется борьба с языком во имя борьбы, с подобающим эффектом.
Так что не надо доводить все до абсурда. Есть некий инструмент — применяйте его там, где его применение оправданно и не лезьте с ним туда, где он совсем неуместен.
IT>>Скорее экстремально кривые. Ты всю память освободил в своих компонентах? Ничего больше не ликает? Ну так пойди и ещё раз проверь.
R>Да нет, ничего не ликает.
Ну как ты не понимаешь! Самое главное при строительстве Эйфелевой башни — это ответ на вопрос, не ушло ли некоторое количество материалов налево!
Подумал и решил на одно твое замечание ответить.
S>Другая категория людей — те, которым интересно получать более правильные решения. Такой человек может при выборе решения предпочитать рантайм-эффективность, удобство для пользователя, или простоту в поддержке. Это уже не так важно — важен сам интерес к улучшению. S>Вот такие люди как раз бросаются на новые изобретения, потому что им интересно улучшить свои решения.
Видишь ли, изобретение изобретению рознь. Если задача — улучшить свои решения, то первый вопрос к этому изобретению — а может ли оно дать такое улучшение ? Например, если речь идет (как в моей работе) о некотором достаточно сложном алгоритме обработки больших матриц, на что я должен бросаться и на что нет ?
На многопоточность — да. Если бы я о ней не знал, и мне бы кто-то сказал, что можно так распараллелить — я должен немедленно этим заняться.
На SSE2 — да. По той же причине.
На матричные процессоры — да. И когда мне заказчик предложил использовать CUDA, я немедленно согласился. Даст это что-то или нет — вопрос сложный, пока не попробуешь — не поймешь (сейчас уже могу сказать — даст).
А вот на Java, C#, LinQ, Хаскель и т.д — нет. Потому что априорно ясно, что в этой задаче от них никакой пользы не будет.
А могут быть ситуации в точности наоборот. Вот представь себе программиста, которого "заморозили" с 80-х годов. Он тогда на С++ CGI-сайты писал, и до сих пор их пишет . И тут ему говорят, что есть , мол, гораздо более эффективные средства это делать. Он должен немедленно за эти средства сесть и их изучать. А вот если ему предложать эти CGI программы улучшать, перейдя с C++ на asm, то он должен советчика послать туда же, куда я должен послать того, кто мне порекомендует делать сложную обработку матрицы с требованиями наивысшего быстродействия на Java или C#.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>В некотором смысле SQL — это понижение размерности задачи на 1.
Не могу согласиться. Ты же дальше сам приводишь примеры про join и group — где там на 1? Там и на 10 может понизиться.
Или я неправильно понимаю понятие "размерности задачи"?
Далее. Про "невозможность выбрать данные из таблицы без цикла" мне совершенно непонятно. Эдак рассуждая, и умножить два числа без цикла нельзя — там же сложения и сдвиги. Впрочем, сложение без цикла тоже не организуешь, потому что он там присутствует "по самой сути задачи". Помните, как в первом классе учили сложению в столбик? Ведь самый был натуральнейший цикл.
Тем не менее, никто при программировании не задумывется о природе циклов для сложения и умножения. Тем более, что "линейный просмотр" процессору организовывать не обязательно.
Поэтому не мог ли бы ты поподробнее осветить насчет "понижения размерности на два" и прочих высокофилософских терминов?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Видишь ли, изобретение изобретению рознь. Если задача — улучшить свои решения, то первый вопрос к этому изобретению — а может ли оно дать такое улучшение ? Например, если речь идет (как в моей работе) о некотором достаточно сложном алгоритме обработки больших матриц, на что я должен бросаться и на что нет ?
Это зависит от очень большого количества факторов, которые ты тщательно скрываешь. PD>На многопоточность — да. Если бы я о ней не знал, и мне бы кто-то сказал, что можно так распараллелить — я должен немедленно этим заняться. PD>На SSE2 — да. По той же причине. PD>На матричные процессоры — да. И когда мне заказчик предложил использовать CUDA, я немедленно согласился. Даст это что-то или нет — вопрос сложный, пока не попробуешь — не поймешь (сейчас уже могу сказать — даст). PD>А вот на Java, C#, LinQ, Хаскель и т.д — нет. Потому что априорно ясно, что в этой задаче от них никакой пользы не будет.
Вот простой вымышленный пример: пусть у нас основная задача — перемножать матрицы. Большого размера и в больших количествах.
Но при анализе мы выясняем, что заметная доля этих матриц — единичные или нулевые.
Тогда у нас возникает искушение подправить наши алгоритмы так, чтобы они учитывали этот факт. И цепочка A*B*C*D*E вычислялась бы значительно быстрее, если B и D равны I. А если любая из матриц — нулевая, то вся цепочка бы вычислялась мгновенно.
На языках с развитой системой типов (например, Хаскеле) мы могли бы обеспечить это даже статически.
На С++ — только в рантайме, и только тщательным выверением всех алгоритмов.
PD>А могут быть ситуации в точности наоборот. Вот представь себе программиста, которого "заморозили" с 80-х годов. Он тогда на С++ CGI-сайты писал, и до сих пор их пишет . И тут ему говорят, что есть , мол, гораздо более эффективные средства это делать. Он должен немедленно за эти средства сесть и их изучать. А вот если ему предложать эти CGI программы улучшать, перейдя с C++ на asm, то он должен советчика послать туда же, куда я должен послать того, кто мне порекомендует делать сложную обработку матрицы с требованиями наивысшего быстродействия на Java или C#.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот на Java, C#, LinQ, Хаскель и т.д — нет. Потому что априорно ясно, что в этой задаче от них никакой пользы не будет.
Хаскель может и помочь. Например, ты можешь сделать набор высокопроизводительных базовых операций с матрицами, а комбинировать их в сложные алгоритмы уже на Хаскеле. Никто не отменял возможности использовать сишные библиотеки, там где надо работать с железом или на максимум загрузить процессор и т.п. Подключить эту либу можно конечно и к жаве с додиезом, но таких возможностей как Хаскелл они не дадут.
Поможет это или нет в твоём конкретном случае — . Всё зависит от задачи.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, IT, Вы писали:
IT>>Это потому, что для этого нет адекватных средств. Точнее уже есть. Вот прямо сейчас я делаю язык для своих задач и работать он будет быстрее и надёжднее кода, написанного ручками, просто потому, что в ручном коде я должен беспокоиться ещё и о поддержке этого кода, в в сгенерированном мне это до лампочки.
M>Вот именно. Это то, о чём я тебе и говорю. Ты создаёшь средство, которое позволит писать программы на языке с высоким уровнем абстракции, M>не используя промежуточных уровней, а используя кодогенерацию написанную специально для конкретного класса задач. M>А теперь представь себе, что он генерирует код не для конкретно .NET или конкретно JVM, а для конкретной аппаратной платформы, M>и даже для конкретного компьютера (с его конкретным числом ядер, размером памяти, кэша и прочее). M>А теперь представь себе, что изготовители CPU тоже просекли фишку с адаптируемостью, и стали делать адаптируемые (конфигурирумые под M>конкретные задачи) процессоры. И ты можешь писать макросы, которые будут при компиляции учитывать эти возможности. M>Ты можешь оценить степень оптимизации подобного приложения по сравнению с существующими?
Ну так ты же только что доказал опровержение своего собственного утверждения. Ты рассказал про язык с высоким уровнем абстракции, который генерирует высокооптимизированный код. Если уровень абстракции языка недостаточно высок, он будет генерировать неоптимальный код.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>Это зависит от очень большого количества факторов, которые ты тщательно скрываешь.
Безусловно
S>Вот простой вымышленный пример: пусть у нас основная задача — перемножать матрицы. Большого размера и в больших количествах. S>Но при анализе мы выясняем, что заметная доля этих матриц — единичные или нулевые. S>Тогда у нас возникает искушение подправить наши алгоритмы так, чтобы они учитывали этот факт. И цепочка A*B*C*D*E вычислялась бы значительно быстрее, если B и D равны I. А если любая из матриц — нулевая, то вся цепочка бы вычислялась мгновенно.
S>На языках с развитой системой типов (например, Хаскеле) мы могли бы обеспечить это даже статически. S>На С++ — только в рантайме, и только тщательным выверением всех алгоритмов.
Да какая такая выверка нужна ? Банальная проверка и все. Да, в рантайме.
Если нам не помогут, то мы тоже никого не пощадим.
