The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

AMD увольняет около 11% сотрудников, opennews (??), 04-Ноя-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


39. "AMD увольняет около 11% сотрудников"  –5 +/–
Сообщение от WishMaster (ok), 04-Ноя-11, 15:12 
>>FPU тоже стоило отправить на помойку истории
> коли вы лично пользуетесь чем-то вроде планшета, на котором нет FPU, то
> это не значит, что этот модуль нужно отправить на помойку истории.
> про совместимость с 32 битами уже написали.

FPU нужен для математических расчетов, что по вашему математику нельзя без FPU посчитать?-)) Особенно для 90% типовых задач?-))


Ответить | Правка | Наверх | Cообщить модератору

41. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 04-Ноя-11, 15:17 
это вы объясните тем конторам, в программах которых используются для расчётов SSE. или всех поставить перед фактом?
;)
Ответить | Правка | Наверх | Cообщить модератору

49. "AMD увольняет около 11% сотрудников"  –5 +/–
Сообщение от WishMaster (ok), 04-Ноя-11, 16:07 
> это вы объясните тем конторам, в программах которых используются для расчётов SSE.
> или всех поставить перед фактом?
> ;)

А я про х87 говорил, а не про SSEx

Ответить | Правка | Наверх | Cообщить модератору

57. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 04-Ноя-11, 16:59 
даааааа?
внимание на картинку! в центре FPU. потом узнаём, что такое FMAC

http://pc.watch.impress.co.jp/img/pcw/docs/331/235/kaigai5.jpg

ссылка
http://aceshardware.freeforums.org/server-cpus-in-2010-and-2...

Ответить | Правка | Наверх | Cообщить модератору

62. "AMD увольняет около 11% сотрудников"  –3 +/–
Сообщение от WishMaster (ok), 04-Ноя-11, 17:42 
Обеспечение даже одного регистра доставшегося от 8086 по наследству это ранзисторы, а тут мы тащим стековый x87, пусть даже внутри стоит декодировщик команд, а не его первоначальная реализация, вопрос на фига?-)))
Ответить | Правка | Наверх | Cообщить модератору

63. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Andrey Mitrofanov (?), 04-Ноя-11, 17:53 
> а тут мы тащим стековый x87

Тащите? Айяйяй! Не надорвитесь, бедненький!! </tag>

Ответить | Правка | Наверх | Cообщить модератору

73. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 04-Ноя-11, 19:44 
FMUL, FDIV, FADD и пр. собираешься выкидывать? или от чего будем конкретно избавляться? это в 70х-80х годах один-два десятка транзисторов могли шибко задеть производительность из-за того, что команды выполнялись последовательно. с приходом внутреннего кэша первого уровня эта проблема постепенно отпала. возникли проблемы совсем другого плана. и исключение MMX из декодировщика (к примеру) дешифровку команд вообще не ускорит. а вами называемое x87 де-факто не существует уже давно, со времён Pentium MMX. ну а сами команды остались ввиду совместимости
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

86. "AMD увольняет около 11% сотрудников"  –3 +/–
Сообщение от WishMaster (ok), 05-Ноя-11, 02:15 
FMUL  и т.д. От всего лишнего, без чего можно обойтись. Задача из третьего курса ВУЗа, предмет микроэлектроника, какой процессор проще разогнать по частоте со 1 млн транзисторов или с 2 млн, при одинаковых прочих равных?-)))) Совместимость способствует лени разработчиков, потому и используют наработки 20 летней давности, уберем часть совместимости, придется оптимизировать софт-))
И еще чем проще процессор, тем проще с ним работать и писать оптимизированное ПО.
Один раз уже встали на грабли с совместимостью, когда наплодили зоопарк адресаций, а ведь можно было спокойно взять и сделать линейный режим 32 бита. Сейчас проще на низкоуровневых языках пишут единицы приложений. А софт написанный на JAVA или С++ спокойно обойдется без лишних команд, допилить нужно будет только компилятор. Про всякие PHP и Со. Я вообще молчу-))
Ответить | Правка | Наверх | Cообщить модератору

