The OpenNET Project / Index page

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

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


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

Оглавление

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

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


26. "AMD увольняет около 11% сотрудников"  +1 +/–
Сообщение от Карбофос (ok), 04-Ноя-11, 13:58 
>FPU тоже стоило отправить на помойку истории

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

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

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ообщить модератору

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

Обычному х87 FPU давно уже пора на свалку истории. Убить в пользу SIMD команд, ну и хватит.

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

52. "AMD увольняет около 11% сотрудников"  –4 +/–
Сообщение от WishMaster (ok), 04-Ноя-11, 16:14 
>>>FPU тоже стоило отправить на помойку истории
>> коли вы лично пользуетесь чем-то вроде планшета, на котором нет FPU, то
>> это не значит, что этот модуль нужно отправить на помойку истории.
>> про совместимость с 32 битами уже написали.
> Обычному х87 FPU давно уже пора на свалку истории. Убить в пользу
> SIMD команд, ну и хватит.

MMX тоже стоит оправить на свалку, вслед за х87

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

74. "AMD увольняет около 11% сотрудников"  –6 +/–
Сообщение от Аноним (-), 04-Ноя-11, 20:00 
> MMX тоже стоит оправить на свалку, вслед за х87

Не возражаю, им все-равно уже никто не пользуется. Некрофилы с пентиум ммх пусть сами себе софт компилят, имхо.

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

78. "AMD увольняет около 11% сотрудников"  +1 +/–
Сообщение от Карбофос (ok), 04-Ноя-11, 20:46 
неплохо вообще знать, как оно работает. хотя бы приблизительно. а потом уж делать громкие заявления.
Ответить | Правка | Наверх | Cообщить модератору

89. "AMD увольняет около 11% сотрудников"  –4 +/–
Сообщение от WishMaster (ok), 05-Ноя-11, 02:52 
> неплохо вообще знать, как оно работает. хотя бы приблизительно. а потом уж
> делать громкие заявления.

Схему процессора не предоставите, чтобы предметный разговор был?-) А то нравятся мне господа, которые утверждают, что экономии не будет только на основании блок схемы.-))
Так к размышлению, если вы когда-то печатные платы разводили, то прекрасно знаете, что минус 2 сигнальные линии и можно сделать печатную плату на слой меньше, в процессорах те же приколы, только на микро уровне. А уж проблемы с разведением питания, вообще отдельная песня. И счет порой идет на микроамперы. Дальнейшее очевидно или нет?

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

91. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 05-Ноя-11, 02:56 
мне еще раз объяснить про кэши и конвейерную обработку команд, или дальше будешь выдавать желаемое за действительное?
Ответить | Правка | Наверх | Cообщить модератору

106. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от saNdro (?), 05-Ноя-11, 12:25 
> мне еще раз объяснить про кэши и конвейерную обработку команд, или дальше
> будешь выдавать желаемое за действительное?

Нет смысла спорить со студентом (возможно бывшим. не известно что хуже), которому что-то там рассказали в институте. По его постам видно что он в этой области ТЕОРЕТИК.

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

109. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 05-Ноя-11, 13:06 
Объясните, как реализован кэш и обработчик команд на языке электроники, а я вам пальцем ткну, в каком месте можно оптимизировать в каком нет-))) Только учтите, что разработка микропроцессоров моя специальность, а последние 10 лет разрабатываю сигнальные процессоры,  реализация аппаратного Фурье преобразования, к примеру,  требует хорошего понимания схемотехники и навыков оптимизации, особенно, когда процессор мультипоточный-)
Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

111. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 05-Ноя-11, 14:25 
>Объясните, как реализован кэш и обработчик команд на языке электроники

так вы и этого не знаете? o_O
>а последние 10 лет...

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

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

138. "AMD увольняет около 11% сотрудников"  –2 +/–
Сообщение от WishMaster (ok), 06-Ноя-11, 04:37 
Когда у людей кончают аргументы они переходят на личности, к сожалению я не ошибся. Привести схему вы не в состоянии, чтобы фактически доказать, что я не прав. Заодно и другим показать, что мое мнение не верно, причем показать не столько мне, сколько остальным людям, которые читают данный тред.
Да и общий стиль беседы говорит о многом. Что-то мне подсказывает, что диаграмму различий транзакции  i960 в 8 битном и 32 битном режиме у  LRDYRCV# вы с ходу не нарисуете, а чему равен Cclk тоже не скажите. Кстати, а что будет при записи 1 в CCR0.2 у S80296SA? Если есть задача создать 4 канальный анализатор спектра для сигналов 0-1 МНz c аппаратным Фурье преобразованием для шины PCI 2.0, что лучше для этих целей i960 или S80296SA?
Список продолжить это программа 3 курса провинциального ВУЗА более, чем 12 летней давности между прочим, уровень знаний на 3. -)) Видимо в Макдональдсе этому тоже учат-))))

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

144. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 06-Ноя-11, 14:26 
я тебе уже много чего тут писал, а ты тут басни о "переходе на личности" пишешь. ты всего лишь по каждому аргументу слил (отмолчался, переключил разговор на другую тему). хороший пример - я написал, что удаление мозолящих твои глазки MMX команд не приведет к ускорению декодирования ввиду буферизации, ты переключил разговор на "дайте мне схему и я вам покажу, где можно оптимизировать". мне что, схему декодера тебе дать на пару миллионов транзисторов? вот как раз - обратись в AMD или Intel, может они тебе дадут. именно к этому сводятся твои разговоры. заодно, можешь туда попроситься работать, заменишь еще пару тысяч инженеров, не меньше, это точно. они даже рады будут. покаются, что делали туфту, выкинут FPU и будет всем щастье.
единственное, что вижу, то, что ты всего лишь повторяешься и уже примелькался "третий курс" с аппаратным Фурье. это то, на чем ты застопорился? я тоже тебе могу накидать задач по оптимизации кода, только будет выглядеть это СОВСЕМ НЕ В ТЕМУ. хотя, судя по написанной тобой "революционной" оптимизации процессоров, тебе бы может надо было подучить предмет "микропроцессорная техника"? если тебе уж лично до такой степени как бельмо в глазу мешает FPUnits и особенно команды умножения и деления чисел с плавающей точкой, то пользуйся ARM и разрабатывай свои сигнальные процессоры на них, не стесняйся.
Ответить | Правка | Наверх | Cообщить модератору

147. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 06-Ноя-11, 15:43 
Т.е. я правильно понимаю вашу позицию, что количество транзисторов не потребляемую мощность? А также количество транзисторов не влияет на топологию кристалла и как следствие на его стоимость?
Да/нет?


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

149. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 06-Ноя-11, 17:24 
не влияет на потребляемую мощность. Ачепятка.


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

154. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 06-Ноя-11, 21:04 
снова переключаешь тему. ты говорил о том, что нужно выкинуть и не нужно. просто примитивно пытаешься выдать желаемое за действительное? или пытаешься выставить других тупыми?
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

156. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 07-Ноя-11, 00:54 
Так влияет или нет? Кто темы переключает?:-)) Простой вопрос, на который достаточен ответ да/нет. Минус блок минус вентили, или транзисторы, как больше нравится. Так что с потреблением и топологией кристалла? Ответ очевиден, но видимо сильно не удобен, я правильно понимаю?-)))
Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

158. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Карбофос (ok), 07-Ноя-11, 02:09 
ответ будет очень неудобен для тебя. т.к. есть такая фишка, которая называется процентное соотношение. еще раз повторяю для особо упёртых: конвейерная обработка команд и кэширование кода сведут твои упрощения к фактически нулю. зато новый процессор можно назвать "геморроимум" ввиду совместимости сверху вниз.
впрочем, как и выкидывание блоков адресации, вроде сегментной и относительной адресации.
все эти "упрощения", вернее - громкие заявления, можно лишь назвать негромким выпердом. селяви. так что пудри мозги дальше.
Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

160. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от WishMaster (ok), 07-Ноя-11, 12:59 
Ответ, так и не получен, что с потреблением, при уменьшении количества транзисторов при том же тех. процессе? Полная совместимость и так понятно, что теряется. Что с топологией кристала? Прямой вопрос был задан, а на него получен ответ совершенно о другом. Или вопрос про потребление настолько сложен, что на него не ответить?-))) Есть такая фишка процентное соотношение, чего к чему? Суть вашей мегафишки не раскрыта.-)
Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

164. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от Michael Shigorinemail (ok), 08-Ноя-11, 03:30 
> Ответ, так и не получен

Дядьки, замните уже для ясности. :)

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

118. "AMD увольняет около 11% сотрудников"  +/–
Сообщение от fork (??), 05-Ноя-11, 16:31 
> Обычному х87 FPU давно уже пора на свалку истории. Убить в пользу
> SIMD команд, ну и хватит.

Да по-моему оно всё через RISC ядро реализовано уже давно mmx sse x87 в том числе.

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

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

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




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

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