были времена - не справлялись. Как узнать что эффективнее и почему это так без смены уровня абстракции?

Блин, да очевидно ведь! Если мы делаем больше вычислений (в цикле) - это хуже. Меньше - лучше. Причём тут асм?!  Если бы вы привели хотя б какой-нибудь пример, ориентированный на особенности работы процессора, выравнивания там скажем - другое дело. А это... Банальное число операций. Математика уж скорее, чем асм ))

GoldFinch, примеры высосаны из пальца.

есть кончено, в 1 примере при ф-ии возвращающей класс я бы руки оторвал, за второй вариант.

это вообще че за конструкция? впервые вижу 
нафиг там свитч x=key - '0' И все. Примеры элементарные
Упс страницу пропустил 

Это сообщение отредактировал(а) vinter - 5.2.2009, 18:49

+1, вот например 
Любитель и Carnifex знают что switch компилится с использованием таблицы переходов, а толку-то никакого

компилится в массив адресов меток m1..mN ("таблица переходов"), из которого выбирается адрес для перехода на нужный case, N операторов присваивания константы переменной, и N переходов на конец switch
итого N адресов, N присваиваний, N констант, N+1 переходов, в процессе выполнения происходит 2 перехода и 1 присваивание


здесь N констант и 1 операция присваивания

Добавлено через 1 минуту и 20 секунд
vinter, считай это псевдокодом, а не кодом С++
примеры вырожденные, чтобы было виднее их суть

GoldFinch, в идеале, чем выше уровень абстракции тем лучше, в этом направлении программирование и развивается.
Раньше, когда компьютеры были большими а /me ходил в первый класс, программисты были не глупее чем сейчас но софт был, скажем так не очень функциональный. А все из-за уровня абстракции, программировать с использованием прерываний, регистров и тд это конечно круто, но написание более менее сложной программы потребует слишком много человеко-лет. То, что сейчас пишет один программист на сишарпе за неделю в одно рыло, раньше писала-бы куча народу много месяцев.
Поэтому я считаю, что нужно использовать достижения прогресса в нашей профессии, вместо того, что-бы изучать все, что когда-то было мэйнстримом, в общем нужно смотреть вперед а не назад.
В то-же время есть вещи, не теряющие ценности со временем, дискретная математика, тервер, алгоритмы и структуры данных так-же актуальны для современных программистов как и раньше  

1) Знание принципов генерации байткода даёт знание того, почему одни конструкции в языке эффективнее других. Нередко в книгах их вбивают в голову на уровне аксиом - "эффективнее так, а не иначе", но на практике понимание движущих механизмов сильно полезнее тупого зазубривания.

2) Принципы работы JVM - это, например, способ загрузки классов при запуске, порядок инициализации конструкций в классе, выделение и использование памяти, различные алгоритмы сборщика мусора и их переключение в зависимости от специфики приложения...

Лишнее? Ну... можно писать код и без всего этого мусора в голове (и даже без знания математики, проверено  ). Только вот выше быдлокодера подняться будет проблематично.

И вообще, С++, на мой взгляд - достаточно низкоуровневый язык, те кто пробовал программировать на python/ruby ну или даже C#/Java в общем на современных языках программирования, или на функциональных ЯП, таких как haskell, которые многие считают языками программирвания будущего, меня поймут ;)

дело было не в том, что небыло стандартных библиотек с готовыми алгоритмами, это все было достаточно давно. проблема была в железе с крайне жесткими ограничениями по объемам памяти и производительности. мне повезло попрограммировать ГУЙ для ДОС когда у тя может быть не более 10 64Кб сегментов памяти, а процессор с трудом тянет всякую анимацию типа анимированного курсора мыши (последовательность битмапов хранить негде, поэтому анимация рассчитывалась в реал-тайме)

Добавлено через 2 минуты и 19 секунд
Lazin, функциональные языки не менее древние чем императивные. Недостатков у них более чем хватает.

ты приводишь знания о спецификации языка, а это есть стандарт(не знаю как там со стандартом в яве), Знание принципа раскрытия инструкций в байт код, не дает никаких преимуществ. Если считаешь иначе, приводи конкретный пример.

например?


Ну а я про что, раньше этого так и было, а сейчас это все не актуально.
Сейчас новый сервер дешевле нового программиста, так-что делайте выводы. Раньше программисты оптимизировали все что только можно на микроуровне, там операцию сэкономили, там избавились от лишней отрисовки на экране и вроде как быстрее заработало. Но на современном железе ты этого "быстрее" скорее всего не заметишь. Какая нафик разница сортируется массив из 1kk строк за 0.1 сек или за 0.05 сек. Такой импрувмент начальство скорее всего не оценит. Оценят максимально корректную программу, которая создаст как можно меньше проблемм. 
В большинстве современных приложений причина тормозов - I/O, неоптимально разработанные алгоритмы( O(N*N) когда можно сделать O(ln(N))), неправильная работа с динамической памятью(фрагментация, слишком частое выделение - освобождение памяти), локи в многопоточных приложениях. Все это борется не с помощью вставок на асме, а на более высоком уровне, использованием асинхронного ввода вывода, буферизованного, оптимальных алгоритмов обработки данных, написанием своего специализированного менеджера памяти, ну и правильным проектированием приложеиня и использоанием наиболее подходящих в конкретном случае примитивов синхронизации.

