Здравствуйте, Awaken, Вы писали:
L>>А то наплодили дельфийных и вижуал-васиковских "программистов"..
A>повбывав бы таких программистов которые всю бизнес-логику засовывают в
A>обработчик нажатия кнопки на форме (VB и Delphi насаждают такой стиль кодирования,
A>особенно для новичков)
Угу, я о том же. При этом ни хрена не понимая, как оно работает внутри.
Здравствуйте, Linuxoid, Вы писали:
L>Здравствуйте, Dmitry A. Sustretov, Вы писали:
L>Вот, почитай:
L>http://russian.joelonsoftware.com/Articles/BacktoBasics.html
L>А то наплодили дельфийных и вижуал-васиковских "программистов"..
Чавооо ?!
Причём тут дельфи ? Просто оптимизировать руками, когда есть современные компиляторы, лучше тебы знающие, КАК будет выполняться данный кусок кода, не имеет смысла в большинстве случаев. Имеет смысл только для очень внутренних циклов, выполняющихся 95% времени приложения, и если алгоритмическая оптимизация бессильна.
Зуб даю, что ты не напишешь код, который будет байт искать в строке, работающий быстрее, чем это тот, который сделает компилятор.
Здравствуйте, Dmitry A. Sustretov, Вы писали:
DA>Здравствуйте, Linuxoid, Вы писали:
L>>Здравствуйте, Dmitry A. Sustretov, Вы писали:
L>>Вот, почитай:
L>>http://russian.joelonsoftware.com/Articles/BacktoBasics.html
L>>А то наплодили дельфийных и вижуал-васиковских "программистов"..
DA>Чавооо ?!
DA>Причём тут дельфи ? Просто оптимизировать руками, когда есть современные компиляторы, лучше тебы знающие, КАК будет выполняться данный кусок кода, не имеет смысла в большинстве случаев. Имеет смысл только для очень внутренних циклов, выполняющихся 95% времени приложения, и если алгоритмическая оптимизация бессильна.
DA>Зуб даю, что ты не напишешь код, который будет байт искать в строке, работающий быстрее, чем это тот, который сделает компилятор.
При чем тут оптимизация и вставки на асме? Я говорю о том, что ассемблер нужно изучить (пусть не досконально) хотя бы для того, чтобы представлять, как работает процессор, и понимать, что происходит, когда ты пишешь у себя в программе какое-нибудь memcpy(...) или sprintf(...)
Здравствуйте, Linuxoid, Вы писали:
L>Здравствуйте, Dmitry A. Sustretov, Вы писали:
DA>>Здравствуйте, Linuxoid, Вы писали:
L>>>Здравствуйте, Dmitry A. Sustretov, Вы писали:
L>>>Вот, почитай:
L>>>http://russian.joelonsoftware.com/Articles/BacktoBasics.html
L>>>А то наплодили дельфийных и вижуал-васиковских "программистов"..
DA>>Чавооо ?!
DA>>Причём тут дельфи ? Просто оптимизировать руками, когда есть современные компиляторы, лучше тебы знающие, КАК будет выполняться данный кусок кода, не имеет смысла в большинстве случаев. Имеет смысл только для очень внутренних циклов, выполняющихся 95% времени приложения, и если алгоритмическая оптимизация бессильна.
DA>>Зуб даю, что ты не напишешь код, который будет байт искать в строке, работающий быстрее, чем это тот, который сделает компилятор.
L>При чем тут оптимизация и вставки на асме? Я говорю о том, что ассемблер нужно изучить (пусть не досконально) хотя бы для того, чтобы представлять, как работает процессор, и понимать, что происходит, когда ты пишешь у себя в программе какое-нибудь memcpy(...) или sprintf(...)
не вопрос
Здравствуйте, Dmitry A. Sustretov.
Настоятельно рекомендую воздерживаться от оверквотинга.
... << RSDN@Home 1.0 beta 6a... наслаждаюсь Track23 >>
Здравствуйте, Linuxoid.
Настоятельно рекомендую воздерживаться от оверквотинга.
... << RSDN@Home 1.0 beta 6a... наслаждаюсь Track24 >>
DA>Просто оптимизировать руками, когда есть современные компиляторы, лучше тебы знающие, КАК будет выполняться данный кусок кода, не имеет смысла в большинстве случаев.
В 2/3 случаев так и будет, полагаю
Но, пока не в 90%
Последний пример — недавно спорили, в "Алгоритмах" в точном вычислении факториала 1000, что будет быстрее, работать с 16-битными числами или 32-хбитными. Там используется промежуточное перемножение чисел, давая, соответственно, 32-х и 64-х битное произведение.
Понятно, что вручную на асме лучше работать с 32/64, чем 16/32, т.к. то же произведение как раз будет 64-х битным в EDX:EAX, а 16-битные придётся ещё маскировать, двигать или использовать префиксы.
Вопрос был поймёт ли это компилятор. Я использовал VC7. Думаю, мало кто сомневается, что это на сегодня один из лучших компиляторов C/C++.
(GCC тоже хорош, но оптимизация у него послабее).
Так вот, вариантов было два. Первый в духе:
unsigned long a32, b32.
unsigned long d32=((unsigned __int64)a32*b32)%0x100000000;
unsigned long c32=((unsigned __int64)a32*b32)/0x100000000;
unsigned long a32, b32.
unsigned long d32=(unsigned __int64)a32*b32;
unsigned long c32=((unsigned __int64)a32*b32)>>32;
Компилятор в обоих случаях сделал всё замечательно. Дважды не вычислял, использовал быстрые операции, распараллеливал вычисления и т.п. Вот только в первом случае полез вызывать внешнюю подпрограмму деления/остатка 64-битных чисел, во втором же — сделал всё в одну команду, через imul, сразу используя после этого результаты из EDX:EAX.
Не зная ассемблера хотя бы на уровне чтения листинга такое не заметить
DA>Имеет смысл только для очень внутренних циклов, выполняющихся 95% времени приложения, и если алгоритмическая оптимизация бессильна.
Угу. Но, ведь, нужно знать что писать, чтобы помочь компилятору
DA>Зуб даю, что ты не напишешь код, который будет байт искать в строке, работающий быстрее, чем это тот, который сделает компилятор.
Ну, слава Богу, на таком простом примере я напишу код не хуже компилятора и на современном процессоре. Но и не лучше :D Если взять что-то более сложное — ты прав. Уже для PII я не могу гарантировать, что напишу лучше компилятора. Но вот и компилятору можно подсовывать очень и очень разный исходный код и нужно уметь разобраться в результате
Хотя, конечно, ещё важнее знать просто хорошие алгоритмы. Сортировка всего 500 больших записей, видимо, методом пузырька в одной популярной программе меня просто бесила, пока я от этой программы не отказался :D
есть замечательная книга Windows Debugging и там объясняется зачем нужно понимать ассемблер.
и даже отдельная глава по основным командам Intel приводится