90. "AMD увольняет около 11% сотрудников"  +2 +/–
Сообщение от Карбофос (ok), 05-Ноя-11, 02:54 
видимо, чему-то примитивному вас там учили. черезвычайно.
так что там с адресацией? относительную, или абсолютную кто-то не осилил? или с кэшем что-то чего недопонял? если какой недалёкий проф вчухивает какие "прописные истины", то это совсем не значит, что он говорит правду.
а от темы ты ну очень отклонился. фигню начал втюхивать про 20-летнюю давность, игнорируя то, что я написал. прочитал бы уж про микропроессорные архитектуры чего. от твоих знаний пованивает сплошной теорией. пардон, конечно. ничего личного.
ко всему прочему, зоопарк пополнился ARM решениями. оказия вот, что дробилкам на прочих CPU/GPGPU базированных они сливают просто ну очень сильно. можешь, конечно, заявить, что обработка видео, сейсмоданных, погоды, астрономических данных нах человечеству не нужно. да здравствуют счётные палочки и сдвиг регистра.

а хотя, давай напишем с тобой две версии программы обработки матрицы по Гауссу? ты напишешь чисто целочисленными методами а я уж как-нибудь, "по старинке", sse или чем там, с использованием fpu? даже алгоритм можешь выбрать сам.

Ответить | Правка | Наверх | Cообщить модератору

150. "AMD увольняет около 11% сотрудников"  –2 +/–
Сообщение от WishMaster (ok), 06-Ноя-11, 19:18 
Ну напишите. Найдите обратную матрицу по Гауссу элементы матрицы int128, матрица 32 порядка, для описания ПО используете исключительно x87. А заодно посмотрим сколько времени все это безобразие считаться будет-))
А нормальные люди, если их промышленные задачи постоянно требуют расчета обратных матриц, возьмут FPGA и сделают спец. ускоритель на той же шине PCI-e. Сделают один раз и он будет только тем и заниматься, что матрицы считать, а пропускной работы шины для передачи данных более чем достаточно. Если же они эту матрицу раз в год считают, то монопинисуально, сколько она считаться будет. Если есть куча специфических расчетов, то все равно любой писюк сольет дата центру, который заточен под эти расчеты.
Ответить | Правка | Наверх | Cообщить модератору

155. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 06-Ноя-11, 21:17 
то есть у вас пацаны на районе используют сугубо FPGA. просто вау!
речь идёт об универсальности устройств, а не замене чипов FPGA при смене алгоритмов. у меня на компе вычисляются разные задачи, для некоторых хватает целых чисел, для остальных нужно вычислять с плавающей точкой.
а про матрицу можешь не волноваться, я ее смогу вычислить. в том числе знаю, как её вычислять не надо, чтобы сделать расчёты быстро.
я же тебе предложил написать решение задачи сугубо на компе, причем, написал условия. к чему было вообще начинать разговор о алгоритмических решениях в железе? как бы намёк на то, что не видать мне решённой задачи?

кто-то вообще хотел сказать, что процессор - это для лохов или как понять сие? ну и расскажи это тем раздолбаям из top500. единственное, что можно сказать, что абсолютное большинство тех серверов занимается не единственным типовым алгоритмом.

p.s. а ежели найдут какие ошибки в железе, то во что будет обходиться bugfix?
p.p.s. как имплементировать алгоритм высокой сложности в железе, у перечисленных вами есть некие ограничения на кристалл. я понимаю, что упростить можно. упростить, но не примитивизировать, подогнав его под железные требования, со всеми вытекающими.
p.p.p.s. есть куча задач, которые просто невозможно решить в железе. например, со множеством конфигурируемых, скажем, объектов, у которых есть свои индивидуальные характеристики (в том числе и взаимодействие друг с другом), количество объектов может изменяться в зависимости от той же конфигурации, причём изменяться в очень широком спектре. и речь не идет об чистом ОО, подобную задачу можно решить и фунциональным языком, но несколько сложнее.

Ответить | Правка | Наверх | Cообщить модератору

163. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Michael Shigorinemail (ok), 08-Ноя-11, 03:23 
> Если есть куча специфических расчетов, то все равно любой писюк сольет дата центру,
> который заточен под эти расчеты.

Во-первых, в ДЦ те же писюки.  Во-вторых, кластерные технологии в ДЦ мигрируют, но с задержкой на три-пять лет.  Ну и шансов напороться там на GPGPU или FPGA-ускоритель пока наблюдаю ноль, в отличие от.

Так что хорошо бы немного остыть и мух отдельно, котлет отдельно...

Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

168. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 08-Ноя-11, 14:37 
Ну это же не повод не переходить на новые технологии. К нам тут одна специализированная железка приехала, через недельку смогу опубликовать выдержки из документации, если интересно. Что-то мне подсказывает, что в следующем года эти платы на всех углах лежать будут. А с учетом простоты программирования можно получить очень приятный выигрыш на определенном типе задач.
Ответить | Правка | Наверх | Cообщить модератору

172. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Michael Shigorinemail (ok), 09-Ноя-11, 00:29 
> Ну это же не повод не переходить на новые технологии.

Смотря лучше ль они справляются или только щёки надувают...

> К нам тут одна специализированная железка приехала

У нас на стенде есть и писишное счётное железо, и PPC64.  Не помню точно, один из образцов с FPGA на борту или ещё нет.  ARM тоже вот завёлся, но не счётный, хоть и довольно мощный.

А что там? :)

Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

175. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Andrey Mitrofanov (?), 09-Ноя-11, 11:10 
>специализированная железка
> эти платы на всех углах лежать будут.

Пылиться никому не нужные, пинаемые сиротинушки? |) Зачем же сразу "много" покупать...

ЗЫ: Да-да, physics-ы в каждом доме. Уже давно-о... Добрая сказка.

Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

55. "AMD увольняет около 11% сотрудников"  +2 +/–
Сообщение от Yakov Markovitch (?), 04-Ноя-11, 16:52 
>>>FPU тоже стоило отправить на помойку истории
>> коли вы лично пользуетесь чем-то вроде планшета, на котором нет FPU, то
>> это не значит, что этот модуль нужно отправить на помойку истории.
>> про совместимость с 32 битами уже написали.
> FPU нужен для математических расчетов, что по вашему математику нельзя без FPU
> посчитать?-)) Особенно для 90% типовых задач?-))

Вы удивитесь, но, например, все офисные приложения интенсивнейшим образом используют FPU. Шрифты, вёрстка/textflow (это wordprocessor'ы), расчёты в электронных таблицах, бухгалтерские программы и т.д. Мы уж не говорим о графредакторах и всяких программах для обработки фотографий - я говорю _не_ о профессиональных, а о повседневных!

Плавающая арифметика двойной точности без FPU медленнее на 2 порядка (буквально: в 100 раз в лучшем случае). И не рассказывайте про SSE/MMX - они не по другой части. Если Вы только слушаете музыку, смотрите кино и играете в игрушки - это Ваши "типовые задачи" - то да, Вам и без FPU ничего. Но не все такие счастливые.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

65. "AMD увольняет около 11% сотрудников"  –2 +/–
Сообщение от WishMaster (ok), 04-Ноя-11, 18:04 

> Вы удивитесь, но, например, все офисные приложения интенсивнейшим образом используют FPU.
> Шрифты, вёрстка/textflow (это wordprocessor'ы), расчёты в электронных таблицах, бухгалтерские
> программы и т.д. Мы уж не говорим о графредакторах и всяких
> программах для обработки фотографий - я говорю _не_ о профессиональных, а
> о повседневных!

Т.е. Без x87 вы графику не отобразите-)) Шрифты, я так понимаю вы в том числе про сглаживание?-) А логические элементы на которых построены процессоры конечно что-то о синусах знают-)))
80 битные регистры и стековая структура была хороша, когда обычные регистры CPU были 8-16 разрядные, сегодня когда они 64 разрядные, это уже не актуально. А теперь задумайтесь, тот же офис 2003 и 2011, что у него работа с текстом в разу улучшилась, с точки зрения графики?-)))
Бухгалтерия, вы хотите сказать, что подсчета баланса вам не хватит 64 битных регистров общего назначения? Смотрим на типовое ПО -1С, там скорость работы кода это жесть. А все почему, да потому, что не стоит задачи оптимизировать код. И так везде. Будет задача оптимизации кода, даже без x87 все будет работать. Правда придется немного поработать, а не просто в визуальном редакторе менюшки потаскать.