Это сообщение отредактировал(а) Lazin - 5.2.2009, 22:44

Классика из любой книги на Java:

Общеизвестно - присваивание String в цикле является признаком неумелого программирования и просаживает скорость приложения. Какова причина? Смотрим байткод с помощью "javap -c":

Механика: исходная строка сохраняется в стеке (2). В цикле на каждой итерации создаётся новый объект StringBuilder (12), сохранённая строка извлекается из стека и добавляется к нему (к слову: и если её размер больше 16 символов, происходит новое выделение памяти и перемещение на неё объекта) (16-20), добавляется строка "abc" (25), из содержимого StringBuilder создаётся новый объект String (28) и сохраняется обратно в стек (31). А всё оттого, что объект String является неизменяемым (immutable), и операции со сложением строк через оператор (+) неявным образом используют StringBuilder. Но одно дело зазубрить и поверить на слово, а другое - увидеть в байткоде собственными глазами. Понимаю, пример выглядит чрезмерно наглядным и даже в какой-то степени уникальным - но мой point про полезность понимания подтверждает на сто процентов. Плюс на форуме есть цикл статей от Domestic Cat. Вот, к примеру, цитата из второго поста после обсуждения некоторого количества кода, подтверждающая полезность тщательного изучения генерируемого байткода:



Сборщики мусора в стандарт языка не входят, это спецификация JVM, с которой знакомится гораздо меньшее число разработчиков. Однако при приёме на работу про них могут серьёзно спросить. Почему JVM легко относится к огромным количествам короткоживущих объектов; особенности работы JVM, при запуске которой установлен ключ "-client"; или "-server"; чем отличается на деле работа последовательного GC от параллельного; для чего разработан инкрементальный GC и в каких специфичных случаях он даёт выигрыш приложению; почему требуется быть осторожным с вызовом System.gc() (считается, что это всего лишь рекомендация JVM к запуску сборки мусора, которую она вправе проигнорировать. Однако на деле при запуске такого GC чистится не только молодое поколение, но и старое, в результате приложение может серьёзно приостановиться и ни о каком soft real-time речи уже не будет).


P.S. про ассемблер: только после его изучения до меня на самом деле дошло, что такое "передача по значению" и "передача по ссылке". Думать о них стало значительно проще. И в Джаве они используются в том числе.

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

Shaggie, дальше свпорить с тобой не буду, т.к боюсь моих познаний в Java для этого не хватит. Пока тебе поверю на слово 

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

Для примера возьмём умножение матриц. Много зависит от того, как мы храним матрицу в памяти(линейно, либо построчно), а для этого нужно понимать, что при линейном хранении вероятно кэш-промахов меньше, чем при построчном. В то же время для маленьких матриц(эмперически установил для себя границу таких матриц, где общее число элементов < 50000) это не имеет смысла, т.к. маленькая матрица может уместиться полностью в кэш современных процессоров. С другой стороны, хотим мы реализовать умножение. Сколько бы мы не оптимизировали классический алгоритм нифига путнего из этого не выйдет. Для больших матриц частые кэш-промахи съедят любую оптимизацию(одно обращение к памяти может занимать тысячи тактов). А вот если взять и транспонировать одну из матриц, а потом перемножать последовательно строка*строка(а не строка*столбец), то мы получаем эффективную работу с кэшем и, допустим в моём случае, десятикратный прирост производительности на матрицах размером 1024х1024. Далее можно этот процесс векторизировать, т.е. заюзать SSE2, но тут уже действительно надо знать ассемблер и подходящии инструкции, а так же принципы их работы, понимать саму парадигму SIMD. А кому этого мало, можно вообще перенести перемножение больших матриц на GPU,  а там опять новая архитектура и её особенности и опять же, чем лучше знаком с аппаратными особенности(в разумных пределах), тем лучше. 

Знание ассемблера полезно при профайлинге приложений, чтобы не смотреть как осёл на асм-листинги и тайминги без понимания сути.

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

Всё зависит в итоге от разработчика и его профессионализма. Если я знаю, что у меня какой-то цикл выполняется 10 раз в час, при этом он совсем не нагружен, то лучше я вызов метода/функции в него помещу, ибо код будет более читабелен, а вынос переменной за цикл здесь является излишней оптимизацией, никому ненужной. 

Согласен, но в моей практике не было программ, умножающих матрицы очень много раз, да и если программа написана корректно и алгоритм правильный, заюзать SIMD и оптимизировать работу с кэш памятью не проблема (кстати асм тут не нужен) а вот если ваш алгоритм - ### и программа написана не пойми как, то тут уже сложно будет что-то сделать  
В общем, корректную программу сделать быстрой легко, а быструю корректной - сложно. (не помню чьи это слова)