Здравствуйте, Pavel Dvorkin, Вы писали: PD>Что же касается примера с strcpy, то именно тот факт, что ее высоко оптимизировали, говорит, что ее эффективнсть — совсем не мелочь. Если бы ее эфективность мало на что влияла, зачем бы авторы библиотеки это сделали ?
а теперь я вообще соневаюсь, что вы работаете где-то. неужели всегда все что люди делают оно исключительно разумные цели преследует? любая разработка большого проекта напоминает хаотичный бред обычно
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>ArrayList при своем росте, требует периодической полной реаллокации, что ведет к инвалидации данных кеша. Кроме того, если в нем не 5-10 элементов, эта переаллокация на нижнем уровне может привести к выделению новых страниц памяти, то есть к системному вызову с переходом в режим ядра и связанными с этим затратами. Это как-то учитывается ?
Учитывается при помощи свойства Capacity.
Павел, ты вот сейчас троллишь, или это конец света наступил? Все эти "секретные новости" были хорошо известны ещё во времена Delphi 2.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
PD>>>>Во-первых, нетрудно сообразить, что коль в качестве примера приведена strcpy, то речь идет не о яве и дотнете AVK>>>Да? Твоя цитата: AVK>>>
AVK>>>От того, насколько эффективно реализована банальная strcpy (конечно, для примера), зависит скорость программ на С++ и C#, Java
PD>>Моя, конечно. И вот еще моя. Ты ее почему-то убрал. А зря. Потому что именно она и поясняет мою мысль.
AVK>Ты сперва определись, шла речь о джаве и шарпе, или не шла.
Ну что же, придется, видимо, мне и впрямь взять на себя роль КО. Потому что эти О для тебя , оказывается, вовсе и не О...
O#1. strcpy есть фигура речи, естественно, имеется в виду код нативных библиотек в целом
O#2. Нативный код выполняется не только в чисто нативных приложениях, но и в ненативных тоже.
O#3. Более того, управляемые приложения в значительной степени исполняют ненативный код. Более того, если речь идет о GUI, то львиная доля — ненативный код, исполняемый как в 3 кольце, так и в ядре.
O#4 (вывод) Поэтому от того, насколько эффективно реализованы библиотеки нативного кода , зависит эффективность нативного приложения.
PD>>И наконец, в пятых, хоть ява, хоть дотнет программа исполняет большое количество нативного кода если не прямо, так косвенно.
AVK>А как же тогда: AVK>
AVK>нетрудно сообразить, что коль в качестве примера приведена strcpy, то речь идет не о яве и дотнете
А очень просто. Речь идет о нативном коде поддержки java и дотнет, то есть о коде, который в приложениях , написанных на яве и дотнете (а также питоне, бейсике и т.д.) исполняется, хотя и не является собственно результатом компиляции с явы или с#.
Нетрудно было понять, но ты не захотел.
AVK>Да, к страшным методам — не ведусь на твою лапшу.
Более серьезные аргументы, видимо, отсутствуют.
AVK>>>Это не то. RAW разделы это древний артефакт для совместимости. Но и файл БД открывается с флажком, запрещающим кеширование. PD>>Открытие файлов без кеширования — вещь вполне банальная, флаг в CreateFile.
AVK>Спасибо, КО.
Всегда пожалуйста
PD>> Только вот при чем тут учет структуры диска ?
AVK>При том что кеширование отключается как раз для того, чтобы сам сиквел содержит более качественные и специализированные алгоритмы ускорения доступа к диску. В том числе и свой собственный кеш страниц.
Спасибо. Я бы сам никогда не догадался
PD>>А если через драйвер, то учитывать структуру диска будет он, а не мы
AVK>В винде есть способы узнать физическую структуру диска даже через драйвер ФС.
Несомненно. Только не физическую структуру диска, а структуру файловой системы. За физической структурой диска надо к драйверу HDD обращаться.
PD>>, так как влиять на размещение файла при живом драйвере не получится — это его обязанности.
AVK>Влиять может и не получится, а вот учитывать — запросто.
PD>>Да вполне угодила, что тут особенного, банальность.
AVK>Так и вопросы у тебя более чем банальные. Ты внезапно осознал вполне очевидные вещи — линейный доступ к памяти и, особенно, к диску быстрее, чем случайный. И теперь, судя по всему, считаешь что сделал открытие.
Не понял ты. То, что быстрее, я осознал лет 15 назад. А вот то, что системные библиотеки (в большинстве своем) по-прежнему этот фактор игнорируют и работают как если бы мы все еще имели RAM — вот это да.
PD>> Но я же не об этом говорил, а о скорости доступа как к структурам прямого доступа. В памяти. Код то есть самого sql парсера и его структур даных.
AVK>В чем принципиальная разница? Проблемы то те же самые. Про код парсера (а точнее оптимизатора, парсер никого давно уже не колышет) сиквела тебе тут вряд ли кто что скажет, это один из самых охраняемых секретовв mssql. Но предположить, что те люди, которые этот код писали, были не в курсе особенностей доступа к памяти, ну это надо быть совсем незамутненным.
А я где-то предположил ? Можно такое упоминание ? Наоборот, я написал
PD>Наверное, можно при этом отключить и кеширование, тем более, что авторы его из MS, а значит, все могут
Здравствуйте, Sinclair, Вы писали:
S>Павел, ты вот сейчас троллишь, или это конец света наступил? Все эти "секретные новости" были хорошо известны ещё во времена Delphi 2.
Антон, постарайся понять, о чем я говорю. Не о каких-то секретах, хорошо известных уже 15 лет или более, а о том, что библиотеки для самых массовых действий по-прежнему в значительной степени эти "секреты" игнорируют.
Здравствуйте, __kot2, Вы писали:
PD>>Что же касается примера с strcpy, то именно тот факт, что ее высоко оптимизировали, говорит, что ее эффективнсть — совсем не мелочь. Если бы ее эфективность мало на что влияла, зачем бы авторы библиотеки это сделали ? __>а теперь я вообще соневаюсь, что вы работаете где-то. неужели всегда все что люди делают оно исключительно разумные цели преследует? любая разработка большого проекта напоминает хаотичный бред обычно
А вот тут ты глубоко неправ. Разработка программы на заказ — порой да. И то не всегда. Мне довелось участвовать в проекте, который продолжался несколько лет и отнюдь не напоминал хаотичный бред. И задачей моей было именно оптимизировать код.
А вот разработка библиотеки, да не какой-нибудь, а стандартной библиотеки среды программирования, да не какой-нибудь среды программирования, а среды #1 — тот, кто позволит себе хаотичный бред в такой работе, быстро в трубу вылетит.
Так что поищи другой ответ на этот вопрос...
А еще есть Intel C++, который делает более эффективный код, чем VC++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>а о том, что библиотеки для самых массовых действий по-прежнему в значительной степени эти "секреты" игнорируют.
Докажи
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А вот тут ты глубоко неправ. Разработка программы на заказ — порой да. И то не всегда. Мне довелось участвовать в проекте, который продолжался несколько лет и отнюдь не напоминал хаотичный бред. И задачей моей было именно оптимизировать код.
PD>А вот разработка библиотеки, да не какой-нибудь, а стандартной библиотеки среды программирования, да не какой-нибудь среды программирования, а среды #1 — тот, кто позволит себе хаотичный бред в такой работе, быстро в трубу вылетит.
PD>Так что поищи другой ответ на этот вопрос...
я в Микрософте работаю, если чо
PD>А очень просто. Речь идет о нативном коде поддержки java и дотнет, то есть о коде, который в приложениях , написанных на яве и дотнете (а также питоне, бейсике и т.д.) исполняется, хотя и не является собственно результатом компиляции с явы или с#.
Ну и что с этим кодом? Его авторы не умеют работать с целевыми системами? Понятно, что это не так. JIT в дотнете и яве как раз сделан так, чтобы генерировать код для целевой платформы.
Тебя волнуют кэши процессора? А с какого перепугу они тебя волнуют? В 99.9999% приложений банальная алгоритмическая оптимизация сделает в разы больше, чем любые попытки попасть в кэш процессора.
И ты не поверишь, в 0.00001% задач, где это действительно надо, люди садятся и пишут код, который попадает в кэш процессора, сам работает с файлами на диске и т.п. Это как раз то, о чем тебе Андрей написал про SQL Server, например:
кеширование отключается как раз для того, чтобы сам сиквел содержит более качественные и специализированные алгоритмы ускорения доступа к диску. В том числе и свой собственный кеш страниц.
ЗЫ. Тут в Erlang VM оптимизируют VM для улучшения работы на многопроцессорных системах. Там учитывается все: кэши процессоров, resource contention, lock-free алгоритмы, memory barriers. Нужно ли это все для VM? Безусловно. И ВНЕЗАПНО программисты, которые ей занимаются, это все знают и используют. Для 99.9999% приложений внутри этой VM знать это банально не нужно.
Здравствуйте, __kot2, Вы писали:
PD>>А вот разработка библиотеки, да не какой-нибудь, а стандартной библиотеки среды программирования, да не какой-нибудь среды программирования, а среды #1 — тот, кто позволит себе хаотичный бред в такой работе, быстро в трубу вылетит.
PD>>Так что поищи другой ответ на этот вопрос... __>я в Микрософте работаю, если чо
M>Тебя волнуют кэши процессора? А с какого перепугу они тебя волнуют? В 99.9999% приложений банальная алгоритмическая оптимизация сделает в разы больше, чем любые попытки попасть в кэш процессора.
Посмотри мое первое сообщение. Там ссылка на исходный постинг, вызвавший это мое сообщение. В нем обсуждается бинарный поиск и его специфика в связи с кешем. Там именно предложена некая оптимизация, пусть и для частного случая поиска многих, а не одного.
Вот и вопрос — где эта (или подобная) оптимизация в системных библиотеках ?
M>И ты не поверишь, в 0.00001% задач, где это действительно надо, люди садятся и пишут код, который попадает в кэш процессора, сам работает с файлами на диске и т.п. Это как раз то, о чем тебе Андрей написал про SQL Server, например: M>
M>кеширование отключается как раз для того, чтобы сам сиквел содержит более качественные и специализированные алгоритмы ускорения доступа к диску. В том числе и свой собственный кеш страниц.
Вопрос-то тоньше. Люди пишут, верно. Сам писал. Но это свой код. А библиотеки ? Их-то код мало кто переписывает. Вот и получается, что полагаемся на не самый эффективный код... И не только генерируемый JIT и т.д, но и нативный код, принмающий участие в работе процесса на базе .net или java или что угодно.
M>>Тебя волнуют кэши процессора? А с какого перепугу они тебя волнуют? В 99.9999% приложений банальная алгоритмическая оптимизация сделает в разы больше, чем любые попытки попасть в кэш процессора.
PD>Посмотри мое первое сообщение. Там ссылка на исходный постинг, вызвавший это мое сообщение. В нем обсуждается бинарный поиск и его специфика в связи с кешем. Там именно предложена некая оптимизация, пусть и для частного случая поиска многих, а не одного. PD>Вот и вопрос — где эта (или подобная) оптимизация в системных библиотеках ?
Вопрос неправильный. Правильные: Эта оптимизация нужна? Если она нужна, доступны ли библиотеки, где она выполнена? Если библиотеки недоступны, есть ли возможность реализовать это самому?
Ответы:
— Эта оптимизация нужна?
Нет, в 99.99999% приложений она не нужна, потому что алгоритмические оптимизации в разы лучше, чем попытка уложится в кэш процессора
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, интересный вопрос. Можно как-то узнать, сколько времени в некотором дотнет или ява-приложении исполняется управляемый код и сколько — нативный ? Я имею в виду "чистое" (не астрономическое) время исполнения процесса. Узнать, сколько времени исполняется код ядра и код юзермоде для процесса — никаких проблем, а вот это можно ли узнать ?
А чем при выполнении managed отличается от unmanaged? Например a+b на C# как будет отличаться от a+b на C++? ИМХО никак.
Так что непонятно что ты спросить хочешь.
Можешь просто посчитать время выполнения простых операций в цикле на .NET и на C++ — разница это то что дает именно managed.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, интересный вопрос. Можно как-то узнать, сколько времени в некотором дотнет или ява-приложении исполняется управляемый код и сколько — нативный ?
Можно. Профайлером.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали: G>А чем при выполнении managed отличается от unmanaged? Например a+b на C# как будет отличаться от a+b на C++? ИМХО никак. G>Так что непонятно что ты спросить хочешь.
Может, я не совсем прав, но...
При исполнении управляемого кода имеем
1. Общее время в юзермоде (кернелмоде опустим)
2. Время, потраченное самим JIT — это он измерить вполне мог бы
3. Время от момента входа в некий нативный код до выхода из него — тоже можно бы измерить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Резюме : когда мы используем алгоритмы, требующие прямого доступа, надо отдавать себе отчет, что мы имеем дело фактически с компьютером, намного более медленным, чем мы считаем. Иными словами, если мы думаем, что со времен ДОС скорость работы машины увеличилась в N раз (я не обсуждаю многоядерность и многопоточность), то реально она увеличилась лишь в N/K раз.
А ничего, что в кэш второго уровня одного современного ядра поместится несколько раз по 640kb (тех самых, которых во времена ДОС хватало на всё)?
PD>А если это так, то не означает ли это , что надо озаботиться преобразованием алгоритмов, использующих прямой доступ, к некоторому иному виду, его не использующему ? Даже если поначалу кажется (из общих соображений), что это приведет к падению быстродействия ?
Поздравляю с разморозкой. Это и так всегда делается. Этому в школе учат, классе эдак в первом. Даже любой студент-двоечник знает, как адаптировать алгоритмы под особенности кэшей.
Здравствуйте, Pavel Dvorkin, Вы писали:
__>>я в Микрософте работаю, если чо PD>Так спроси разработчиков, если это возможно
Мне это напомнило вопрос, который задал сын моего знакомого после очередного посещения фитнеса (а он любитель покачаться): "пап, а ты качков там видел?"
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
