Оптимизация ПО для AMD «Bulldozer»

Снова травы пыхнул?
Причем тут вообще сайрикс?

Геод это типичная «пятая нога» среди амд-поделий, так же как и итаниум на пару с XScale...Правда интел на ИА-64 в поряде заработал, в отличии от...

Это затормозит прогресс

Как?

Придётся ждать по полгода прежде чем использовать разработки.

Intel так делали - AMD преимуществ это не дало.

Заводы по производству комплектующих пока что не копируются как информация, почти нахаляву.

Нисколько - никто не запрещает сначала регистрировать патент, а потом публиковать код.

Ага, подготовить и зарегистрировать пачку патентов можно мгновенно, как на точку за бухлом сгонять.

Придётся ждать по полгода прежде чем использовать разработки.
Вы путаете. В этот раз AMD отправили свои патчи для поддержки Bulldozer в ядро и gcc после выпуска процессора. Пройдёт не меньше полугода, прежде чем ядро с поддержкой Bulldozer окажется во всех основных дистрибутивах и не меньше года до того, как дистристроители перейдут на сборку софта новой версией gcc. Я предложил отправить эти же патчи за полгода до выпуска процессора. Ещё раз: где тут торможение прогресса? Где конкретно?
> Заводы по производству комплектующих пока что не копируются как информация, почти нахаляву.
Тогда кому какое дело до выложенного кода? Вон, об особенностях IB (которые могут быть выяснены в результате анализа выложенных Intel патчей, реализующих поддержку IB) с начала 2011 года никаких тайн нет.
> Ага, подготовить и зарегистрировать пачку патентов можно мгновенно, как на точку за бухлом сгонять.
Попробуйте сообразить: что же тогда нужно сделать, чтобы за полгода до выпуска процессора нужные патенты уже были зарегистрированы? (Вообще говоря они и так к этому времени обычно уже зарегистрированы, поэтому я вообще не понимаю, к чему вы заговорили про патенты.) Подумайте, а как же эту проблему решают в Intel, где патчи для поддержки IB были подготовлены для выкладывания в открытый доступ за год до выпуска процессора?

получился i8008 и i8080. Второй, кстати, AMD отреверсила. Как и последующие до 486

Эмммм, а ничего что AMD все процесоры до K5 выпускала по лицензии интеловской? Зачем им было реверсить то если им интел сама сказала что и каким делать а чего не делать чтобы не посягать на номер 1 хозяина.

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

Да и фиг с ним, с ведром, няшка селинукс периодически жрёт так, что тормозит больше чем на 20% и всем пофиг. Добавили бы в федору глибц с поддержкой бульдозера а с остальным можно не торопиться:)

Я предложил отправить эти же патчи за полгода до выпуска процессора. Ещё раз: где тут торможение прогресса? Где конкретно?

Грамотное пейсание кучи бумажек занимает много времени а до этого нужно провести кучу тестов, а после внесения изменений в железо переписывать мануал, возможно не один раз. И ради чего? Ради рекомендаций которые неначем проверить.

Тогда кому какое дело до выложенного кода? Вон, об особенностях IB (которые могут быть выяснены в результате анализа выложенных Intel патчей, реализующих поддержку IB) с начала 2011 года никаких тайн нет.

Конечно у интел тайн нет, их «тайна» это средства и оборудование на котором можно банально впихнуть больше транзисторов на единицу площади. Причём не просто впихнуть а учесть идеи конкурентов и быстро воплотить в железе. Примерно как у китайцев, тем покажи новый телефон и через месяц увидишь его клонов на рынке.

Попробуйте сообразить: что же тогда нужно сделать, чтобы за полгода до выпуска процессора нужные патенты уже были зарегистрированы? (Вообще говоря они и так к этому времени обычно уже зарегистрированы, поэтому я вообще не понимаю, к чему вы заговорили про патенты.) Подумайте, а как же эту проблему решают в Intel, где патчи для поддержки IB были подготовлены для выкладывания в открытый доступ за год до выпуска процессора?

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

Вообще говоря они и так к этому времени обычно уже зарегистрированы

Что-то может быть полезно зарегистрировать в последний момент, чтобы у обходящих патентное ограничение было меньше времени.

Придётся ждать по полгода прежде чем использовать разработки.

Мне жаль твоего заказчика