> Плавающая арифметика двойной точности без FPU медленнее на 2 порядка (буквально: в
> 100 раз в лучшем случае). И не рассказывайте про SSE/MMX -
> они не по другой части. Если Вы только слушаете музыку, смотрите
> кино и играете в игрушки - это Ваши "типовые задачи" -
> то да, Вам и без FPU ничего. Но не все такие
> счастливые.

Мои типовые задачи включают в том числе математические вычисления, но наши библиотеки(я про то, что используем на работе) не используют x87. Тот же синус ничто не мешает представить в табличной форме, а графические процессоры очень хорошо работают, как числодробилка. Кстати, отказ от x87 позволил лучше распареллить приложения. И уж объем данных, которые наши приложения обрабатывают существенно больше, чем объем данных у офиса или 1С.
Выдам служебную тайну -))) Биометрическая система распознавания образов и целей, спокойно распознает лица и пальцы без использования x87. Вычислений там тоже достаточно.
И еще момент, если посмотреть на то, как используются ресурсы процессора современными приложениями, то становится грустно.
Откомпилируйте cout<<"the best"; на компиляторах 10 летней давности и на компиляторах 2011 года, будете неприятно удивлены качеством кода-))

Ответить | Правка | Наверх | Cообщить модератору

67. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Yakov Markovitch (?), 04-Ноя-11, 18:55 
>> Вы удивитесь, но, например, все офисные приложения интенсивнейшим образом используют FPU.
>> Шрифты, вёрстка/textflow (это wordprocessor'ы), расчёты в электронных таблицах, бухгалтерские
>> программы и т.д. Мы уж не говорим о графредакторах и всяких
>> программах для обработки фотографий - я говорю _не_ о профессиональных, а
>> о повседневных!
> Т.е. Без x87 вы графику не отобразите-)) Шрифты, я так понимаю вы
> в том числе про сглаживание?-) А логические элементы на которых построены
> процессоры конечно что-то о синусах знают-)))

Всё можно сделать на всём. Мы говорим об эффективности. Логические элементы, из которых сделаны процессоры, не знают и про целочисленную арифметику, кстати - из этого никак не следует, что следует отменить целочисленное ядро.

> 80 битные регистры и стековая структура была хороша, когда обычные регистры CPU
> были 8-16 разрядные, сегодня когда они 64 разрядные, это уже не
> актуально.

Правда? А то, что x87 - это не просто стек и 80-разрядных регистры, а железка, позволяюшая в среднем меньше чем за такт правильно выполнить арифметическую (и не только) IEEE 754 - операцию?

>> Плавающая арифметика двойной точности без FPU медленнее на 2 порядка (буквально: в
>> 100 раз в лучшем случае). И не рассказывайте про SSE/MMX -
>> они не по другой части. Если Вы только слушаете музыку, смотрите
>> кино и играете в игрушки - это Ваши "типовые задачи" -
>> то да, Вам и без FPU ничего. Но не все такие
>> счастливые.
> Мои типовые задачи включают в том числе математические вычисления, но наши библиотеки(я
> про то, что используем на работе) не используют x87. Тот же
> синус ничто не мешает представить в табличной форме,

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

Кстати, любое табличное представление в лучшем случае забивает кеши (когда вам везёт, оно маленькое и вы не промахиваетесь), в худшем - вызывает прокачивание по шине памяти.

> а графические процессоры
> очень хорошо работают, как числодробилка. Кстати, отказ от x87 позволил лучше
> распареллить приложения. И уж объем данных, которые наши приложения обрабатывают существенно
> больше, чем объем данных у офиса или 1С.
> Выдам служебную тайну -))) Биометрическая система распознавания образов и целей, спокойно
> распознает лица и пальцы без использования x87. Вычислений там тоже достаточно.

