Исправление NiTr0, (текущая версия) :
Такой код утилизирует и 5% х86. Это ничего не меняет.
в любом случае - утилизация больше. а частоты, благодаря нормальной архитектуре вместо сверхширокого монстра, в разы выше.
Эксперты в треде. Для справки - х86 не может нагрузить более 4портов, но ты продолжай.
кто-то попутал порты исполнения с выходами декодеров, и продолжает невозмутимо болтать ерундой...
Ветвления - проблема тех, кто писал эту лапшу в 99% случае. Всё это либо убирается, либо обходится. Ветвления никакого отношения к портам не имеют.
ну-ну, уберите ветвления из обхода деревьев.
Во-первых поиск в дереве не утилизирует ни одного порта и в х86.
да-да, исполняется святым духом вестимо...
Во-вторых с чего ты мне вообще выклал своё дерево? Оно мне не упало. Да и вообще это memory bound задача.
да потому что работа с деревьями - это и выделение/освобождение памяти (как из кучи, так и системной), и поиск данных, и прочее, прочее, прочее... в отличие от перемножения матриц, на что только и годны DSP типа эльбруса.
В третьих - типичное проявление глупости и неспособности думать в рамках вменяемости. Один поиск не утилизирует, но поиски независимые, что даёт выполнять сколь угодно много поисков в параллель, собственно частично как и вставка, но с потолком.
да не вопрос, есть 10 значений вам, напишите алгоритм, который за один проход вставит эти 10 значений в RB-дерево. вы же специалист по алгоритмам? или - специалист по болтанию ерундой?
Поэтому для вас есть хипертрейдинг и на 25портов, если они на них равномерно распределено всё множество операций - можно повесить в 10раз больше гипетредов.
да нет там никакого «гипертрейдинга» (что бы вы под этим словом ни воображали). есть один тупой конвейер, тупо молотящий один поток MIMD команд. динамически модифицировать который (в стиле «а эти блоки сейчас будут выполнять не команды ветки А, а команды ветки Б») невозможно в принципе (вернее - программно-то возможно, самомодифицирущимся кодом, вот только кроме дополнительных тормозов и лучей поноса от «счастливцев», которым это придется отлаживать, ничего более не даст).
Исходная версия NiTr0, :
Такой код утилизирует и 5% х86. Это ничего не меняет.
в любом случае - утилизация больше.
Эксперты в треде. Для справки - х86 не может нагрузить более 4портов, но ты продолжай.
кто-то попутал порты исполнения с выходами декодеров, и продолжает невозмутимо болтать ерундой...
Ветвления - проблема тех, кто писал эту лапшу в 99% случае. Всё это либо убирается, либо обходится. Ветвления никакого отношения к портам не имеют.
ну-ну, уберите ветвления из обхода деревьев.
Во-первых поиск в дереве не утилизирует ни одного порта и в х86.
да-да, исполняется святым духом вестимо...
Во-вторых с чего ты мне вообще выклал своё дерево? Оно мне не упало. Да и вообще это memory bound задача.
да потому что работа с деревьями - это и выделение/освобождение памяти (как из кучи, так и системной), и поиск данных, и прочее, прочее, прочее... в отличие от перемножения матриц, на что только и годны DSP типа эльбруса.
В третьих - типичное проявление глупости и неспособности думать в рамках вменяемости. Один поиск не утилизирует, но поиски независимые, что даёт выполнять сколь угодно много поисков в параллель, собственно частично как и вставка, но с потолком.
да не вопрос, есть 10 значений вам, напишите алгоритм, который за один проход вставит эти 10 значений в RB-дерево. вы же специалист по алгоритмам? или - специалист по болтанию ерундой?
Поэтому для вас есть хипертрейдинг и на 25портов, если они на них равномерно распределено всё множество операций - можно повесить в 10раз больше гипетредов.
да нет там никакого «гипертрейдинга» (что бы вы под этим словом ни воображали). есть один тупой конвейер, тупо молотящий один поток MIMD команд. динамически модифицировать который (в стиле «а эти блоки сейчас будут выполнять не команды ветки А, а команды ветки Б») невозможно в принципе (вернее - программно-то возможно, самомодифицирущимся кодом, вот только кроме дополнительных тормозов и лучей поноса от «счастливцев», которым это придется отлаживать, ничего более не даст).