Сообщение Re: Сегодняшние лидеры Intel — не инженеры от 10.08.2020 5:40
Изменено 10.08.2020 5:42 netch80
Re: Сегодняшние лидеры Intel — не инженеры
Здравствуйте, Шахтер, Вы писали:
Ш>здесь
Ш>Что в России, что в Америке -- если лидеры компании не имеют экспертизы в предметной области, компания проиграет конкуренцию.
Можно подумать, период, когда руководство Intel имело техническую "экспертизу", оно рулило лучше
Единственное, на чём реально Intel выехал — это на обратной совместимости (дорогой ценой) и поддержке Windows, плюс агрессивный маркетинг и создание имиджа "nobody fired for bying Intel" (как IBM, но на ранг пониже).
Технические же дизайнерские решения ещё в лучшие времена были через один ужаснее другого:
Крупные проекты, заведомо понятные как провальные для тех, кто не имел неуправляемых амбиций:
Авантюра с i8089.
Бессмысленный 80286.
Авантюра с iAPX 432.
Pentium 4 (взлетел чисто на маркетинге, впоследствии выброшен целиком).
Авантюра с IA64, как следствие — принятие не менее кошмарного AMD64 в неизменном виде (AMD можно понять, у них ресурсы были катастрофически в обрез, но Intel?)
Или пройдёмся по архитектуре x86: просто открываю документацию и начинаю последовательно рассматривать:
Сверхнеудобный для парсера формат команд (суффиксы MOD-REG-R/M и SIB в конце), чудовищно усложняющий разбор потока команд. Не исправлен при переходе на 32 или 64 бита.
Сохранение адресации сегментными регистрами внутри пространства виртуальной памяти (как следствие — сильное удорожание управления виртуальными машинами, это уже имея перед глазами S/370, где этот вопрос был решён много лет тому назад).
Сохранение однобайтовых команд в 32-битном режиме там, где и 4 байта не повредило бы (IN/OUT, CMC, HLT, и прочие, которые не встретишь в выхлопе современного компилятора), и как следствие — необходимость длинных [E]VEX.
Неуправляемо блокирующийся и сериализующий XCHG. Неуправляемо жёсткий memory ordering.
Сохранение RCL, RCR на несколько бит при наличии SHLD, SHRD.
OF в старшем байте Flags, при наличии двух незанятых бит в младшем.
Дебильные флаги у BSF, BSR.
И прочая и прочая — я и 1/10 от проблем не перечислил.
Верю, что прежнее руководство Intel было технарями, но их компетентность закончилась в районе 1980 года. То есть сейчас всё идёт правильно: при таком грузе дебильных решений в прошлом и проблемах совместимости, при том, что альтернативные архитектуры и соответственно производители поджимают по всем фронтам — только маркетинг и способен придержать падение. (Я не смотрел текущий расклад и принимаю как предпосылку утверждение про направление смены руководства.)
Ш>здесь
Ш>Что в России, что в Америке -- если лидеры компании не имеют экспертизы в предметной области, компания проиграет конкуренцию.
Можно подумать, период, когда руководство Intel имело техническую "экспертизу", оно рулило лучше
Единственное, на чём реально Intel выехал — это на обратной совместимости (дорогой ценой) и поддержке Windows, плюс агрессивный маркетинг и создание имиджа "nobody fired for bying Intel" (как IBM, но на ранг пониже).
Технические же дизайнерские решения ещё в лучшие времена были через один ужаснее другого:
Крупные проекты, заведомо понятные как провальные для тех, кто не имел неуправляемых амбиций:
Авантюра с i8089.
Бессмысленный 80286.
Авантюра с iAPX 432.
Pentium 4 (взлетел чисто на маркетинге, впоследствии выброшен целиком).
Авантюра с IA64, как следствие — принятие не менее кошмарного AMD64 в неизменном виде (AMD можно понять, у них ресурсы были катастрофически в обрез, но Intel?)
Или пройдёмся по архитектуре x86: просто открываю документацию и начинаю последовательно рассматривать:
Сверхнеудобный для парсера формат команд (суффиксы MOD-REG-R/M и SIB в конце), чудовищно усложняющий разбор потока команд. Не исправлен при переходе на 32 или 64 бита.
Сохранение адресации сегментными регистрами внутри пространства виртуальной памяти (как следствие — сильное удорожание управления виртуальными машинами, это уже имея перед глазами S/370, где этот вопрос был решён много лет тому назад).
Сохранение однобайтовых команд в 32-битном режиме там, где и 4 байта не повредило бы (IN/OUT, CMC, HLT, и прочие, которые не встретишь в выхлопе современного компилятора), и как следствие — необходимость длинных [E]VEX.
Неуправляемо блокирующийся и сериализующий XCHG. Неуправляемо жёсткий memory ordering.
Сохранение RCL, RCR на несколько бит при наличии SHLD, SHRD.
OF в старшем байте Flags, при наличии двух незанятых бит в младшем.
Дебильные флаги у BSF, BSR.
И прочая и прочая — я и 1/10 от проблем не перечислил.
Верю, что прежнее руководство Intel было технарями, но их компетентность закончилась в районе 1980 года. То есть сейчас всё идёт правильно: при таком грузе дебильных решений в прошлом и проблемах совместимости, при том, что альтернативные архитектуры и соответственно производители поджимают по всем фронтам — только маркетинг и способен придержать падение. (Я не смотрел текущий расклад и принимаю как предпосылку утверждение про направление смены руководства.)
Re: Сегодняшние лидеры Intel — не инженеры
Здравствуйте, Шахтер, Вы писали:
Ш>здесь
Ш>Что в России, что в Америке -- если лидеры компании не имеют экспертизы в предметной области, компания проиграет конкуренцию.
Можно подумать, период, когда руководство Intel имело техническую "экспертизу", оно рулило лучше
Единственное, на чём реально Intel выехал — это на обратной совместимости (дорогой ценой) и поддержке Windows, плюс агрессивный маркетинг и создание имиджа "nobody fired for bying Intel" (как IBM, но на ранг пониже).
Технические же дизайнерские решения ещё в лучшие времена были через один ужаснее другого:
Крупные проекты, заведомо понятные как провальные для тех, кто не имел неуправляемых амбиций:
Авантюра с i8089.
Бессмысленный 80286.
Авантюра с iAPX 432.
Pentium 4 (взлетел чисто на маркетинге, впоследствии выброшен целиком).
Авантюра с IA64, как следствие — принятие не менее кошмарного AMD64 в неизменном виде (AMD можно понять, у них ресурсы были катастрофически в обрез, но Intel?)
Или пройдёмся по архитектуре x86: просто открываю документацию и начинаю последовательно рассматривать:
Сверхнеудобный для парсера формат команд (суффиксы MOD-REG-R/M и SIB в конце), чудовищно усложняющий разбор потока команд. Не исправлен при переходе на 32 или 64 бита.
Сохранение адресации сегментными регистрами внутри пространства виртуальной памяти (как следствие — сильное удорожание управления виртуальными машинами, это уже имея перед глазами S/370, где этот вопрос был решён много лет тому назад).
AVX512, о котором вспоминали по ссылке... даже с 256 уже проблемы; идея с переменной длиной (максимум зависит от модели процессора, и может быть ограничен настройками) озвучена уже лет 20 назад, и ARM её успешно реализовал.
Сохранение однобайтовых команд в 32-битном режиме там, где и 4 байта не повредило бы (IN/OUT, CMC, HLT, и прочие, которые не встретишь в выхлопе современного компилятора), и как следствие — необходимость длинных [E]VEX.
Неуправляемо блокирующийся и сериализующий XCHG. Неуправляемо жёсткий memory ordering.
Сохранение RCL, RCR на несколько бит при наличии SHLD, SHRD.
OF в старшем байте Flags, при наличии двух незанятых бит в младшем.
Дебильные флаги у BSF, BSR.
И прочая и прочая — я и 1/10 от проблем не перечислил.
Верю, что прежнее руководство Intel было технарями, но их компетентность закончилась в районе 1980 года. То есть сейчас всё идёт правильно: при таком грузе дебильных решений в прошлом и проблемах совместимости, при том, что альтернативные архитектуры и соответственно производители поджимают по всем фронтам — только маркетинг и способен придержать падение. (Я не смотрел текущий расклад и принимаю как предпосылку утверждение про направление смены руководства.)
Ш>здесь
Ш>Что в России, что в Америке -- если лидеры компании не имеют экспертизы в предметной области, компания проиграет конкуренцию.
Можно подумать, период, когда руководство Intel имело техническую "экспертизу", оно рулило лучше
Единственное, на чём реально Intel выехал — это на обратной совместимости (дорогой ценой) и поддержке Windows, плюс агрессивный маркетинг и создание имиджа "nobody fired for bying Intel" (как IBM, но на ранг пониже).
Технические же дизайнерские решения ещё в лучшие времена были через один ужаснее другого:
Крупные проекты, заведомо понятные как провальные для тех, кто не имел неуправляемых амбиций:
Авантюра с i8089.
Бессмысленный 80286.
Авантюра с iAPX 432.
Pentium 4 (взлетел чисто на маркетинге, впоследствии выброшен целиком).
Авантюра с IA64, как следствие — принятие не менее кошмарного AMD64 в неизменном виде (AMD можно понять, у них ресурсы были катастрофически в обрез, но Intel?)
Или пройдёмся по архитектуре x86: просто открываю документацию и начинаю последовательно рассматривать:
Сверхнеудобный для парсера формат команд (суффиксы MOD-REG-R/M и SIB в конце), чудовищно усложняющий разбор потока команд. Не исправлен при переходе на 32 или 64 бита.
Сохранение адресации сегментными регистрами внутри пространства виртуальной памяти (как следствие — сильное удорожание управления виртуальными машинами, это уже имея перед глазами S/370, где этот вопрос был решён много лет тому назад).
AVX512, о котором вспоминали по ссылке... даже с 256 уже проблемы; идея с переменной длиной (максимум зависит от модели процессора, и может быть ограничен настройками) озвучена уже лет 20 назад, и ARM её успешно реализовал.
Сохранение однобайтовых команд в 32-битном режиме там, где и 4 байта не повредило бы (IN/OUT, CMC, HLT, и прочие, которые не встретишь в выхлопе современного компилятора), и как следствие — необходимость длинных [E]VEX.
Неуправляемо блокирующийся и сериализующий XCHG. Неуправляемо жёсткий memory ordering.
Сохранение RCL, RCR на несколько бит при наличии SHLD, SHRD.
OF в старшем байте Flags, при наличии двух незанятых бит в младшем.
Дебильные флаги у BSF, BSR.
И прочая и прочая — я и 1/10 от проблем не перечислил.
Верю, что прежнее руководство Intel было технарями, но их компетентность закончилась в районе 1980 года. То есть сейчас всё идёт правильно: при таком грузе дебильных решений в прошлом и проблемах совместимости, при том, что альтернативные архитектуры и соответственно производители поджимают по всем фронтам — только маркетинг и способен придержать падение. (Я не смотрел текущий расклад и принимаю как предпосылку утверждение про направление смены руководства.)