Здравствуйте, IT, Вы писали:
IT>Я никуда не ухожу. Меня интересует прежде всего эффективность всего решения. Если к системе предъявляются серьёзные нефункциональные требования и заказчик за это готов платить, то он это получит, не переживай.
Что за нефункциональные требования у тебя там могут быть — не знаю и не хочу обсуждать. Я говорил именно о функциональных требованиях. Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее.
IT>Конечно, возможна, я это вполне допускаю. Но как я уже сказал такое встречается довольно редко. Ты же пытаешься распространить свой крайний случай на всё программирование в мире.
Давай точки над i расставим.
Я не пытаюсь распространить свой крайний случай на всё программирование в мире. Ни в коем разе!
Я не пытаюсь доказать, что С++ нужно использовать для написания сайтов.
И т.д. я не пытаюсь.
Я просто утверждаю, что для разного рода задач нужны и должны использоваться свои инструменты. Где-то лучше всего Питон, а где-то С. Для данной задачи что лучше — Питон или С — обсуждать имеет смысл , если знать задачу, иначе не стОит. Поэтому априорные, без знания задачи, рекомендации неуместны.
А часто ли нужен Питон, С, С# или Хаскель — так ли это важно ? Для конкретной задачи и будем решать. А для другой будем решать заново.
И если ты готов то же самое повторить, иными словами, под этим подписаться — тогда нечего больше обсуждать.
Покажи мне хоть одно место, где я предлагал изничтожить, к примеру, C#. Не найдешь.
А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ?
Так кто из нас терпимее к чужим мнениям ?
Вы ей-богу, как ранние христиане. Вам надо во что бы то ни стало все языческие культы изничтожить. Я (как язычник) говорю вам — ничего не имею против вашего бога, у меня богов много, одних я люблю больше, других меньше, я и вашего в этот сонм добавлю. А мне в ответ — веруй только в одного нашего бога, а иначе...
IT>А при чём здесь ты? Твои задачи — это капля в море и почему на эту каплю должно равняться всё море.
См. выше.
PD>>В теории совершенно верно, а практически не всегда возможна. Например, обработка производится 3dparty lib, свою написать — годы понадобятся, да и будет ли лучше... а вот оптимизировать то, что от меня зависит, я могу. Даже если это 1-2%.
IT>Да сколько угодно. Только то, что ты оптимизируешь сегодня под имеющееся у тебя железо, не факт что будет работать быстрее на завтрашнем.
Мне сегодня надо чтобы работало. Завтра видно будет. Завтра будут другие задачи и другие деньги.
PD>>Не согласен. Они определяются тем, насколько инструмент близок по своему духу машинному языку. Чем ближе — тем больше у меня возможностей, не переходя или почти не переходя на асм, написать наилушим образом. Что же касается выразительных и простых конструкций иных языков, то эта простотоа и ясность, вполне приемлемые в иных случаях, здесь проигрывают. По той простой причине, что высокоуровненвые конструкции неизбежно компилируются неким стандартным образом, без учета конкретной специфики. Ее полностью можно учесть в идеале на асме, а в реальности — на очень низкоуровневом ЯВУ.
IT>Под оптимизацию стандартных высокоуровневых конструкций, если ты не знал, затачиваются внутренности процессоров.
Расскажи подробнее, какие именно внутренности процессора заточены под ваш любимый SELECT из Linq.
>Ещё год назад ты говорил о 5%, сегодня уже об 1-2%, а что будет ещё через пару лет?
О чем речь идет-то ? В предыдущей моей фразе про проценты ни слова.
PD>>С точностью до наоборот.
IT>А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории?
C#, Java, Fortran, PL/1, VB,, Asm, ну и кое-что по мелочи.
IT>>>До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет.
PD>>А что поможет ?
IT>Поможет пересмотр архитектуры.
А если ее нельзя пересмотреть ?
PD>>Задачи разные бывают.
IT>Это правда, только понимаешь ты это очень однобоко. Складывается впечатление, что они только у тебя разные бывают, а у остальных в точности такие как у тебя и другими быть не могут.
Ни из чего, что я сказал, это не следует. Если это только впечатление — значит, оно неверно. Если я такое говорил — ссылку в студию!
PD>>Если не трудно, расскажи, как можно оптимизировать эти матричные сложения на порядок по скорости. Я тебе благодарен буду до предела. 
IT>Купи проц с 16-ю ядрами и сделай алгоритм многопоточным.
Многопоточность тут не поможет, я уже объяснил почему, идет пакетная обработка, так что все равно — одну матрицу разбивать или несколько обрабатывать. А вот насчет 16 ядер — не лукавь. Я тебя спросил — как можно
оптимизировать. А ты мне в ответ — купи более мощное железо. Почему бы в таком случае не посоветовать — купи 16 компьютеров ?
IT>Напомни. А тебя тем временем ещё больше огорчу. С появлением Linq сегодня этот код у меня выглядел бы вот так:
IT>IT>File.ReadAllLines("filename").Last();
IT>
IT>Свой оптимизированный вариант можешь не приводить, мне он не интересен.
Мой вариант был тогда еще приведен, и в нем ничего не меняется. А вот в твоем время замерь. Без LinQ ты проиграл в 33 раза
http://rsdn.ru/forum/education/2813653.1.aspxАвтор: Pavel Dvorkin
Дата: 28.01.08
А здесь, я думаю, побольше. Судя по тому, что нахождение простой суммы чисел проигрывает в 4-5 раз отнюдь не С++, а C# без Linq
IT>Потому что для решаемой задачи, а именно для файла размером в 120 байт, моё решение будет более чем приемлемым.
А почему же ты тогда, предлагая свое решение (тогда еще, да и сейчас) не оговорился — оно хорошо будет работать для малых файлов, но для достаточно больших его применять не следует ? Если бы ты это сделал — я и возражать бы не стал, если там 120 байт — все равно, что делать. Но ты ведь предлагаешь свое решение как универсальное, не так ли ?
PD>>Для того, чтобы его сделать, надо как можно пониже уровнем спуститься. Не оперировать абстракциями как-то реализованными, а использовать те средста, которые требуют минимальных действий. А для этого надо работать не с высокоуровневыми, а наоборот, низкоуровневыми средствами. Иными словами, Fine Tuning.
IT>Не надо никуда опускаться. Данная задачка не стоит выеденного яйца Пушкина ни по временным затратам, ни по производительности. Таких задачек в день я решаю мильён. Если оптимизировать каждую, то жизни не хватит.
М-да, ну и аргументы...
