Застой в компиляторах - Форум на исходниках

WWW.ИСХОДНИКИ.РУ cpp.sources.ru

java.sources.ru web.sources.ru soft.sources.ru

jdbc.sources.ru asp.sources.ru api.sources.ru

  Форум на исходниках
  C / C++ / Visual C++
  Застой в компиляторах
СПРОСИТЬ  ОТВЕТИТЬ
профайл | регистрация | faq

Автор Тема:   Застой в компиляторах

rodion опубликован 06-11-2001 10:43 MSK
Чем можно объяснить застой в компиляторах.
Когда существует 4 пень а компилировать можно только под 1?
Flex Ferrum опубликован 06-11-2001 00:05 MSK
А зачем? Система комманд различается только в той области, которая может использоваться только из ассемблера... Так что...
rodion опубликован 06-11-2001 14:53 MSK
Но развее хотя бы MMX не ускоряет програму на 15%?
Flex Ferrum опубликован 06-11-2001 16:35 MSK
Компилятору еще объяснить нужно, где использовать MMX, а где нет. Подобного рода оптимизация ИМХО уже руками делается.
Sourcer опубликован 06-11-2001 23:28 MSK
Да путь хотябы нормально доделают существующие...
Почти у всех компиляторов есть свои глюки и один из них общий...
Это когда компилятор не выдерживает многочисленные условия....
Я уже с этим и на pascal и на VC bи на TASM
сталкивался...
Причём когда таие проблемы встречались, другие компиляторы нормально всё компилировали и всё работало...
Хотя и те тожа компилировали, но извините когда идёт дохера условий и какието почемуто не обрабатываются когда прогу на VC откомпилиш, но в тоже время в DJGPP всё работало...
В VS:
дохера условий(сверх сложных)
потом
c=1;
if(c==1) //это уловие почемуто не выпоняется
{
}
Даже на TASM такое было, но MASM всё нормально компилил!
а на паскалее всемирно извесный глюк с
writeln("zzz");
read(x);
writeln("zzz");
read(x);
writeln("zzz");
read(x);
writeln("zzz");
read(x);
writeln("zzz");
read(x);
writeln("zzz");
read(x);
.....
Короче надо сначало нормально доделать нынешние компиляторы хотябы под 86...
А потом уже делать для 4го пня
x опубликован 07-11-2001 04:21 MSK
1.баги в компиляторах здесь абсолютно нипричем
2.насчет оптимизации под
a)оптимизация под MMX дает прирост только для операций вывода через память=остальное редкие 2D случаи
б)а собственно проблема совместимости SSE,SSE2,3DNow!,3DNow+= где совместимость?
3.а кому нужна скорость работы=последние пару лет производительность компа просто НЕКУДА ДЕВАТЬ
4.ты неправильно понимаешь задачи текущего комерческого рынка=если понимаешь их вообще
почитай элджера
5.компиляторы развиваются=просто из-за дебильной приверженности к стандартам ANSI просто мешает им развиваться=пример C#
Lord_DEMON опубликован 07-11-2001 13:13 MSK
Господа! какая оптимизация? вы читали что такое ММХ и прочая помойка?
это реально использовать, если вы пишете саморучно Direct X или Open GL
ну или при декодировании потока mpeg и подобных. Все что там есть, это исполнение одной инструкцией кучи задач, наприример все перемножить и сложить (x*a+y*b+z*c). Если в программе нет работы с матрицами и сложной математики, то ММХ, SSE и все остальное не поможет. А если ваша прога использует Direct X или другие подобные API, то можете быть спокойны, все само собой оптимизируется :)
А обычные IFы это не ускорит :)
кстати на счет ошибок в компиляторах, они часто бывают, если включить оптимизацию кода на ускорение, я например вообще стараюсь не настраивать тонко компилятор, стабильней работает :)
m_fox опубликован 07-11-2001 17:54 MSK
Правильно говоришь. Вы почитайте что такое MMX, а потом уже и говорите.
Поддержка компиляторами более новых процессоров и не нужна. Система комманд почти не меняется.
А с проверками сам процессор справляется. Там всякие конвееры, предсказания и т.п., что делается без компиляторов.
lamo опубликован 07-11-2001 21:30 MSK
радион.
я вот смотрю на твои вопросы ...
а ты вроде аспирант там какойто.
право странно.
а вот прикинь ктонить из твоих стьюдентов
сюда заглянет и посмотрит на твой експиренс.
Banev опубликован 07-11-2001 22:41 MSK
Больше на школьника похоже, ну максимум второй курсю
Banev опубликован 07-11-2001 22:43 MSK
в смысле, курс - второй
x опубликован 08-11-2001 04:37 MSK
2 Lord_Lemon & fov :Don't Fuck my brain

