> Скорее всего 95% прироста производительности вашей программы обеспечены 1-2 оптимизациями
Это не так. Мы много смотрели в код конкурентов, и знаем что мы используем практически идентичные алгоритмы, просто для задачи сравнения данных в базе других особо нет. Насчёт асинхронности — да, тут есть хороший выигрыш, но даже без неё программа всё-равно в разы быстрее, благодаря остальным оптимизациям.
Для конечных пользователей это много чего меняет :) Собственно, я для этого и написал основных 30 пунктов. Каждый из них привнёс в производительность свою долю. Я упоминал, что разработка велась сразу с учётом оптимизации, поэтому сложно говорить о самых горячих местах. Да, после первой реализации программа была уже быстрее конкурентов, а дальнейшая оптимизация была что-то вроде «надо выжать по максимуму».
Не спорю. Я тоже говорю, что стоит вначале определится с требованиями к приложению, а только в самых необходимых случаях прибегать к хардкорным оптимизациям :)
> black-box замеров двух разных систем
Откуда такие сведения? Я точно знаю по какому алгоритму работает конкурентная сисетма. У меня было достаточно времени чтоб ознакомится с исходным кодом с помощью .NET Reflector.
Можете рассуждать сколь угодно в рамках своих познаний, но всё работает на практике, причём есть реальное приложение, которое работает лучше всех. Всё было кропотливо проверено за 3 года работы в этой области. А вы лично проверяли то, о чём сейчас написали? Есть доказательства высокопроизводительных приложений?
>Никаких «foreach»
Зачем надеятся на оптимизацию при каких-то условиях, если можно руками чётко написать именно то, что хочешь. Тем более, JIT compiler может быть разный (для Windows, XBox, Linux, и пр.) от разных производителей. Кто сказал что все они одинаково работают?
>эта конструкция создаёт экземпляр класса, который реализует интерфейс IEnumerable
Вы неправильно поняли пункт. Это уже уточнения как можно использовать «foreach». Смысл в том, что в итоге у вас всё-равно 2 метода: MoveNext и Current. Именно об вызове методов я писал, ссылаясь на пункт 23 (я в тексте ссылаюсь на 24, сейчас исправлю, простите).
>Единственный способ избежать этих проверок, написать «for» таким образом
Вы ссылку смотрели на блог от Microsoft на словах «таким образом»? Там детально объясняется как можно. Что ж здесь неверного?
>volatile
Это детальное разъяснение к описанию? Не совсем понял.
>Структуры, поля которых – только value types, легко сериализовать в массив байт и обратно.
Почему нельзя? Туда можно ещё приписать Big/Little Endian, но всё это проблемы характерные для конкретных задач, о которых не шла речь. Если использовать такой подход для какого-нибудь временного кэша, то почему нельзя?
Я везде пытался как можно проще и короче пояснить основную суть, не вдаваясь в детали (а их очень много), о чём честно предупредил в начале статьи :)
Не могу не согласится насчёт CMOVxx, но не забывайте что статья про C# — здесь код компилируется в IL, а потом в инструкции (причём JIT должен делать это быстро). Будет ли там CMOV — нужно смотреть от случая к случаю.
Насчёт примера «int CompareBytes(byte a, byte b)», я проверял на практике при написании статьи — на моей машине работало ровно в 2 раза быстрее, не обманываю :) А если с CMOV — ещё раз этак в 2,5 быстрее (точно уже не помню). Поэтому и написал «определённых местах может», а не «всегда будет лучше» :)
Это не так. Мы много смотрели в код конкурентов, и знаем что мы используем практически идентичные алгоритмы, просто для задачи сравнения данных в базе других особо нет. Насчёт асинхронности — да, тут есть хороший выигрыш, но даже без неё программа всё-равно в разы быстрее, благодаря остальным оптимизациям.
Откуда такие сведения? Я точно знаю по какому алгоритму работает конкурентная сисетма. У меня было достаточно времени чтоб ознакомится с исходным кодом с помощью .NET Reflector.
> Да вы шутите
Out-of-box thinking ;)
Зачем надеятся на оптимизацию при каких-то условиях, если можно руками чётко написать именно то, что хочешь. Тем более, JIT compiler может быть разный (для Windows, XBox, Linux, и пр.) от разных производителей. Кто сказал что все они одинаково работают?
>эта конструкция создаёт экземпляр класса, который реализует интерфейс IEnumerable
Вы неправильно поняли пункт. Это уже уточнения как можно использовать «foreach». Смысл в том, что в итоге у вас всё-равно 2 метода: MoveNext и Current. Именно об вызове методов я писал, ссылаясь на пункт 23 (я в тексте ссылаюсь на 24, сейчас исправлю, простите).
>Единственный способ избежать этих проверок, написать «for» таким образом
Вы ссылку смотрели на блог от Microsoft на словах «таким образом»? Там детально объясняется как можно. Что ж здесь неверного?
>volatile
Это детальное разъяснение к описанию? Не совсем понял.
>Структуры, поля которых – только value types, легко сериализовать в массив байт и обратно.
Почему нельзя? Туда можно ещё приписать Big/Little Endian, но всё это проблемы характерные для конкретных задач, о которых не шла речь. Если использовать такой подход для какого-нибудь временного кэша, то почему нельзя?
Я везде пытался как можно проще и короче пояснить основную суть, не вдаваясь в детали (а их очень много), о чём честно предупредил в начале статьи :)
Насчёт примера «int CompareBytes(byte a, byte b)», я проверял на практике при написании статьи — на моей машине работало ровно в 2 раза быстрее, не обманываю :) А если с CMOV — ещё раз этак в 2,5 быстрее (точно уже не помню). Поэтому и написал «определённых местах может», а не «всегда будет лучше» :)