Здравствуйте, Sharov, Вы писали:
C>>Да и в любом случае, нынче виртуалки уже давно вышли из моды. Текущий state-of-the-art — это stateless-системы, описываемые кодом, которые могут пересоздаваться с нуля по требованию. S>Речь о докере?
Обычно о нём, хотя и необязательно. Ещё есть vagrant, puppet, chef, ...
Здравствуйте, Sharov, Вы писали:
C>>Инстансы типа t1/t2/t3 на Амазоне прозрачно мигрируют между аппаратными узлами. Причём во время работы. C>>Обычно миграция между гипервизорами - редкое событие, к которому готовятся заранее и делают аккуратно. S>Я в виртуализации не силен, а это не одно и тоже? В чем разница?
Я имел в виду миграцию между разными типами гипервизоров. Например, между VMWave и XEN.
Здравствуйте, Lexey, Вы писали:
L>Проблема в том, что эти продвинутые процессоры мало кому были нужны. Их пытались пихать в различные НИИ и т.п. под гранты. В итоге они там стояли и делали то (роль почтовых и веб серваков выполняли, например), с чем спокойно справлялись более бюджетные сервера на x86. При этом вторые еще и администрировать было гораздо проще и приятнее из-за наличия нормального софта (с которым у Sun'а все было плохо). В тех реалиях какое-то адекватное применение у этих процессоров могло быть только в высокопроизводительных вычислительных кластерах или кластерах СУБД (в ГЦИ ЦБ Оракл на таком гоняли). Но это очень узкая ниша.
Потому что это аппликейшн сервер, числодробилка обыкновенная. Либо процессинг с лирингом обсчитывать должен в кластере, либо исполнять серверная часть CAD/CAE/CAM-системы. Работают с которой через клиентское приложение или же проброс GUI по X-ам с обычных компов.
L>На x86 в те времена работали практически все рабочие станции и большая часть серваков в конторах самого разного масштаба. И хорошо работали.
Десктопы. Под рабочими станциями в то время понимались вполне конкретные машины, имевшие мало общего с IBM PC.
Были они на процессорах семейства MIPS R10000 или же Motorola 68K, изрядно уделывая по производительности любой IBM PC. За счёт чего и могли вращать на себе мало-мальски приличные ОС (производные от юниксов) и различные САПР-пакеты, со всяким разным моделированием через CAE-, CAM-системы, сродни Siemens NX или же CATIA v4.
Именно в дополнение к таким рабочим местам и нужны были аппликейшн сервера на целочисленных числодробилках UltraSPARC.
Здравствуйте, a7d3, Вы писали:
L>>Проблема в том, что эти продвинутые процессоры мало кому были нужны. Их пытались пихать в различные НИИ и т.п. под гранты. В итоге они там стояли и делали то (роль почтовых и веб серваков выполняли, например), с чем спокойно справлялись более бюджетные сервера на x86. При этом вторые еще и администрировать было гораздо проще и приятнее из-за наличия нормального софта (с которым у Sun'а все было плохо). В тех реалиях какое-то адекватное применение у этих процессоров могло быть только в высокопроизводительных вычислительных кластерах или кластерах СУБД (в ГЦИ ЦБ Оракл на таком гоняли). Но это очень узкая ниша.
A>Потому что это аппликейшн сервер, числодробилка обыкновенная. Либо процессинг с лирингом обсчитывать должен в кластере, либо исполнять серверная часть CAD/CAE/CAM-системы. Работают с которой через клиентское приложение или же проброс GUI по X-ам с обычных компов.
И? Это возражение или согласие?
L>>На x86 в те времена работали практически все рабочие станции и большая часть серваков в конторах самого разного масштаба. И хорошо работали.
A>Десктопы. Под рабочими станциями в то время понимались вполне конкретные машины, имевшие мало общего с IBM PC.
Да пофигу, как их называть. Я имел в виду то, на чем люди работали. И это были именно x86, в основном. И работали они, как правило, под Виндой. А "Cантехника" плохо вписывалась в виндовую экосистему, стоила дофига и задач, которыми ее можно было бы реально нагрузить, почти не было.
Здравствуйте, Cyberax, Вы писали:
L>>JetBrains что-то пробивное сделали для плюсов? C>Полный разбор кода, включая шаблоны. Соответственно, надёжная нафигация по коду и рефакторинг.
А это нереально сложно, что никто до этого не сделал? Вроде языку более 30 лет, а нормальных ide -- по пальцам.
Здравствуйте, Sharov, Вы писали:
S>А это нереально сложно, что никто до этого не сделал? Вроде языку более 30 лет, а нормальных ide -- по пальцам.
Это сложно, считай что полноценный фронт-энд от компилятора нужен. В QtCreator был свой и очень щустрый, но перешли на clang т.к. поддерживать свой при развитии плюсов довольно тяжко.
C>Программирование настолько шагнуло вперёд, и в основном благодаря инструментам и пониманию процессов разработки. LVV>>Нынешние объемы едвали не более, чем наполовину генерятся, а не пишутся. C>Нет.
Ну, пример приведи, что сейчас считается более крутым, чем бортовая система космического корабля.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
C>>Программирование настолько шагнуло вперёд, и в основном благодаря инструментам и пониманию процессов разработки. LVV>>>Нынешние объемы едвали не более, чем наполовину генерятся, а не пишутся. C>>Нет. LVV>Ну, пример приведи, что сейчас считается более крутым, чем бортовая система космического корабля.
Ну вот опять про космические корабли началось...
В Шаттле объём исходного кода — около 400 тысяч строк. Это сейчас уровень небольшого проекта. В Windows — около 50 миллионов строк кода.
А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода.
И вот умение управлять развитием таких систем — это как раз достижение 90-х и 2000-х.
C>В Шаттле объём исходного кода — около 400 тысяч строк. Это сейчас уровень небольшого проекта. В Windows — около 50 миллионов строк кода.
Система управления маленькая, но СЛОЖНАЯ.
А винда не показатель. За 35 лет накопилось. Из которых сколько ненужных? C>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода. C>И вот умение управлять развитием таких систем — это как раз достижение 90-х и 2000-х.
Ну, про 90-е ты загнул, тогда только интернет появился.
И, наверное, можно как-то обозначить класс таких систем.
Распределенные?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
C>>В Шаттле объём исходного кода — около 400 тысяч строк. Это сейчас уровень небольшого проекта. В Windows — около 50 миллионов строк кода. LVV>Система управления маленькая, но СЛОЖНАЯ. LVV>А винда не показатель. За 35 лет накопилось. Из которых сколько ненужных?
Я слышал, что объём кода в драйверах Радеонов уже много лет как превышает объём кода в самой Windows. Драйверы — это тоже не так-то просто.
Здравствуйте, Cyberax, Вы писали:
C>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода.
2 миллиарда строк говнокода. Наверное так точнее Как в ДНК куча накопленного легаси, никто уже не помнит что это, зачем это, когда появилось, но трогать нельзя.
C>И вот умение управлять развитием таких систем — это как раз достижение 90-х и 2000-х.
Управлять развитием говнокода это безусловно достижение, особенно добиться при этом, чтобы целевой продукт не падал, не лагал и в полном объеме реализовывал свой функционал.
N>Я слышал, что объём кода в драйверах Радеонов уже много лет как превышает объём кода в самой Windows. Драйверы — это тоже не так-то просто.
Ну, винду на радеонах не пользую.
Сейчас пишу с компа Rizen 5 + Vega 8 c осью Альт Образование.
Но вообще излишняя универсализация (которая в умах программеров сидит изначально) — это не есть хорошо.
К такому выводу пришел в результате 50-летнего опыта в ИТ.
Вот МАЛЕНЬКИЙ пример.
С относительно времени пользую для юнит-тестирование C++ посредством Catch / doctest.
И все время свербит мысль: надо вычистить оттуда все компилеры, которыми не пользуюсь.
На винде оставить версию для gcc + версию для студийного компилера
А на Альте — только gcc.
И кода меньше будет, и работать шустрее станет.
Во многих случаях код разбухает по одной из двух причин:
— либо излишняя универсальность
— либо сделано в неподходящей технологии, но хорошо известной на данном этапе программерам.
Возвращаясь к вопросу об объеме кода в радеонах.
Оно же в виндовс.
Вот до эры персоналок и винды существовало такое понятие как "генерация ос" под конкретную аппаратуру.
Требовало серьезной квалификации. Ибо чел должен был присвоить множеству параметров совершенно конкретные значения.
Сейчас это все автоматизировано?
Что-то мне подсказывает, что нет.
Ядро линя включает все возможные драйверы?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Cyberax"
C>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода. C>И вот умение управлять развитием таких систем — это как раз достижение 90-х и 2000-х.
Это речь об agile или о чем? Я про управлять, а не писать.
Здравствуйте, Nuzhny, Вы писали:
N>Я слышал, что объём кода в драйверах Радеонов уже много лет как превышает объём кода в самой Windows. Драйверы — это тоже не так-то просто.
Здравствуйте, Sharov, Вы писали:
N>>Я слышал, что объём кода в драйверах Радеонов уже много лет как превышает объём кода в самой Windows. Драйверы — это тоже не так-то просто. S>А можно ссылку, а то что-то совсем не верится.
Я эту историю слышал от сотрудников АМД, типа сравнивали с объёмами Windows 2000 или XP. Как-то не сильно гуглится насколько это может быть правдой, хотя исходники Windows в сеть и утекали, но не нагуглил сходу их объёмы.
Чисто АМД драйвер в исходниках Линукса занимает более 2 млн строк, но это самая выжимка. Нет ещё закрытой части, которая есть в Windows, не кучи системных утилит и т.д. Так что как сейчас обстоят дела я не в курсе.
Здравствуйте, Nuzhny, Вы писали:
N>Я эту историю слышал от сотрудников АМД, типа сравнивали с объёмами Windows 2000 или XP. Как-то не сильно гуглится насколько это может быть правдой, хотя исходники Windows в сеть и утекали, но не нагуглил сходу их объёмы.
Чет. не верится -- драйвера это относительно простые штуки, которые с железом взаимодействуют. С др. стороны все зависит от железа,
гпу явно не простая железяка, но чего там делать на млн. строк промежуточного кода? Запихнул данные, получил результат...
N>Чисто АМД драйвер в исходниках Линукса занимает более 2 млн строк, но это самая выжимка. Нет ещё закрытой части, которая есть в Windows, не кучи системных утилит и т.д. Так что как сейчас обстоят дела я не в курсе.
А можно ссылку на гитхаб на драйвер? Глянуть хотя бы в общих чертах.
Здравствуйте, Sharov, Вы писали:
S>А можно ссылку на гитхаб на драйвер? Глянуть хотя бы в общих чертах.
Про миллионы строк. Что-то здесь, тут для Vulkan. Все куски я наверняка не найду.
Но это точно не простая вешь: реализация работы с железом, вывода на монитор(ы), OpenGL, Vulkan, DirectX — вот всей этой кучи стандартов. Далее там отдельно идут всякие компиляторы шейдеров, компиляторы OpenCL, ещё чего-нибудь. Там есть обработка видео и изображений. А ещё очень много кода написано вокруг этого, чем пользуются сами разработчики.
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, пример приведи, что сейчас считается более крутым, чем бортовая система космического корабля.
Ну например, автопилот (даже "простой" адаптивный круизконтроль) любого современного автомобиля. Ответственность тут на многие порядки больше чем у ваших космических кораблей.
Здравствуйте, Lexey, Вы писали:
L>И? Это возражение или согласие?
L>Да пофигу, как их называть. Я имел в виду то, на чем люди работали. И это были именно x86, в основном. И работали они, как правило, под Виндой. А "Cантехника" плохо вписывалась в виндовую экосистему, стоила дофига и задач, которыми ее можно было бы реально нагрузить, почти не было.
Это вопрос позиционирования, где-то и штангенциркулями гайки отворачивали, а микроскопами друг друга по головам стучали.
Оснащение рабочих мест компьютерами всегда делается исходя из нескольких соображений. Тому же инженеру-конструктору нужна была нормальная рабочая станция для работы с CAx-пакетами (CAD/CAE/CAM). Варианты чего-то приличного на x86-процессорах стали появляться лишь начиная с 1996-1997 годов. И это была новая веха, потому как ранее IBM PC не тянули даже серьёзных ОС и не годились на роль десктопа сопоставимого с рабочей станцией.
Если же имелись аппликейшен сервера приличные, на тех же UltraSPARC, то рабочие места инженеров можно было оснастить уже и IBM PC, для использования, по большей части, в роли терминалов — пробросив на эти десктопы через «иксы» тот софт, что выполняется реально на сервере.
Ни сколько не удивительно, что где так и сделали — серваки приличные поставили, а рабочие места сделали на базе x86-десктопов, но использовалось это всё через задницу. Именно потому что кому-то захотелось винду держать, а потребности в CAE/CAD/CAM реально не было. Поскольку компьютерная грамотность была почти нулевая и никто их толком не освоил.
Графический драйвер AMDGPU ... В Linux 5.9 он включает 2,16 млн строк кода... кодовая база драйверов AMDGPU настолько велика из-за автоматически генерируемых заголовочных файлов для регистров GPU и т. д. На самом деле 1,79 млн строк драйвера AMDGPU в Linux 5.9 — это просто заголовочные файлы, которые преимущественно генерируются автоматически.
