Comments 36
«Исполняемый» и «исполнительный» — разные вещи
UFO just landed and posted this here
Не принижая Linux и не восхваляя Windows, хочется уточнить.
Какой дистрибутив linux там используется? Эти суперкомпьютеры физически являются одним компьютером или кластером, где количество ядер в каждом отдельном компьютере «разумное»?
Какой дистрибутив linux там используется? Эти суперкомпьютеры физически являются одним компьютером или кластером, где количество ядер в каждом отдельном компьютере «разумное»?
Так дистрибутив же написан: в обоих примерах RHEL
По первому суперкомпьютеру инфа с вики следующая:
«4608 серверов IBM Power Systems AC922 <...>. В состав этих серверов входит 9216 22-ядерных процессоров IBM POWER9 и 27 648 графических процессоров NVIDIA Tesla V100[9].
<...>
Каждый узел содержит более 500 Гб когерентной памяти (High Bandwidth Memory и DDR4 SDRAM), которая адресуется всеми CPU и GPU, плюс 800 Гб энергонезависимой памяти, которая может использоваться как пакетный буфер или расширенная память. Процессоры и видеокарты подключаются с использованием шины NVLink. Это позволяет использовать гетерогенную вычислительную модель.»
А вот можно ли отнести это к компьютеру или к кластеру, не знаю
По первому суперкомпьютеру инфа с вики следующая:
«4608 серверов IBM Power Systems AC922 <...>. В состав этих серверов входит 9216 22-ядерных процессоров IBM POWER9 и 27 648 графических процессоров NVIDIA Tesla V100[9].
<...>
Каждый узел содержит более 500 Гб когерентной памяти (High Bandwidth Memory и DDR4 SDRAM), которая адресуется всеми CPU и GPU, плюс 800 Гб энергонезависимой памяти, которая может использоваться как пакетный буфер или расширенная память. Процессоры и видеокарты подключаются с использованием шины NVLink. Это позволяет использовать гетерогенную вычислительную модель.»
А вот можно ли отнести это к компьютеру или к кластеру, не знаю
Это всетаки много отдельных серверов, соедененных в целое быстрой шиной. Подозреваю, что использовать это целое как целое может только специально написанный софт. А приведенная на скриншоте система — хотя, конечно, физически это набор блэйдов на интерконнекте, но логически и с точки зрения ОС — это один сервер «кусочком» и использовать все ядра и память может любое win приложение. Подозреваю что и linux на него тоже можно поставить без заметных проблем, если конечно linux поддерживает 1700+ процессоров.
UFO just landed and posted this here
Раньше на эту тему еще была шутка: да, Linux поддерживает 4096 процессоров, но можно ли проигрывать YouTube в полноэкранном режиме?
В итоге стало можно, если перекомпилять ядро и добавить туда патчи от анестезиолога, то наконец-то можно будет смотреть YouTube
chromium-vaapi, стоковый CFS в ядре и Celeron с частотой 1.1ГГц (новый нетбук) — 1080p60 без лагов и тормозов.
Вините криворуких разрабов, которые постоянно ломают аппаратное ускорения в браузерах…
Вините криворуких разрабов, которые постоянно ломают аппаратное ускорения в браузерах…
Это шутка минимум десятилетней давности, еще когда видео на ютубе проигрывалось через флеш, а BFS только появился
xkcd.com/619
xkcd.com/619
Вот только в каждой шутке есть доля шутки, и эта — не исключение. Запустите 1080p60 (Именно 60! c 30 к/с проблемы как-бы нет) и пожалуйста, i7 2630qm уже изображает умирающего. Немного помогает переброс хрома на дискретку. Еще немного — отключение композитора.
А как подключаешь vaapi — волосы становятся гладкими и шелковистыми даже на задавленном целероне…
А как подключаешь vaapi — волосы становятся гладкими и шелковистыми даже на задавленном целероне…
Я на днях удалил Linux и проверить уже, увы, не смогу (
Но в последнее время проблем не было, хотя не знаю, процом видео декодилось или дискреткой. У меня настольный комп всегда был с дискретной нвидией и проприетарным драйвером
Но в последнее время проблем не было, хотя не знаю, процом видео декодилось или дискреткой. У меня настольный комп всегда был с дискретной нвидией и проприетарным драйвером
i3 7100, встроенное видео, Kubuntu 18, Firefox 63, монитор 4k. Видео 1080р60 в utube проигрывается плавно, нагрузка на процессор ~40%. 1440p60 на том же видео — тоже все плавно, загрузка процессора выше, порядка ~80%. А вот 2160p60 уже не тащит.
Считать суперкомпьютер за один компьютер на уровне ОС не вполне честно. Там и RHEL заметно допилен и память неоднородна от слова "совсем", и FS совсем свои. А 32-сокетный монстр — это еще "почти честный" моносервер (Intel: Configure native 4- and 8-socket CPU configurations and extend to up to 32-socket systems via third-party OEM node controllers).
UFO just landed and posted this here
По первой ссылке как раз написано про 32-сокетный сервер и такие есть у Хуавея.
UFO just landed and posted this here
После прочтение возникли сумбурные мысли.
1. Ядру Linux всегда ставили в недостаток майнфреймовое происхождение. А судя из статьи, планировщик Windows начал на каком-то этапе ориентироваться (где-то явно или не явно) на реализации планировщиков в Linux.
2. Учитывая наращивание количества ядер в новых процессорах даже для десктопов, мне вопрос балансировки и распределения нагрузки на ядра не кажется таким уж далеким от обычного пользователя.
1. Ядру Linux всегда ставили в недостаток майнфреймовое происхождение. А судя из статьи, планировщик Windows начал на каком-то этапе ориентироваться (где-то явно или не явно) на реализации планировщиков в Linux.
2. Учитывая наращивание количества ядер в новых процессорах даже для десктопов, мне вопрос балансировки и распределения нагрузки на ядра не кажется таким уж далеким от обычного пользователя.
линукс — абсолютный лидер во всех топ-ах (TOP100,TOP500). и как-то я такую картину наблюдаю все время, сколько смотрю на нее (лет 15 точно).
хотя и виндовс там был на задворках. интенсивно продвигаемый майкрософтом. впрочем, позже они о нем забыли и сейчас там его нет совсем...
ой, пардон. чушь написал. не правильно понял…
Ядру Linux всегда ставили в недостаток майнфреймовое происхождение.
Что? История происхождения ядра Linux, изложенная самим создателем в книге «Just for fun» говорит о том, что происхождение этого ядра ну очень «писишное» — писалось под 386 процессор, причем сам Линус говорил о том, что сомневается, что оно будет работать где-то ещё. Время решило иначе, но факт остается фактом
Ну, давайте поспорим сами с собой. Или с тем, что мы говорили ранее. Сейчас очень интересно забывать историю, или хотя бы говорить, что это было не так. Как минимум стоит вспомнить: «habr.com/post/62811»
1. Это скорее всего не проблема, так как под сервер и под десктоп, я думаю, планировщик можно сконфигурировать перед компиляцией ядра. А вот Winda корнем целилась в десктоп, поэтому и терминальные сессии особо не учитывали при архитектуре планировщика, потом одумались.
А когда планируется оптимизировать работу с Тредриппером, у которого несимметричная шина памяти?
На сегодня она поддерживает архитектуры x86, x64,
На сегодня уже часть x86 архитектур не поддерживаются.
Наборы API – это механизм, позволяющий ОС разъединять DLL и место их применения. К примеру, набор API позволяет приложениям для win32 продолжать пользоваться kernel32.dll, притом, что реализация всех API прописана в другой DLL
Это не механизм разъединения, это лютый геморой который они будут еще долго разгребать. Все эти ms-core-… просто указатели на другие библиотеки им даже запрещено запускаться. Нафига надо было так делать манифестом и базой данных это было не решить. Понадобилось родить эту жуть. А потом в составе больших продуктов необходимо поставить vcredist всех версий иначе не работает. При этом для удобста на сайте микрософта эти библиотеки имеют одинаковые имена vcredist.
Например FreeLibrary находиться в kernel32.dll он будет ссылаться на api-ms-win-core-libraryloader-l1-1-1.dll или api-ms-win-core-libraryloader-l1-2-0.dll или еще куда. Но в итоге всё равно попадёт в kernel32 так загрузчику глубоко фиолетово. Но без файла api-ms-win-core-libraryloader-*.dll не запуститься. Что мешало просто запись в реестре сделать, зачем еще эту гору файлов таскать? Что быстрее загрузить 1 файл и сотню отдельных? Да и в старых виндах гарантировано не запустится. Так что все эти api-set больше похожы один из механизмов запланированного устаревания софта.
Не вопрос, исходники публикуете в опенсорс, мы читаем и восхищаемся, вносим свои баги, а Билл нас за это поносит. А без статья просто демонстрация неприкрытого хвастовства, рассчитанная точно не на специалистов, а скорее на продавцов и любителей потратить чужие деньги.
Признаться, статья в контексте других действительно легкопортируемых операционных систем звучит скучно.
Да и код закрыт, что миру с того, что кто-то где-то чем-то хвастается?
> ls ~/var/linux/arch/
alpha/ arm/ blackfin/ cris/ h8300/ ia64/ m32r/ metag/ mips/ nios2/ parisc/ riscv/ score/ sparc/ um/ x86/
arc/ arm64/ c6x/
Да и код закрыт, что миру с того, что кто-то где-то чем-то хвастается?
Очень интересная и познавательная статья. Но как это часто бывает с майками, они теоритическую масштабируемость плохо накладывают на практическую из-за больших разбежек по возможным сценариям работы, поэтому усредняют до одной математической модели сценарии работы на 2х ядрах с HT и на 8ми ядрах с HT. Не сочтите за хвастовство, просто хотел бы поделиться, что это не пустые слова — мы учли такие моменты при разработке своего софта ещё в 2014ом году и поэтому в отличии от игрового режима Microsoft, наш игровой режим не уменьшает производительность у пользователей независимо от конфига. Кому интересно, может ознакомится подробнее здесь
Sign up to leave a comment.
Единое ядро Windows