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

PD>>>Эффективности чего ? Работы программиста или конечного кода ?
IT>>Эффективность затрат, необходимых для получения конечного результата.
PD>Не уходи от ответа. Что, если затраты не столь существенны, а качество продукта на первом месте ?

Я никуда не ухожу. Меня интересует прежде всего эффективность всего решения. Если к системе предъявляются серьёзные нефункциональные требования и заказчик за это готов платить, то он это получит, не переживай.

IT>>Эффективной можно спокойно считать программу, эффективность которой приемлема.

PD>Это все слова. От меня требуют — как можно быстрее. Все остальное мне простят. И если тактовая будет 20 GHZ, то от меня все равно будет требовать то же. Иными словами, выжать из железа все, что можно. Ты допускаешь, что такая постановка вопроса возможна ?

Конечно, возможна, я это вполне допускаю. Но как я уже сказал такое встречается довольно редко. Ты же пытаешься распространить свой крайний случай на всё программирование в мире.

>>К тому же программа чаще всего — это комплекс алгоритмов. Бессмысленно, например, выжимать миллисекунды при построении текста SQL запроса, если потом сам запрос выполняется десятки минут.

PD>Если запрос будет выполняться десятки минут, со мной перестанут разговаривать. А вот если запро выполняется 100 мсек, а остальное — 5 мсек, а я сделаю 4 — мне за это скажут спасибо.

А при чём здесь ты? Твои задачи — это капля в море и почему на эту каплю должно равняться всё море.

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

PD>В теории совершенно верно, а практически не всегда возможна. Например, обработка производится 3dparty lib, свою написать — годы понадобятся, да и будет ли лучше... а вот оптимизировать то, что от меня зависит, я могу. Даже если это 1-2%.

Да сколько угодно. Только то, что ты оптимизируешь сегодня под имеющееся у тебя железо, не факт что будет работать быстрее на завтрашнем.

>>Но такие оптимизации не зависят от языка программирования... хотя я не прав — зависят. Зависят от того насколько выразителен и прост в обращении используемый инструмент.

PD>Не согласен. Они определяются тем, насколько инструмент близок по своему духу машинному языку. Чем ближе — тем больше у меня возможностей, не переходя или почти не переходя на асм, написать наилушим образом. Что же касается выразительных и простых конструкций иных языков, то эта простотоа и ясность, вполне приемлемые в иных случаях, здесь проигрывают. По той простой причине, что высокоуровненвые конструкции неизбежно компилируются неким стандартным образом, без учета конкретной специфики. Ее полностью можно учесть в идеале на асме, а в реальности — на очень низкоуровневом ЯВУ.

Под оптимизацию стандартных высокоуровневых конструкций, если ты не знал, затачиваются внутренности процессоров. Ещё год назад ты говорил о 5%, сегодня уже об 1-2%, а что будет ещё через пару лет?

>>A здесь C сливает современным языкам со страшной силой.

PD>С точностью до наоборот.

А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории?

IT>>До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет.

PD>А что поможет ?

Поможет пересмотр архитектуры.

PD>Задачи разные бывают.

Это правда, только понимаешь ты это очень однобоко. Складывается впечатление, что они только у тебя разные бывают, а у остальных в точности такие как у тебя и другими быть не могут.

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

PD>Если не трудно, расскажи, как можно оптимизировать эти матричные сложения на порядок по скорости. Я тебе благодарен буду до предела.

Купи проц с 16-ю ядрами и сделай алгоритм многопоточным.

>>А вот сложность решения будет в точности наоборот — код на C# будет на порядки проще кода на C при незначительном увеличении потребления ресурсов.

PD>Исходный код — будет, не спорю, а эффективность — наоборот. Тебе про чтение последней строки из файла напомнить ? .

Напомни. А тебя тем временем ещё больше огорчу. С появлением Linq сегодня этот код у меня выглядел бы вот так:

File.ReadAllLines("filename").Last();

Свой оптимизированный вариант можешь не приводить, мне он не интересен.

PD>Кстати. если уж ты так ратуешь за использование эффективных алгоритмов, почему же ты там пошел на чтение файла целиком, если вполне достаточно прочитать маленький кусочек с конца, да даже и не читать (проблемы будут), а просто открытьт мэппинг — и задним ходом! Вот тебе и пример насчет эффективного алгоритма.

Потому что для решаемой задачи, а именно для файла размером в 120 байт, моё решение будет более чем приемлемым.

PD>Для того, чтобы его сделать, надо как можно пониже уровнем спуститься. Не оперировать абстракциями как-то реализованными, а использовать те средста, которые требуют минимальных действий. А для этого надо работать не с высокоуровневыми, а наоборот, низкоуровневыми средствами. Иными словами, Fine Tuning.

Не надо никуда опускаться. Данная задачка не стоит выеденного яйца Пушкина ни по временным затратам, ни по производительности. Таких задачек в день я решаю мильён. Если оптимизировать каждую, то жизни не хватит.