Здравствуйте, Dimonizhe, Вы писали:
D>Я пишу на Жабе корпоративные приложения. И уж точно не отношусь с пиететом к ассемблеру. Хочу сказать определенно — всякий шит тормозящий даже на двойных Зеонах с 3 гигами памяти ДОСТАЛ. Поэтому, если кто-то что-то оптимизировал на ассемблере, то это как минимум уважаемо как забота о нас.
BEA Weblogic?
На самом деле тормозит как правило не платформа или язык, а кривые ручки программистов, ленящихся почитать книжки про структуры данных и алгоритмы, и поэтому неумеющие их эффективно применять. Их не волнует, что допустим поиск элемента в выбранной структуре занимает O(n), находит, а это главное. Ну и про работу с потоками отдельная песня.
Здравствуйте, jenyavb, Вы писали:
J>Здравствуйте, Константин, Вы писали:
К>>Хорошо, пусть создаёт. Элементарнейший подсчёт: забэкапить всё то, что будет заменено, это (считаю по максимуму): J>Он не только это бэкапит. Он создает точку восстановления. Это все-равно, что создать её вручную, столько-же времени займет.
А можно эту порчу отключать при установке?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, jenyavb, Вы писали:
J>>Здравствуйте, Константин, Вы писали:
К>>>Хорошо, пусть создаёт. Элементарнейший подсчёт: забэкапить всё то, что будет заменено, это (считаю по максимуму): J>>Он не только это бэкапит. Он создает точку восстановления. Это все-равно, что создать её вручную, столько-же времени займет.
К>Во-первых, что такое точка восстановления по сути? Чем она отличается от простого бэкапа специфического набора файлов и веток реестра? Лично я этого не знаю, но просто не могу себе представить, чего такого можно понапихать в точку восстановления, чтобы её создание занимало в 10 раз больше времени, чем тупое копирование.
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, anton_t, Вы писали:
_>>Наверное Volume Shadow Copy задействовано.
К>Ето шо такое и где управляется?
Я бы по-другому спросил: где это вырубить?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Константин, Вы писали:
К>>Здравствуйте, anton_t, Вы писали:
_>>>Наверное Volume Shadow Copy задействовано.
К>>Ето шо такое и где управляется?
E__>Я бы по-другому спросил: где это вырубить?
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, anton_t, Вы писали:
_>>Наверное Volume Shadow Copy задействовано.
К>Ето шо такое и где управляется?
Здравствуйте, anton_t, Вы писали:
_>>>Наверное Volume Shadow Copy задействовано.
К>>Ето шо такое и где управляется?
_>Служба такая. Для теневого копирования.
Это-то я понял. Я не понял, что такое теневое копирование, нафига оно нужно, что, когда и куда она копирует "теневым образом" и чем это отличается от обычного копирования; как вся эта кухня настраивается и настраивается ли вообще (я не имею в виду просто запуск/остановку службы, с этим тоже всё ясно), ну и так далее. А просто перевести "Shadow Copy" с ангельского я уж как-нибудь и сам смог.
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, anton_t, Вы писали:
_>>>>Наверное Volume Shadow Copy задействовано.
К>>>Ето шо такое и где управляется?
_>>Служба такая. Для теневого копирования.
К>Это-то я понял. Я не понял, что такое теневое копирование, нафига оно нужно, что, когда и куда она копирует "теневым образом" и чем это отличается от обычного копирования; как вся эта кухня настраивается и настраивается ли вообще (я не имею в виду просто запуск/остановку службы, с этим тоже всё ясно), ну и так далее. А просто перевести "Shadow Copy" с ангельского я уж как-нибудь и сам смог.
Для конкретного процесса создаётся "снимок" тома, с которого он может копировать файлы и который не изменяется несмотря на то, что другие прцессы могут менять файлы на этом томе. Применяется для операций бэкапа. Его применение вполне может объяснить тормознутьсть MSI
Здравствуйте, Xander Zerge, Вы писали:
XZ>Нельзя уметь писать по-настоящему грамотный код на, скажем, C++, не зная и не представляя, в какой ассемблерный код это выльется при компиляции.
Я более крамольный весч скажу, ви только таки не обижайтесь тут. Нельзя вообще писать хороший и грамотный код на любом языке, не написав своими руками ни одного более-менее серьёзного оптимизирующего компилятора для языка высокого уровня.
Понимать, как ЯВУ отображается в ассемблер — это хорошо. Но ещё важнее понимать, почему он так отображается, и как этим процессом управлять.
XZ>Поэтому, в критически важных по времени участках, использование собственного ассемблерного кода может дать наилучший результат — если суметь увидеть, что С++ код не будет в точности транслирован в нужную ассемблерную последовательность, и написать кусочек наилучшим образом.
Да что вы все к этому убогому C++ прицепились? И ежу ясно, что оптимальный код из этого языка получить нельзя просто by design.
Здравствуйте, NearBird, Вы писали:
NB> Да что вы все к этому убогому C++ прицепились? И ежу ясно, что оптимальный код из этого языка получить нельзя просто by design.
темку подчистили, но я надеюсь ты помнишь задачки и покажешь, что ты реальный программист, а не виртуал.
Сразу видно что человек даже не знаком с примитивным набором команд своего проца.
Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить
распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики сразу на него пересядут.
Почемуто наличие шэйдеров и инструкций GPU в трехмерных играх никого не смущает,
хотя это тот же ассемблер только для видеокарты.
Для примера расскажу как я выучил ассемблер.
Однажды на нашей фирме возникла необходимость обрабатывать
цветные изображения разрешения 768x576 с четырех видеокамер в реалтайме.
Каждая камера давала по 25 кадров в сек.
Первую версию алгоритма я написал на STL при помощи мегамодных итераторов и функторов.
После сборки в релизе проц справлялся только с 4-мя кадрами в сек. А нужно 100! Что делать?
Я потратил 2 недели на изучение SSE2 и еще неделю на реализацию.
5 десятков вылизанных инструкций свободно молотили 100 кадров, более того проц был загружен на 10%.
В SSE2 есть инструкция psadbw которая за такт считает сумму модулей разностей 16 байтов,
как раз то что там было нужно!
И еще, не существует ни одного нормального кодера/декодера видео, который не написан на асме,
я не имею в виду тот примитив типа mov, xchg и т.п. а современные расширения процессоров
unreg_flex wrote: > Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить > распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики > сразу на него пересядут.
Intel C++ — уже много лет параллелит. Там при максимальном уровне
предупреждений даже выдается гордая надпись: "xx.cpp(yyy) : (col. nn)
remark: LOOP WAS VECTORIZED."
В GCC 4.1 тоже векторизация появилась, в 4.2 ее заметно расширят.
> Почемуто наличие шэйдеров и инструкций GPU в трехмерных играх никого не > смущает, хотя это тот же ассемблер только для видеокарты.
Вот пример такого "ассемблера":
uniform sampler2D coeffsABC;
uniform sampler2D coeffsDEF;
void main( void )
{
// Get the texture coordinates
vec2 st = gl_TexCoord[0].st;
// Read the polynomial coefficients from the textures
vec3 ABC = vec3(texture2D(coeffsABC, st)-0.50196); // 8-bit signed,
vec3 DEF = vec3(texture2D(coeffsDEF, st)-0.50196); // 128/255 -> 0.0
// Construct vectors with powers of u and v
vec3 uv1 = vec3(fract(st*32.0), 1.0);
vec3 u2uvv2 = uv1.xxy * uv1.xyy;
// Calculate the pixel size in (u,v) space for antialiasing
vec4 duvdxy = 32.0*vec4(dFdx(st), dFdy(st));
float stepwidth = 0.5*length(duvdxy);
// Make a checkered pattern to show texel borders
//vec2 cst = floor(mod(st*32.0, 2.0));
//float c = mod(dot(cst, vec2(1.0, 1.0)), 2.0);
// Evaluate the implicit curve polynomial
float f = dot(ABC,u2uvv2) + dot(DEF,uv1);
// Compute the magnitude of the gradient of the polynomial
vec2 gradf = vec2(dot(uv1, vec3(2.0*ABC.x,ABC.y,DEF.x)),
dot(uv1, vec3(2.0*ABC.z,ABC.y,DEF.y)));
float g = inversesqrt(dot(gradf, gradf));
// Set the color to be black when P<=0.0, white otherwise
float a = smoothstep(-stepwidth, stepwidth, f*g);
gl_FragColor = vec4(a, a, a, 1.0);
}
Здравствуйте, Cyberax, Вы писали:
C>unreg_flex wrote: >> Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить >> распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики >> сразу на него пересядут. C>Intel C++ — уже много лет параллелит.
Вот только не там и не то. Я тоже обрабатывал изображения 768x576 с видеокамер
В принципе, VC тоже что-то такое делает, но в критических местах толку от этого ноль.
Здравствуйте, Cyberax, Вы писали:
C>unreg_flex wrote: >> Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить >> распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики >> сразу на него пересядут. C>Intel C++ — уже много лет параллелит. Там при максимальном уровне C>предупреждений даже выдается гордая надпись: "xx.cpp(yyy) : (col. nn) C>remark: LOOP WAS VECTORIZED."
Да, ради интереса если дизассемблировать результаты компиляции IC++ даже простейших программок получается нечто практически нечитаемое , однако работает это быстро, особенно на всяких математически прожорливых программах типа шифрования это заметно.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, vhonest, Вы писали:
V>>Я бы неспешил покупить программу, в которой часть, пусть даже и небольшая, написана на ассемблере, да еще и тщательно оптимизирована V>>Щас ассемблерщики мне быстро минусов наставят
E__>Пишу на java и .net, но вот тебе минус. Чем ассемблер плох-то? Тем более это алгоритмы сжатия — их, имхо, и надо писать на асме, на крайняк — на си. E__>Интересно, вы решили, что на асме нельзя написать качественную программу потому, что сами не можете этого сделать? Ну не стоит всех в свою рамку вписывать.
Почему нельзя? Конечно можно!
Просто мы живем в 21-ом веке, все со временем меняется, мировозрение и подход к разработке тоже меняется...
А) Раньше (80-ые — начало 90-ых) использовали ассемблер по двум причинам:
1. Код написанный "хомо-сапиенсом" будет более логичным, правильным и быстрым, по сравнению с кодом, который сгенерирован компилятором, так как анализаторы и оптимизаторы компиляторов тех времен желали ожидать лучшего.
СЕГОДНЯ НЕ АКТУАЛЬНО: Компиляторы дошли до такого уровня, чтобы оптимизировать код не хуже человека, а в некоторых местах еще и лучше (человек может ошибиться и что-то пропустить, — компилятор — машина — не пропустит).
2. В те времена происходил бурный рост коммандного множества процессоров (раньше 8086 от 80286, 80486 от Pentium — разительно отличались не только рабочими частотами, а еще и объемами поддерживаемых комманд). Компиляторы не успевали за развитием процессоров. Следовательно, для реализации более быстрого кода с применением новых процессорных комманд необходимо было писать вставки на ассемблере — компилятор же все компилировал, грубо говоря, под 8086.
СЕГОДНЯ НЕ АКТУАЛЬНО: Сегодня все компиляторы поддерживают все современные комманды процессоров. А с выходом новых проуессоров, в основном, увеличиваются только рабочие частоты — командные множества остаются такими же. Сегодня основное направление в развитии комманд процессора — математика для 3D графики — которая нужна в основном только разработчикам DirectX и видеокарт. Не уверен, что линейная алгебра потребуется для средства передачи звука.
3. Маниакальная борьба за производительность — оптимизации до байта.
СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько выросли, что намного себе дороже оптимизировать (сколько у тебя весит программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или 50 метров — всем по барабану). А вот глючность никуда не девалась — 20 лет назад бесила пользователей и сегодня пользователей бесит.
Вывод: если проблемы производительности ушли сами собой по течению времени, за чем же ими заниматься?
Не лучше потраченное на это время уделить вопросам стабильности?
Whistler wrote: > СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько > выросли, что намного себе дороже оптимизировать (сколько у тебя весит > программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или > 50 метров — всем по барабану).
В данный момент у меня на компьютере 42 процесса. Большая часть занимает
около мегабайта (общий объем занятой памяти 442Мб), всего памяти 1Гб.
Если бы программы занимали хотя бы в два раза больше места — у меня
памяти бы не хватило. И при этом ничего особого на компьютере не стоит.