оптимизация даже под MMX дает много даже на if-ах = ты никогда не пробовал cmp через MMX
реализовать?
нет?
а ведь он быстрее сравнивает несмотря на то что ему приходится 2 числа обработать
MMX как раз успевает сравнить без простоя конвейера=без инициализации предсказания переходов
другое дело что еще надо из mm* результат извлечь=но на x86-64 этой проблемы нет!!!!!
так что оно будет жить!!!!!!!
да вот еще=если строковые опреции переписать на ASM MMX=то ты получишь увеличение производительности в 5-7 раз
только не надо гнать что в твоей проге строк нету
а насчет OpenGL & DirctX=ты хоть веришь в то что сам сказал?
если будешь MMX в 3D юзать у тебя вектор в один прекрасный момент вектор плохо нормируется и все
MMX дает много=но увы C не приспособлен для него
вот еще пример команда xchg
почему в С нет возможности ее использования?
это же готовый на аппаратном уровне семафор!!!!!
Lord_DEMON опубликован 08-11-2001 10:28 MSK
2х
Каюсь, сравнение не писал.
По поводу плохо нормируется, я не имел ввиду именно ММХ, она ж целочисленная, я иммел ввиду остальных ее детей.
Ясен пень, что Си для этого не преспособлен, но асм вставки никто не отменял, и при желании можно все.
Если на столько критична производительность
Кстати, о сравнениях, отключение предсказания переходов - это плохо для "правильного" цикла. Надо будет как нить сравнить скорость...
rodion опубликован 08-11-2001 14:13 MSK
Мне как раз и нужна работа с матрицами и сложными вычислениями а обчаться с asm нет времини (и судентов:)
x опубликован 09-11-2001 02:50 MSK
я имел ввиду не отсутствие предсказания с MMX на P1=а то что MMX cmp выполняется за 1 микрооперацию
rodion опубликован 09-11-2001 11:24 MSK
Тогда: Может кто нибудь поможет российской науке и пришлет мне библиотеку для работы числами с плавующей запятой (double)для MMX, 2,3 пня
СПРОСИТЬ  ОТВЕТИТЬ
Перейти:

E-mail | WWW.ИСХОДНИКИ.RU

Powered by: Ultimate Bulletin Board, Freeware Version 5.10a
Purchase our Licensed Version- which adds many more features!
© Infopop Corporation (formerly Madrona Park, Inc.), 1998 - 2000.