Да и фиг с ним, с ведром
А ещё 12309, поэтому давайте не оптимизировать софт. Фиг с ним же, правда? И вообще - Федоропроблемы.
> Грамотное пейсание кучи бумажек
Я писал про патчи. Какие, нафиг, бумажки?
> Конечно у интел тайн нет, их «тайна» это средства и оборудование на котором можно банально впихнуть больше транзисторов на единицу площади. Причём не просто впихнуть а учесть идеи конкурентов и быстро воплотить в железе. Примерно как у китайцев, тем покажи новый телефон и через месяц увидишь его клонов на рынке.
Напоминаю, что Intel платит AMD отчисления за x86_64. Написанное вами сейчас вообще к чему было?
> Попробуйте, сообразить, а почему бы не запатентовать технологию производства ЯО и средств его доставки? Запатентовали бы, выложили патенты вместе с чертежами в интернет и никто больше не смог бы повторить данную технологию.
См. ответ на предыдущую цитату. Вы всё ещё продолжаете настаивать на краже технологий, как извинение за задержку публикации патчей для поддержки нового процессора?
> Что-то может быть полезно зарегистрировать в последний момент, чтобы у обходящих патентное ограничение было меньше времени.
В последний момент уже семплы по журналам рассылают, поэтому этот аргумент в таком виде лишён смысла.

Я писал про патчи. Какие, нафиг, бумажки?

Да нафиг нужны патчи только для gcc, это не единственный в мире компилятор.

Напоминаю, что Intel платит AMD отчисления за x86_64. Написанное вами сейчас вообще к чему было?

Ну и пусть платит, какое это имеет отношение к вопросу. Некоторые идеи и опыт легко прихватизировать бесплатно.

Вы всё ещё продолжаете настаивать на краже технологий, как извинение за задержку публикации патчей для поддержки нового процессора?

В fpc они наврят ли будут патчить, так что нафиг, пусть пишут писульку _для_всех_ нормально и столько, сколько нужно.

Да нафиг нужны патчи только для gcc, это не единственный в мире компилятор.
Не единственный, но первый, в которой стоит коммитить вендору CPU.
> Некоторые идеи и опыт легко прихватизировать бесплатно.
В первую очередь которые не запатентованы - но никто не заставляет откладывать патентование.
> В fpc они наврят ли будут патчить, так что нафиг, пусть пишут писульку _для_всех_ нормально и столько, сколько нужно.
Почему вы считаете, что либо одно, либо другое?

Специально для тех, кто не умеет читать:

druganddrop-2> В тоже время у intel всё просто работает и не надо изобретать велосипеды при программирование под особенные процессоры.

Quasar> 4.2 См. Itanium

Jetty> 4.2 4.2 См Geode

Quasar сделал вполне справедливое замечание, что отсутствие необходимости оптимизации ПО для процессоров Интел - большое преувеличение. Итаниум тому хорошая иллюстрация.

Ты счёл, что этим он обидел Интел. После чего решил немножко обкакать АМД.

Так кто из нас обкурился? :-)

Так кто из нас обкурился? :-)

Виртуал квазара

Не единственный, но первый, в которой стоит коммитить вендору CPU.

После того как сделаешь дело коряво и наполовину, то его становится в лом улучшать - и так что-то работает, сойдёт. И не переживай ты так - лица, каждый год меняющие проц на более мощный, недостатком бабла не страдают, если и переплатят немного, то невелика потеря. К тому времени, когда проц немного подешевеет, патчи должны быть уже дописаны. Люди покупающие топовое железо всегда рискуют получить от него максимальный эффект с некоторой задержкой.

В первую очередь которые не запатентованы - но никто не заставляет откладывать патентование.

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

Почему вы считаете, что либо одно, либо другое?

Прочитать пыдыэфку с пояснениями проще и полезнее чем выковыривать знания из патчей gcc.

Ничего такого я не считывал... Фишка в том что под Геод тоже надо отдельно пилить, в отличии от существующих аналогов например на арме...