У вас massively parallelizable application. Это очень ограниченный (хотя и сильно полезный) класс приложений. Увы и ах, огромное количество приложение не-(или плохо-)параллелизуемы. Уж не говорю о том, что сама по себе параллельность требует накладных расходов и на массе задач они просто не окупаются.

> И еще момент, если посмотреть на то, как используются ресурсы процессора современными
> приложениями, то становится грустно.
> Откомпилируйте cout<<"the best"; на компиляторах 10 летней давности и на компиляторах 2011
> года, будете неприятно удивлены качеством кода-))

Вы путаете компиляторы и библиотеки. Качество генерируемого кода сейчас гораздо выше. И даже с библиотеками всё не так просто - iostream не лучший пример. Попробуйте откомпилировать следующую простую программку компилятором 10-летней давности (ну, например, gcc 3.0, можете взять текущий gcc 3.3) и gcc 4.6.2 - сильно удивитесь (в обоих случаях параметры компиляции -O2 -S). Попробуйте, не пожалеете:


#include <numeric>
#include <stdio.h>

static int fn()
{
    static const int a[] = { 2, 6, 1, 4, 0 } ;
    return std::accumulate(a + 0, a + sizeof a/sizeof *a, 0) ;
}

int main(int, char *[])
{
    printf("%d\n", fn()) ;
}

Ответить | Правка | Наверх | Cообщить модератору

88. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 05-Ноя-11, 02:45 
> Всё можно сделать на всём. Мы говорим об эффективности. Логические элементы, из
> которых сделаны процессоры, не знают и про целочисленную арифметику, кстати -
> из этого никак не следует, что следует отменить целочисленное ядро.

Конечно не следует, следует другое, что при любой организации команд на выходе по любому набор нулей и единиц.

> Правда? А то, что x87 - это не просто стек и 80-разрядных
> регистры, а железка, позволяюшая в среднем меньше чем за такт правильно
> выполнить арифметическую (и не только) IEEE 754 - операцию?

У которой тоже есть траблы с точностью и если четко не знать ограничений стандарта, то при математических вычислениях можно встать на хорошие грабли. Это к вопросу о том, что x87 не панацея/
Это к вопросу о таблицах Брадиса и точности-))


> Вы собираетесь тащить таблицы Брадиса? Если не секрет, с какой дискретностью/точностью
> вы хотите их представить?

От задачи зависит. Кстати, как думаете, как процессор синус считает?-)
То, что в ваших задачах вам может
> хватать _очень_ грубых приближений, не означает, что это всегда так. Или,
> всё-таки, промежуточные значения вы будете сильно не спеша считать?

Опять таки от задачи зависит. нет универсальных алгоритмов, для каждой задачи разработчик включает мозг и думает как ему ее решить. Пример, если у меня SVGA разрешение, то мне на фиг не надо считать координаты с точностью до 25 знака. Точно также, как сдиг заменяет деление на 2. И если я считаю загрузку состава, то мне int достаточно, ну хотя бы потому, что 60 вагонов порой предел. Но современные горе программеры любят на всякий случай использовать float. А когда тыкаешь пальцем в этот говонокод, то объяснить они зачем у них так сделано они не в состоянии.-)

> Кстати, любое табличное представление в лучшем случае забивает кеши (когда вам везёт,
> оно маленькое и вы не промахиваетесь), в худшем - вызывает прокачивание
> по шине памяти.

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

> У вас massively parallelizable application. Это очень ограниченный (хотя и сильно полезный)
> класс приложений. Увы и ах, огромное количество приложение не-(или плохо-)параллелизуемы.
> Уж не говорю о том, что сама по себе параллельность требует
> накладных расходов и на массе задач они просто не окупаются.

Правильно, поэтому в каждом конкретном приложении или, если быть точнее, в каждом типе приложений стоит использовать те или иные подходы.