Автор	Тема: Застой в компиляторах
rodion	опубликован 06-11-2001 10:43 MSK Чем можно объяснить застой в компиляторах. Когда существует 4 пень а компилировать можно только под 1?
Flex Ferrum	опубликован 06-11-2001 00:05 MSK А зачем? Система комманд различается только в той области, которая может использоваться только из ассемблера... Так что...
rodion	опубликован 06-11-2001 14:53 MSK Но развее хотя бы MMX не ускоряет програму на 15%?
Flex Ferrum	опубликован 06-11-2001 16:35 MSK Компилятору еще объяснить нужно, где использовать MMX, а где нет. Подобного рода оптимизация ИМХО уже руками делается.
Sourcer	опубликован 06-11-2001 23:28 MSK Да путь хотябы нормально доделают существующие... Почти у всех компиляторов есть свои глюки и один из них общий... Это когда компилятор не выдерживает многочисленные условия.... Я уже с этим и на pascal и на VC bи на TASM сталкивался... Причём когда таие проблемы встречались, другие компиляторы нормально всё компилировали и всё работало... Хотя и те тожа компилировали, но извините когда идёт дохера условий и какието почемуто не обрабатываются когда прогу на VC откомпилиш, но в тоже время в DJGPP всё работало... В VS: дохера условий(сверх сложных) потом c=1; if(c==1) //это уловие почемуто не выпоняется { } Даже на TASM такое было, но MASM всё нормально компилил! а на паскалее всемирно извесный глюк с writeln("zzz"); read(x); writeln("zzz"); read(x); writeln("zzz"); read(x); writeln("zzz"); read(x); writeln("zzz"); read(x); writeln("zzz"); read(x); ..... Короче надо сначало нормально доделать нынешние компиляторы хотябы под 86... А потом уже делать для 4го пня
x	опубликован 07-11-2001 04:21 MSK 1.баги в компиляторах здесь абсолютно нипричем 2.насчет оптимизации под a)оптимизация под MMX дает прирост только для операций вывода через память=остальное редкие 2D случаи б)а собственно проблема совместимости SSE,SSE2,3DNow!,3DNow+= где совместимость? 3.а кому нужна скорость работы=последние пару лет производительность компа просто НЕКУДА ДЕВАТЬ 4.ты неправильно понимаешь задачи текущего комерческого рынка=если понимаешь их вообще почитай элджера 5.компиляторы развиваются=просто из-за дебильной приверженности к стандартам ANSI просто мешает им развиваться=пример C#
Lord_DEMON	опубликован 07-11-2001 13:13 MSK Господа! какая оптимизация? вы читали что такое ММХ и прочая помойка? это реально использовать, если вы пишете саморучно Direct X или Open GL ну или при декодировании потока mpeg и подобных. Все что там есть, это исполнение одной инструкцией кучи задач, наприример все перемножить и сложить (xa+yb+z*c). Если в программе нет работы с матрицами и сложной математики, то ММХ, SSE и все остальное не поможет. А если ваша прога использует Direct X или другие подобные API, то можете быть спокойны, все само собой оптимизируется :) А обычные IFы это не ускорит :) кстати на счет ошибок в компиляторах, они часто бывают, если включить оптимизацию кода на ускорение, я например вообще стараюсь не настраивать тонко компилятор, стабильней работает :)
m_fox	опубликован 07-11-2001 17:54 MSK Правильно говоришь. Вы почитайте что такое MMX, а потом уже и говорите. Поддержка компиляторами более новых процессоров и не нужна. Система комманд почти не меняется. А с проверками сам процессор справляется. Там всякие конвееры, предсказания и т.п., что делается без компиляторов.
lamo	опубликован 07-11-2001 21:30 MSK радион. я вот смотрю на твои вопросы ... а ты вроде аспирант там какойто. право странно. а вот прикинь ктонить из твоих стьюдентов сюда заглянет и посмотрит на твой експиренс.
Banev	опубликован 07-11-2001 22:41 MSK Больше на школьника похоже, ну максимум второй курсю
Banev	опубликован 07-11-2001 22:43 MSK в смысле, курс - второй
x	опубликован 08-11-2001 04:37 MSK 2 Lord_Lemon & fov :Don't Fuck my brain оптимизация даже под MMX дает много даже на if-ах = ты никогда не пробовал cmp через MMX реализовать? нет? а ведь он быстрее сравнивает несмотря на то что ему приходится 2 числа обработать MMX как раз успевает сравнить без простоя конвейера=без инициализации предсказания переходов другое дело что еще надо из mm* результат извлечь=но на x86-64 этой проблемы нет!!!!! так что оно будет жить!!!!!!! да вот еще=если строковые опреции переписать на ASM MMX=то ты получишь увеличение производительности в 5-7 раз только не надо гнать что в твоей проге строк нету а насчет OpenGL & DirctX=ты хоть веришь в то что сам сказал? если будешь MMX в 3D юзать у тебя вектор в один прекрасный момент вектор плохо нормируется и все MMX дает много=но увы C не приспособлен для него вот еще пример команда xchg почему в С нет возможности ее использования? это же готовый на аппаратном уровне семафор!!!!!
Lord_DEMON	опубликован 08-11-2001 10:28 MSK 2х Каюсь, сравнение не писал. По поводу плохо нормируется, я не имел ввиду именно ММХ, она ж целочисленная, я иммел ввиду остальных ее детей. Ясен пень, что Си для этого не преспособлен, но асм вставки никто не отменял, и при желании можно все. Если на столько критична производительность Кстати, о сравнениях, отключение предсказания переходов - это плохо для "правильного" цикла. Надо будет как нить сравнить скорость...
rodion	опубликован 08-11-2001 14:13 MSK Мне как раз и нужна работа с матрицами и сложными вычислениями а обчаться с asm нет времини (и судентов:)
x	опубликован 09-11-2001 02:50 MSK я имел ввиду не отсутствие предсказания с MMX на P1=а то что MMX cmp выполняется за 1 микрооперацию
rodion	опубликован 09-11-2001 11:24 MSK Тогда: Может кто нибудь поможет российской науке и пришлет мне библиотеку для работы числами с плавующей запятой (double)для MMX, 2,3 пня