После того как сделаешь дело коряво и наполовину, то его становится в лом улучшать - и так что-то работает, сойдёт. И не переживай ты так - лица, каждый год меняющие проц на более мощный, недостатком бабла не страдают, если и переплатят немного, то невелика потеря. К тому времени, когда проц немного подешевеет, патчи должны быть уже дописаны. Люди покупающие топовое железо всегда рискуют получить от него максимальный эффект с некоторой задержкой.
Не аргументы. Патчи должны были быть дописаны как раз к выпуску проца.
> Ну и как запатентовать лужи и ямы на дороге? Как будто если маршрут в объезд препятствий будет запатентоват, то все остальные ездуны окажутся законодательно обязаны ездить по самым плохим участкам дороги. А если другие участники движения узнают о препятствии в последний момент, то не получат дополнительных преимуществ, это называется конкурентная борьба.
Думаете, есть какие-то ямы на дороге AMD, о которых не знают в Intel, или наоборот? Обе компании уже набили приличное количество шишек.
> Прочитать пыдыэфку с пояснениями проще и полезнее чем выковыривать знания из патчей gcc.
Нет, почему вы считаете, что AMD должны делать либо то, либо другое хотя бы за полгода до выпуска процессора? Почему бы не делать и то и другое максимально быстро и качественно? Этим ведь занимаются не одни и те же люди.

Не аргументы.

Аргументы, постоянно так получается. Купи сегодня железо с 16 Гб ДДР3 и ты сможешь запустить сабж Relics Of Annorath Правда, оно того стоит?

Патчи должны были быть дописаны как раз к выпуску проца.

Если патчи тебе что-то должны, то у них и спрашивай.

Думаете, есть какие-то ямы на дороге AMD, о которых не знают в Intel, или наоборот? Обе компании уже набили приличное количество шишек.

Должны быть, иначе развитие железа двигалось быстрее и скачками.

Почему бы не делать и то и другое максимально быстро и качественно? Этим ведь занимаются не одни и те же люди.

Они даже проц пока до ума не успели довести, недоложили транзисторов, так старались побыстрее железяку выбросить на рынок а тут от них требуют ещё и документацию за полгода до релиза. Вот так тебе и напишут: железяка выйдет через полгода но четверть задуманных фич запихнуть в неё не успеем. Это не опенсорс в котором автор должен постоянно недоделывать программу чтобы сообщество его ценило и не забывало:)

Аргументы, постоянно так получается. Купи сегодня железо с 16 Гб ДДР3 и ты сможешь запустить сабж
Вы упороты? Это машины девелоперов, они у себя замерили, и выложили результаты с конфигами. Думаете, такой движок собирается менее, чем с 16 Гб ОЗУ?
> Если патчи тебе что-то должны, то у них и спрашивай.
Совсем-совсем простое предложение уже не можете распарсить?
> Должны быть, иначе развитие железа двигалось быстрее и скачками.
Не факт, не только от «ям» всё зависит (по крайней мере тех, которые могут быть обнаружены путём анализа патчей).
>а тут от них требуют ещё и документацию за полгода до релиза
Документацию придумали требовать вы, я же посетовал на то, что они могли бы, но не делают даже половины того, что делает Intel. В итоге конечно же делают, но тогда когда уже все прогнали тесты и облили их грязью. А ведь этого можно было бы избежать.

Вы упороты? Это машины девелоперов, они у себя замерили, и выложили результаты с конфигами.

Не я переводил тот текст, но при беглом взгляде именно такое впечатление.

Думаете, такой движок собирается менее, чем с 16 Гб ОЗУ?

Тогда это гуано а не пользовательский движок если для его компиляции нужно 16 гиг ОЗУ. В общем, зачем нужны скриптовые движки для таких, монстров, очевидно: экономятся сутки компиляции на каждом пробном запуске.

Совсем-совсем простое предложение уже не можете распарсить?

А вы мою точку зрения на этот запрос.

Документацию придумали требовать вы, я же посетовал на то, что они могли бы, но не делают даже половины того, что делает Intel.

А лично мне сферические патчи в GCC, без документации для всех, не очень интересны.

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

Со своей грязью они разберутся сами. Многие опенсорсники делают не лучше: вроде бы русские аффторы а самим даже коротенький хелп по русски накатать западло. А аэмдэшники задержали английский хэлп, так что всё в пределах такой нормы:)

Вот даже не знаю как вам ответить, наверное в начале имеет смысл поинтересоваться т.н. интервальными вычислениями.

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

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

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

Вот даже не знаю как вам ответить, наверное в начале имеет смысл поинтересоваться т.н. интервальными вычислениями.

За ссылку на теорию, спасибо, однако конкретных цифр можно не ожидать, как я понимаю?

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

Ну когда в компилятор встроят блок чтения мыслей, чтобы ему стало понятно, что же на самом деле имел в виду разработчик, написав этот код (в основном все же true или false возвращает сравнение), тогда...