Завтра попробую откомпилировать. Кстати по поводу компиляторов, попробуйте  откомпилировать приложение, так чтобы оно было 64 битным работало только на процессорах с SSE4 и по возможности их использовало, не использовало команд x87. Не расскажите, как в  том же Visual Studio это сделать?


Ответить | Правка | Наверх | Cообщить модератору

114. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Yakov Markovitch (?), 05-Ноя-11, 15:28 
> От задачи зависит. Кстати, как думаете, как процессор синус считает?-)

:) Это-то понятно. Но часто модель, предоставляемая вам сопроцессором, его ISA, работает быстрее (для конкретного класса задач), чем то же самое, написанное "вручную" через другую ISA (напр. SSE4). Скажем, накладные расходы по раскладыванию в регистры для SSE для подзадачи, которая "естественно" решается в стековой модели x87. Понятно, что у последних моделей x86-64 x87, фактически, слой эмуляции над SSE. Но он, этот слой, действительно часто работает эффективнее не только программиста, но и компилятора.

>[оверквотинг удален]
>> всё-таки, промежуточные значения вы будете сильно не спеша считать?
> Опять таки от задачи зависит. нет универсальных алгоритмов, для каждой задачи разработчик
> включает мозг и думает как ему ее решить. Пример, если у
> меня SVGA разрешение, то мне на фиг не надо считать координаты
> с точностью до 25 знака. Точно также, как сдиг заменяет деление
> на 2. И если я считаю загрузку состава, то мне int
> достаточно, ну хотя бы потому, что 60 вагонов порой предел. Но
> современные горе программеры любят на всякий случай использовать float. А когда
> тыкаешь пальцем в этот говонокод, то объяснить они зачем у них
> так сделано они не в состоянии.-)

Согласен. Но, мне кажется, вы всё-таки чересчур категоричны - огромное количество программ _уже_ написаны и написаны хорошо, отлично работают с x87 и переписывать и/или перекомпилировать их лежит в диапазоне от "контрпродуктивно" до "физически невозможно".

Я уж не говорю о таком нюансе как то, что есть масса (современных!) процессоров архитектуры x86 у которых SSE нет, а x87 есть - всякие Geode, etc., для использования в промышленных или/и встраиваемых системах, им тоже бывает нужно считать плавающую точку, а накладные расходы на эмуляцию велики, а там нужно считать каждый такт.

> Правильно, поэтому в каждом конкретном приложении или, если быть точнее, в каждом
> типе приложений стоит использовать те или иные подходы.

Опять же, полностью согласен. Но и поэтому тоже выбрасывать x87 не нужно - он ведь практически ничего не стоит на современных CPU, меньше 1% площади кристалла (эмуляция поверх SSE4, как уже говорилось) и никак не влияет на основной конвейер, т.е. выбросив его мы ничего не получаем, а теряем много.

> Завтра попробую откомпилировать. Кстати по поводу компиляторов, попробуйте  откомпилировать
> приложение, так чтобы оно было 64 битным работало только на процессорах
> с SSE4 и по возможности их использовало, не использовало команд x87.
> Не расскажите, как в  том же Visual Studio это сделать?

Вот не знаю. Кстати, вы работаете с Visual Studio? Если да, то как там обстоят дела с качеством генерируемого кода? Моё последнее знакомство было с компилятором из 2003-й студии, я в те годы занимался многоплатформенной разработкой и знал довольно много про поведение разных компиляторов на разных платформах, но сейчас довольно давно сижу только под Линухом и как-то упустил вопрос.

Тогда между 2003-й и msvc6 прогресс был разительный, а как обстоят дела в 2010 vs 2008 vs 2003?


Ответить | Правка | Наверх | Cообщить модератору

146. "AMD увольняет около 11% сотрудников"  –1 +/–
Сообщение от WishMaster (ok), 06-Ноя-11, 15:37 
> :) Это-то понятно. Но часто модель, предоставляемая вам сопроцессором, его ISA, работает
> быстрее (для конкретного класса задач), чем то же самое, написанное "вручную"
> через другую ISA (напр. SSE4). Скажем, накладные расходы по раскладыванию в
> регистры для SSE для подзадачи, которая "естественно" решается в стековой модели
> x87. Понятно, что у последних моделей x86-64 x87, фактически, слой эмуляции
> над SSE. Но он, этот слой, действительно часто работает эффективнее не
> только программиста, но и компилятора.