Не я переводил тот текст, но при беглом взгляде именно такое впечатление.
> Тогда это гуано а не пользовательский движок если для его компиляции нужно 16 гиг ОЗУ. В общем, зачем нужны скриптовые движки для таких, монстров, очевидно: экономятся сутки компиляции на каждом пробном запуске.
В общем вы признаёте, что ваше предположение о том, что 16 Гб ОЗУ являются системными требованиями игры было ошибочным?
> А вы мою точку зрения на этот запрос.
То есть патчи для gcc и ядра к выпуску проца не нужны, можно и позже выложить, так по-вашему?
> А лично мне сферические патчи в GCC, без документации для всех, не очень интересны.
Как одно мешает другому, вы мне скажите?
> Со своей грязью они разберутся сами. Многие опенсорсники делают не лучше: вроде бы русские аффторы а самим даже коротенький хелп по русски накатать западло. А аэмдэшники задержали английский хэлп, так что всё в пределах такой нормы:)
Вы уже забыли с чего начался разговор? С того, что они задержали не только хелп.

За ссылку на теорию, спасибо, однако конкретных цифр можно не ожидать, как я понимаю?

Абсолютно правильно понимаете. Бессмысленно даже пытаться приводить конкретные значения без конкретных данных и вычислений. Но, что бы не быть уж совсем голословным, приведу очевидный пример:

float x, t;
...
t = 1/x;
if (x != 1/t) {
 /*результат может превзойти все ожидания*/
}

Ну когда в компилятор встроят блок чтения мыслей, чтобы ему стало понятно, что же на самом деле имел в виду разработчик, написав этот код (в основном все же true или false возвращает сравнение), тогда...

Как раз наоборот! Посмотрите на __builtin_expect в gcc что он делает и для чего нужен.

You may use __builtin_expect to provide the compiler with branch prediction information.

В общем вы признаёте, что ваше предположение о том, что 16 Гб ОЗУ являются системными требованиями игры было ошибочным?

Моё? Это общее предположение участников топика. Пока сам не попробую, а делать это в лом, запустить этого монстра на 4 гигах, я более склонен рассматривать пессимистические сценарии. В процессе навешивания дополнительных рыл и фич, системные требования игры склонны к увеличению а у автора топовое железо и он не станет после компиляции вынимать из системника «лишнюю» оперативку чтобы заметить лажу.

То есть патчи для gcc и ядра к выпуску проца не нужны, можно и позже выложить, так по-вашему?

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

Как одно мешает другому, вы мне скажите?

Разрабам железа виднее, куда приложить усилия в первую, а куда во вторую очередь.

Вы уже забыли с чего начался разговор? С того, что они задержали не только хелп.

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

Пока сам не попробую, а делать это в лом, запустить этого монстра на 4 гигах, я более склонен рассматривать пессимистические сценарии.
Даже зная системные требования Unigine Heaven и OilRush? (На том же движке, рекомендуемые требования - 2 Гб ОЗУ.)
> У каждого свои приоритеты
Приоритет простой - к выпуску железки хорошо бы, чтобы при работе с ней не было багов хотя бы в последних версиях мейнстримных дистрибутивов. Для этоо патчи должны быть выложены заранее, например как в случае IB.
> Разрабам железа виднее, куда приложить усилия в первую, а куда во вторую очередь.
Разрабам железа может и виднее, а вот эффективным менеджерам над ними - нет.
> Одно с другим связано, в данном случае целесообразность установки телеги впереди лошади вызывает сомнения.
Я уже отвечал на это (последнее предложение).

float x, y, t;
 ... 
t = y/x;
if (y != t*x) {
 /*результат может превзойти все ожидания*/
 }

в общем так и не понятно, чем t=y/x и u=z/x более точно, чем v=1/x, t=y*v, u=z*v.

__builtin_expect есть не везде, однако везде я могу переформулировать код сравнения.

[code]t = 1/x; if (x != 1/t)[/code]

Даже студент-прогульщик знает, что при работе с плавающей точной нельзя использовать строгие сравнения. Ошибка в последних разрядах заложена в природу конечности точности вычислений, вопрос лишь в её величине. Никто не гарантирует, что 1.0==(100.0/100) или 1.0==0.1*10.

И, кстати, с учетом того, что абсолютная погрешность чисел в IEEE зависит от модуля степени, а не от мантиссы, оперировать обратными величинами ничуть не менее точно.

Даже зная системные требования Unigine Heaven и OilRush? (На том же движке, рекомендуемые требования - 2 Гб ОЗУ.)

А может автор решил качественно просчитать каждую сосновую иголочку? А их в лесу миллиарды.

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

А разве есть баги?

Разрабам железа может и виднее, а вот эффективным менеджерам над ними - нет.

Либастрал?

AMD опубликовала «Руководство по оптимизации ПО на 15h»

Уже год как. Ну, полгода - точно =)

сейчас уже вроде для следующих вариантов архитектуры публикуют, для piledriver, vishera, sepang... в новостях проскакивало.

в опенсорсных прогах бульдозер быстрее чем i7, иногда )

Задний привод энивей, гораздо эффективнее

Там с рулёжкой грабли вырисовываются.

Зависит от рук водителя

А при переднем приводе водитель вообще не обязан постоянно рулить и никакие сложные рулевые системы не требуются.

А может автор решил качественно просчитать каждую сосновую иголочку?
Не решил. Либастрал, да.
> А разве есть баги?
Ну вам ли не знать, какие есть баги у Linux вплоть до 3.1 с Bulldozer?
> Либастрал?
В данном случае долгий опыт общения с техподдержкой и некоторыми сотрудниками AMD. Да, собственно, он и не нужен - Бригман пишет о таких вещах без утайки.

Ну вам ли не знать, какие есть баги у Linux вплоть до 3.1 с Bulldozer?

Моя использвать AMD Athlon 64 X2 Dual Core Processor 5400+ и федора 15, собирать самый собираемый проект за секунды и иметь баги в виде частых задержек потоков на несколько миллисекуд. Увеличение количества ядер и улучшения связей между ними, должно сделать выполнения более плавной, но обновлять железяки в этом году не планировать - чуток попозже это будет выгодней.

Вы проще скажите, вы о проблеме с планировщиком при работе на Bulldozer знаете или нет?

проблеме планировщика бульдозера у мелкософта? Да

Знаю что нормальный планировщик для бульдозера ещё не написан, НО... Но меня интересуют технологии абстрагирования от проблем планировщика и ограничений операционки, в том числе реализованные на уровне камня. Проще говоря, пусть система подтормаживает, но то что мне надо - летает.

проблеме планировщика бульдозера у мелкософта? Да
Нет, в Linux. В помните, в какой версии Linux появились патчи, добавляющие его поддержку?

Знаю что нормальный планировщик для бульдозера ещё не написан
А нужно, чтобы он уже был написан, для чего его стоило начинать писать гораздо раньше.
> Но меня интересуют технологии абстрагирования от проблем планировщика и ограничений операционки, в том числе реализованные на уровне камня.
Какие, например? (Названия технологий.)

Да по моему не было ещё) Специально недавно качал и make xconfig запускал, чтобы глянуть. - Пусто.

Было, в 3.2 первая версия патчей для поддержки Bulldozer.

Знаю что нормальный планировщик для бульдозера ещё не написан

А нужно, чтобы он уже был написан, для чего его стоило начинать писать гораздо раньше.

Сапог и восьмёрка типа не нужны, для игр и утилит хватает хрюши а для неё всё равно планировщик переписывать не станут, поэтому для очень многих пользователей такая спешка _бесполезное_занятие_. Что камень сам подхватил, то и рулёз а новый камень однозначно быстрее того, с которого обновился. В линуксах, в меньшей степени, тоже самое - очень нудно и напряжно постоянно обновляться ради прироста нескольких % производительности - само когда-нибудь заработает.

Какие, например? (Названия технологий.)

Гуглить, как разработчики обзывают каждую конкретную фичу я не буду и не надейся. Могу описать своими словами. Первое: при установке имеющейся и используемой на данный момент операционки на новое железо, оное должно продемонстрировать прирост производительности и удобства. Операционки выпущены задолго до выходы железа. Второе: абстрагирование от граблей и повышение совместимости на уровне ЯП.

поэтому для очень многих пользователей такая спешка _бесполезное_занятие_
Видимо из-за людей рассуждающих так же, как и вы, железо выходит с кривыми драйверами на старте.
> В линуксах, в меньшей степени, тоже самое - очень нудно и напряжно постоянно обновляться ради прироста нескольких % производительности - само когда-нибудь заработает.
Нужно, чтобы эти проценты были «освоены» сразу, т.к. за них «уплочено».
> Гуглить, как разработчики обзывают каждую конкретную фичу я не буду и не надейся.
Тогда в сад с такой аргументацией.

Видимо из-за людей рассуждающих так же, как и вы, железо выходит с кривыми драйверами на старте.