А тут мы приходим к выбору, либо мы упрощаем процессор и поднимаем частоту к примеру, либо остаемся на старой архитектуре.. И тут возникает нюанс, что быстрее будет работать. А в среднем по больнице, какая система будет работать быстрее с x87 на 3 ГГц или без онного на 5ГГц?

> Согласен. Но, мне кажется, вы всё-таки чересчур категоричны - огромное количество программ
> _уже_ написаны и написаны хорошо, отлично работают с x87 и переписывать
> и/или перекомпилировать их лежит в диапазоне от "контрпродуктивно" до "физически невозможно".

Попытка тащить весь воз программ со времен царя Гороха оборачивается понижением общей эффективности в долгосрочной перспективе. Могу привести маленький пример, himem,sys ver.3.0 после того, как из него выкидываешь поддержку всякой экзотики, раскручиваешь макросы и перекомпилируешь, скорость работы памяти поднимается на 20-30%, хотя сам по себе он работал нормально. Так и тут порой проще с нуля раз в 10-15 лет написать, чем таскать за собой исторические кирпичи. И еще нужно смотреть востребованность старого софта по отношению к рынку, если старый софт востребован 10% рынка, то для 90% проще использовать новые процессоры, а для экзотичного рынка оставить старую архитектуру.

> Я уж не говорю о таком нюансе как то, что есть масса
> (современных!) процессоров архитектуры x86 у которых SSE нет, а x87 есть
> - всякие Geode, etc., для использования в промышленных или/и встраиваемых системах,
> им тоже бывает нужно считать плавающую точку, а накладные расходы на
> эмуляцию велики, а там нужно считать каждый такт.

Встраиваемые системы это отдельный разговор, там рынок с другими критериями.
Мы же говорим о массовом рынке х86, если вспомнить начало разговора.

> Опять же, полностью согласен. Но и поэтому тоже выбрасывать x87 не нужно
> - он ведь практически ничего не стоит на современных CPU, меньше
> 1% площади кристалла (эмуляция поверх SSE4, как уже говорилось) и никак
> не влияет на основной конвейер, т.е. выбросив его мы ничего не
> получаем, а теряем много.

1% площади вроде ни о чем, но как этот процент влияет на топологию кристалла большой вопрос. Я уже приводил пример с разводкой платы, когда одна лишняя сигнальная линия и нам нужно добавлять отдельный печатный слой. А есть менее прозрачные вещи, как паразитные наводки, с ними вообще все весело, особенно, если вспомнить частоты на которых современные микропроцессоры работают.

> Тогда между 2003-й и msvc6 прогресс был разительный, а как обстоят дела
> в 2010 vs 2008 vs 2003?

Не претендую на глобальное исследование, от VS2011 двоякое ощущение, если использовать новый стандарт С++, то код получается весьма приличным и скорость действительно выше, но если взять исходники 10 летней давности и попытаться их откомпилировать, то код получается мягко скажем убогим. У нас есть один проект, который в данный момент переписывается на полное соответствие ISO/IEC 14882:2011. Первые результаты вдохновляют код получился прозрачнее и стоимость его поддержки и модернизации в дальнейшем уменьшится. Но это не большой проект порядка 700 тыс. строк. На выходе мы получаем прозрачную совместимость сразу с несколькими компиляторами, что не может не радовать. А для специфических приложений для наших задач пока фаворитом является компилятор от Интела.

Ответить | Правка | Наверх | Cообщить модератору

151. "AMD увольняет около 11% сотрудников"  +3 +/–
Сообщение от Aleksey Salow (ok), 06-Ноя-11, 19:23 
> А в среднем по больнице, какая
> система будет работать быстрее с x87 на 3 ГГц или без
> онного на 5ГГц?

У клиента есть софтина с x87. Так, и какой же тут правильный вариант...