Не надо переводить стрелки. Кривые драйвера частично такие благодаря слишком быстрому обновлению модельного ряда и постоянно ломаемой совместимости в линуксах. Производители железяк насильно не заставляют пейсателей ПО ломать быстрее чем строить. Что-то большой пользы от смены версии иксов, кроме совместимости с новым ведром:), я не ощущаю а дрова для них нужны свежие. С планшетами таже байда - есть дрова которые нормально работали а потом перестали даже собираться.

Нужно, чтобы эти проценты были «освоены» сразу, т.к. за них «уплочено».

За что именно ты платил, это твои личные фантазии имеющие весьма опосредованное отношение к реалу.

Тогда в сад с такой аргументацией.

А ты хотел нагуглить что не понимаешь и не разобравшись в сути вопроса вынести своё авторитетное суждение;) Твоя аргументация не лучше и сводится к «хотю то, хотю это, дайте мне быстро...».

Не надо переводить стрелки.
Стрелки с AMD на пользователей, которым не нужна спешка, перевели вы.
> Кривые драйвера частично такие благодаря слишком быстрому обновлению модельного ряда и постоянно ломаемой совместимости в линуксах. Производители железяк насильно не заставляют пейсателей ПО ломать быстрее чем строить. Что-то большой пользы от смены версии иксов, кроме совместимости с новым ведром:), я не ощущаю а дрова для них нужны свежие.
Сейчас вы переводите ещё раз, но теперь уже на разработчиков СПО, как бы не замечая факт, что у Intel в отношении поддержки новых CPU в Linux ситуация обстоит гораздо лучше, и не пользователи, которым не нужна спешка, ни разработчики СПО, Intel в этом не мешают почему-то. Почему, интересно?
> За что именно ты платил, это твои личные фантазии имеющие весьма опосредованное отношение к реалу.
Я надеюсь, что вы понимаете, что не только за железо? За Bulldozer я пока не платил, кстати. Может быть возьму что-нибудь на Trunity позже.
> А ты хотел нагуглить что не понимаешь и не разобравшись в сути вопроса вынести своё авторитетное суждение;)
Да знаю я об этих фичах, просто не вечно же ходить на костылях? А вот то, что вы не можете назвать ни одну из них, это уже само по себе символизирует.

Сейчас вы переводите ещё раз, но теперь уже на разработчиков СПО

А на них и переводить не надо - постоянная ломка совместимости это _норма_ многих разработчиков. Тот же mplayer постоянно патчат под новый, несовместимый x264.

как бы не замечая факт, что у Intel в отношении поддержки новых CPU в Linux ситуация обстоит гораздо лучше, и не пользователи, которым не нужна спешка, ни разработчики СПО, Intel в этом не мешают почему-то. Почему, интересно?

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

Я надеюсь, что вы понимаете, что не только за железо?

В комплекте с радеонами обычно идёт диск с игрушкой, с процессорами - только подсохшая термопаста на радиаторе.

Да знаю я об этих фичах, просто не вечно же ходить на костылях? А вот то, что вы не можете назвать ни одну из них, это уже само по себе символизирует.

Вы говорите сами с собой о своих мыслях которые считаете единственно значимыми и ценными.

А на них и переводить не надо - постоянная ломка совместимости это _норма_ многих разработчиков. Тот же mplayer постоянно патчат под новый, несовместимый x264.
Ещё раз, простой вопрос: почему бы на момент выпуска CPU Linux не поддерживать фичи этого CPU? Что в этом плохого? Аналогичный вопрос про gcc.
> Ну и флаг им в руки - штеуд выдас лишнюю скорость для всех, в результате жабонетфлешпитоны отожрутся на халявных харчах и затормозят персоналки почти до прежнего состояния.
И AMD выдаст, когда нужные патчи будут в gcc и ядре, в результате жабонетфлешпитоны отожрутся на халявных харчах и затормозят персоналки почти до прежнего состояния. Так?
> В комплекте с радеонами обычно идёт диск с игрушкой, с процессорами - только подсохшая термопаста на радиаторе.
Вы не поняли вопрос?
> Вы говорите сами с собой о своих мыслях которые считаете единственно значимыми и ценными.
Напоминаю, вы написали «Но меня интересуют технологии абстрагирования от проблем планировщика и ограничений операционки, в том числе реализованные на уровне камня» Иначе говоря вас интересуют костыли обратной совместимости под предыдущие версии ОС и ПО. Само по себе это конечно же неплохо, но почему вы на них так зациклены? («меня интересуют»)