> Так и тут порой проще с нуля раз в 10-15 лет написать, чем таскать за собой исторические кирпичи.

То-то я смотрю в определёных нишах есть спрос на прогеров на коболе. Вы ж, надеюсь, понимаете что программисты писавшие код давным давно либо в дурке либо ктулху их забрал. И какие черви там в коде водятся тоже толком никто не знает. На переписывание, тестирование, внедрение и исправление потребуется дохера денег и времени. А большинству ехать нужно, а не шашечки. Да и лихо переписать софт 15-и летней давности не получится, в нём баги давно стали фичами которые, есно, нигде не задокументированы и повторять их будет очень сложно, а править не всегда возможно.

Ответить | Правка | Наверх | Cообщить модератору

169. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 08-Ноя-11, 14:43 
> У клиента есть софтина с x87. Так, и какой же тут правильный
> вариант...

Стоимость поддержки этой софтины? График изменения задач клиента в ближайшие пять лет и т..п. Получив ответы на подобные вопросы, можно получить ответ какой вариант правильный.

> То-то я смотрю в определёных нишах есть спрос на прогеров на коболе. ....

Финансовый софт, консервативный рынок будут использовать старые доработки только до тех пор, пока не увидят, что новые разработки позволят им заработать больше денег или снизить затраты на инфраструктуру. Это нормально. Любые технологии программирования решают только одну задачу - задачу бизнеса. Пока старый инструмент рентабельный его менять не будут, как только он перестает быть рентабельным, но его не меняют ввиду костности руководителей, к примеру, то бизнес умирает.

Ответить | Правка | Наверх | Cообщить модератору

170. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Aleksey Salow (ok), 08-Ноя-11, 15:10 
>> У клиента есть софтина с x87. Так, и какой же тут правильный
>> вариант...
> Стоимость поддержки этой софтины?

Один специально обученный инженер который следит чтобы всё работало.

> График изменения задач клиента в ближайшие пять лет
> и т..п.

Да никаких изменений. Софтина следит за оборудованием. Оборудование построено во время союза, работает, работает эфективно, улучшаять пока некуда.

> Получив ответы на подобные вопросы, можно получить ответ какой
> вариант правильный.

Последние кардинальные изменения были 17лет назад. Переползли с ЕС-ок на x86 с нетварью и досом. Вот с тех пор оно так и крутиться, даже на семёрку водрузили dosbox и подняли весь нужный софт. И живут дальше. Учитывая общее состояние отрасли - врядли что-то там поменяется в ближайшие 10 лет.

Ответить | Правка | Наверх | Cообщить модератору

171. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 08-Ноя-11, 23:54 
Судя по описание и новое железо для вас тоже не актуально, тогда о чем разговор - работает, пусть себе работает.
Ответить | Правка | Наверх | Cообщить модератору

173. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Michael Shigorinemail (ok), 09-Ноя-11, 00:32 
> Последние кардинальные изменения были 17лет назад. Переползли с ЕС-ок
> на x86 с нетварью и досом. Вот с тех пор оно так и крутиться,
> даже на семёрку водрузили dosbox и подняли весь нужный софт.

dosbox всё же грустноват -- если что, IBM для ПФ РФ делал на dosemu.

PS: крутиТся :)

Ответить | Правка | Наверх | Cообщить модератору

174. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Aleksey Salow (ok), 09-Ноя-11, 02:03 
>> Последние кардинальные изменения были 17лет назад. Переползли с ЕС-ок
>> на x86 с нетварью и досом. Вот с тех пор оно так и крутиться,
>> даже на семёрку водрузили dosbox и подняли весь нужный софт.
> dosbox всё же грустноват -- если что, IBM для ПФ РФ делал
> на dosemu.

может быть и на dosemu бы взлетело. Просто пришли компы с win7, а на них досовский софт не взлетает. Позвонили мне, а я сказал первое что вспомнил. Позже сказали спасибо и что всё работает, что собсна и нужно было.

> PS: крутиТся :)

Ага, видать видать какой-то мусор в голове крутился в тот момент.

Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру