techwork: (Default)
[personal profile] techwork
Простой пример почему кодер высокого уровня как правило дерьмо.

Наткнулся я на статью странения реализации векторных вычислений Risk-V против ARM

Там аффтор такой везь из себя доказывает почему Risc-V лучше при этом приводя в пример что типа очень простые команды и можно поделить векторный регистр на два все одной командой.

Но этот конченный мудак который очень горд тем что наконец то Аллилуя блядь .... прочитал даташиты по асму и осознал себя от этого Гением которому не 4 а 8 тысяч долларов в месяц надо платить , это тупая драная сука не осознала той простой вещи - а как ты тупая блядь реализуешь это в Железе ??????

У Проекта Fugaku по мимо годов работы коллектива Кодамы кстати в том числе на идеях Неведомского и Краснова по сортировке, есть также то чем в Risc-V и не пахнет. А именно - выстраданная годами АППАРАТНАЯ !!! реализация которая кстати изначально делалась на SPARC архитектуре.

При этом вы постарайтесь найти реальные аппаратные сравнение SVE AVX NEON SSE реализаций SIMD обработки данных про Wavefront и nVidiвские 1024 битные векторные регистры и их обработку я вообще промолчу.

А нет ничего ибо софтячники срут на " личный бренд" всякого говна для лоха.

Опишу что знаю. Реализая Интел и нВиди очень похожи что говорит нам о чём ? О совместной работе.

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


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

Вообще рещение Фугаку уникально и красиво - чем длинее вектор и больше массив тем скорость вычисления в Z режиме больше. И я знаю по чему а кто не догадался ступает на хуй. Это уровнь вашей "компетенции" уроды .

почему я ещё давно говорил о том что Neoverse V1 это красиво а до того говорил что Фугаку это шедевр именно в части реализации векторных вычислений. Да кстати на самом деле SVE SVE2 можно использовать с самыми разными аритектурами.

И когда вектор 512 бит то да только на больших массивах с потоковой обработкой данных они могут почти сравнятся. Почти потому что там есть кое что что и даёт этот эффект многомерности регистра. А вот при длинном векторе 1024 или 2048 и тем более больших массивах данных SVE рвёт даже nVidia . WF же это простая реализация SIMD в лоб и там нет вообще ничего интересно - силикон рубит все довольны.

На самом деле конечно же можно реализовать видеокарту с очень низким потреблением как в новых чипах Apple за счёт использование SVE в качестве молотилки . Но долбоёбы холёные совтячники этого никогда не поймут - магия , техпроцесс - ну ну а если маркетолог нарисует 0нм то все законы физики вообще отменятся .... facepalm

Дело не в каких то супертехнологиях а в самом банальном включение в ядро эпловской видеокарты наработок от Fujitsu.

При этом SVE особенно с алгоритмом Хоу делает вообще не нужными все те костыли что городили все американские фирмы всё это время. AVX тупо устаревает при таком подходе.

А теперь смотрим на Risc-V - у этой не вьебенно молодой архитектуре где 48 команд как символов в Хирагане есть прям супер удобные инструции для вектрной обработки - проблема только в одном. Нет железа от Fujitsu. И Fujtsu свой Священный Грааль никому открывать не намерен - ARM они дали уже обработанные готовые IP которые и интегрировали в ядро Neoverse V1.

И с хуяли японцам делать такие подарки вcяким обмудкам с Risc-V ? Именно поэтому SiFive не смотря что они прям Risc-V (на самом деле перепиленные исходники проекта Warrior) они для европейского конкурса на европейский чип пошли и купил Neoverse V1.

А Китайцы вообще могут только как в ноябре фейкновости генерить, говноеды грантососы " импортозаместители" их перепечатывать с помпой о типа новых китайских видеокартах выдавая за такие A core купленные у Imagination которые даже близко не в серии. При том что уже есть C XT core. Которые от старых уже ( а какже каждый год устаренвание) Айфонов но что там с лицензией я тогда в ноябре и рассказал. Впрочем и A core это тоже ядро от айфона 5+ летней давности.

Хотя Хоу таки китаец - умный математик, давно за ним наблюдаю.

Поэтому да как де хорошо в теории реализуется векторная обработка на Risc-V - правда с примемлимой скоростью физически такой нет. Но оеа же есть дата shit е и вот такой погромист бежит делать личный бренд чтобы купаться в бабках, на науку ему насрать.И вот идёт потом грант на Risc-V что то делание когда даже нет железа на каком его изгостовиться а ну да " это же мировая практика" только как вот это согласуетсяс " импортозамещение" когда хуячаться деньги государства то есть нас с вами, а не как в " мировой практике" исключительно на свои или DA . Нет сука он жрёт наши деньги, мои деньги и что то там пиздит про "мировую практику". И по итогу что мы получаем - Импортозамещёный Хуй. А он с баблом валит через Турцию в ЕС или под пальму - сдохните лузеры .

Date: 2022-04-07 05:44 am (UTC)
From: [identity profile] paskin.livejournal.com
Не кури это больше.

Date: 2022-04-07 06:02 am (UTC)
From: [identity profile] techwork.livejournal.com
Не кури что ? когда нет хардовой имплементации и её очень долго разрабатывать но есть в даташите команда по твоему это то что гораздо лучше чем достать уже готовую железную имплементацию ?

Date: 2022-04-07 07:14 am (UTC)
From: [identity profile] paskin.livejournal.com
Вещества всякие. А то ваш "поток сознания" очень трудно читать...

Date: 2022-04-07 07:31 am (UTC)
From: [identity profile] techwork.livejournal.com
Тому кто понимает о чем я говорю прочесть очень легко.

а тебе задачка чем работа со скалярным вектором отличается от работы с векторным регистром ?

Date: 2022-04-07 07:36 am (UTC)
From: [identity profile] paskin.livejournal.com
Тем, что в векторном регистре операция выполняется параллельно над всеми членами вектора (сколько длины регистра хватит)

Date: 2022-04-07 07:43 am (UTC)
From: [identity profile] techwork.livejournal.com
А физически ?

Date: 2022-04-07 07:47 am (UTC)
From: [identity profile] paskin.livejournal.com
Что физически? Один декодер операций и N вычислителей.

Date: 2022-04-07 07:50 am (UTC)
From: [identity profile] techwork.livejournal.com
не логически а физически

Date: 2022-04-07 10:27 am (UTC)
From: [identity profile] techwork.livejournal.com
Вот видишь ты такой же хоть и строил из себя железячника . А принципов реализации хотя на уровне VHDL не знаешь , не говоря на уровне триггеров .

Ты говоришь словами того кто С++ то есть высокий и не имеет понятия о том как именно реализуются в железе его обьекты. Это конечно не на уровне тех мудаков что считают что вызов в закрытую библиотеку это " открытый код" даже не понимая что обработка производится в контейнере по неизвестному ему алгоритму и сложному, а не в самой команде на Java. Но тоже весьма не далеко от плинтуса. Так что Рашке Пиздец. Или как говорит Гуня на похоронах Жирика — Аминь.

А между тем реализовать обработку вектора в железе это вовсе не тривиальная задача и многоэтапная. И если просто реализовать виртуальный вектор программно даже на суперскаляре это выйдет лютый тормоз . Даже если ты будешь видеть это в компиляторе как векторный регистр.

Что у Risk-V и происходит. Это по мимо того почему RiscV пишут свои параметры в Coremark который ничего не показывает — потому что длина слова у него такаже как у ARM и MIPS ибо ничего лучше работы Юрия они так никто и не сделал. А DMIPS 1,7-2 на свободных реализациях и 2,8-3,3 на проприетарных. Это при том что у Юрия 3,5 вышло а такой RISKV только у SiFive и есть — просто потому что это и есть переименованый P5600. У которого просто переименовали ASM команды и имена регистров.

А вот реализация в железе правильного векторного регистра да ещё и переменного по длинне..... Эта задача которую ты точно не решишь и в РФ никто не решит. Ведь это не просто область хранения данных .
А так совершенно любой камень может использовать его иммитацию или просто реализацию абы как — что падение скорости радикально.

Date: 2022-04-07 10:52 am (UTC)
From: [identity profile] paskin.livejournal.com
Я не "железячник" и VHDL — совсем не моя стихия. И не в России, кстати.

Date: 2022-04-07 07:57 pm (UTC)
From: [identity profile] viktor ural (from livejournal.com)
Специалист должен знать и железо, хотя бы базовые принципы. Железо внутри процессора работает быстрее чем микропрограмма внутри процессора. Как пишет Эндрю Таненбаум(хе-хе, где-то читал что у него есть славянские корни от пра-пра дедушки) спец обязан знать историю развития архитектур, потому что то что сейчас устарело — завтра, в будущем может быть востребованным и пригодится. Ездил я как-то лет 15 назад в районный центр Успенское, Краснодарский край, недалеко от меня, к Крису Касперски. Обычный одноэтажный домик из белого силикатного кирпича, постройки середины 80-х, старые деревья — орехи растут перед домом. Но не застал его, свалил он в штаты ещё тогда.

Date: 2022-04-07 08:27 pm (UTC)
From: [identity profile] paskin.livejournal.com
Вы что сказать-то хотели? Я с разными процессорами и архитектурами работаю уже 35 лет — от 580ВМ80 до NVIDIA Ampere. Включая зачем-то помянутый автором SPARC — который на закате Sun проигрывал Интелу в разы по производительности, несмотря на гораздо более совершенную. по сравнению с тогдашним Линуксом ОС Солярис.
Edited Date: 2022-04-07 08:33 pm (UTC)

Date: 2022-04-08 01:26 am (UTC)
From: [identity profile] techwork.livejournal.com
Если ты не понял что именно я написал это говорит лишь о твоём уровне знаний.

И кстати про солярис ты говоришь чушь. Да и аппаратных особенностей SPARC ты не знаешь. А я ломом тоже махал но это не важно.

SPARC это Risk архетектура её DMIPS это примерно 1,2 DMIPS от ARM .

Конечно SPARC имел 2 DMIPS армовских в V8 реализации. Плюс делали камешки по устаревшим техпроцессам. Естетественно это гораздо меньше чем 1,4 DMIPS С7 и тем более 3,5 DMIPS P-3 потому что там это CISC DMIPS что на общих задачах где то 4 к 1.

Сейчас SPARC V9 это 3,23 что в ARM будет примерно 3,5 как и в Warior MIPS а это уровень малых ядер.


При этом справочно Nehalem это 7,5 DMIPS CISC и с тех пор улучшений особо алгоритмических не было.

Всякие Atom это 2,2 DMIPS

Но суть состоит в том что SPARC я упомянул по другой причине.

А ядра SPARC проигрывали в работе только с появлением Klamath — что было реально прорывом и проигрывало потому что ядро SPARC V8 это 0,5 ядро третьего пенька это 3,5 а по TDP 1 ядру P3 были эквиваленты 6 ядер SPARC то есть 0,5*6=3 НО тогдашние компиляторы и ОС плохо работали с многоядерностью.

И как раз провал SPARC V8 был вызван тем что Солярис парашная ОС. И работала она не лучше 2 версии ядра Linux а гораздо хуже, стоила дороже бесплатного линукса, и работала только с камнями SPARC в отличии от мульитплатформенного Linux с мультиплатформенными компиляторами.

Но даже Linux работал гораздо хуже чем Windows 98Se и WS 2000. Я лично снимал метрики и проверял тогда их надёжность — Линукс оказался полным говном по сранению с ними как и все юниксовые поделия. Не программ нормальных как на пользователе так и на сервере. Не надёжности .
В телекомуникационное оборудование начал ставить линукс только потому что бесплатно и POSIX и компиляторы мультиплатформенные. А MIPS тогда могли 2 DMIPS . RTOS системы же стоили все денег и с компиляторами было плохо.

Но Винда сравнилась с линуксом по отжору только на Vista а до того была лучше гораздо.

В 7 исправили немного отжор. а с 8 отжор стал таким что линукс стал вполне кошерным. Единственное за что держиться винда с 8 версии это корпорот взятки, наследованное ПО и геймеры.

Но по безопасности сейчас и винда и линукс говно. По производительности говно. А Солярис таким говном был уже тогда.

И проиграла эта платформа не потому что была радикально хуже — до P3 она была лучше.

Но с P3 98se serv2000 конурировать они уже не смогли потому что единое пользовательское пространство, стандартизация и большая серия.
А во временя UltraSPARC OS 2.5 1995-2000 SPARC был лучше всех в серверном сегменте.

Date: 2022-04-08 12:56 am (UTC)
From: [identity profile] techwork.livejournal.com
Да должен но твой собеседник и так не плохо зарабатывает на работы на языках высокого уровня, и поэтому ему похуй. Потому что пока пузырь с 2001 года дуют это можно. Потому что есть бюджеты на любое говно. Но этому подходит конец. Длинные волны кондратьева и всё такое.

Но опять таки на несколько лет ему хватит.

Date: 2022-04-08 04:54 am (UTC)
From: [identity profile] paskin.livejournal.com
Ха-ха. Уже для микроконтроллеров пишут на MicroPython — потому что час программиста на порядок дешевле процессора. А Nvidia на CUDA Fortran портировала — на нем писать матричные вычисления гораздо удобнее чем на С/С++ и работают они тоже быстрее (за счет того, что компилятор понимает что перед ним многомерный массив, а не какой-то список указателей на указатели).

Date: 2022-04-08 05:49 am (UTC)
From: [identity profile] techwork.livejournal.com
час програмиста дороже процессора. Но это не на долго.

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

Date: 2022-04-08 11:25 am (UTC)
From: [identity profile] paskin.livejournal.com
Вы просто нахватались всяких умных слов и вставляете их к месту и не к месту.
Многомерные массивы "прибиты гвоздями" к С и представляются как массив указателей, о котором компилятор ничего не знает. А в Фортране — это "родной" тип данных, включающий соответствующие математические операции (например, сложение или перемножение массивов) — идеально транслирующиеся в CUDA без всяких аннотаций и прочих "костылей" в коде.

Date: 2022-04-08 05:19 pm (UTC)
From: [identity profile] paskin.livejournal.com
Я же не сказал что на С/С++ нельзя писать код под GPU или другие векторные процессоры. Но языки, в которых матрицы являются действительно таковыми — предоставляют компилятору гораздо больше информации для оптимизации и требуют гораздо меньше "костылей" в коде.

Date: 2022-04-09 12:16 am (UTC)
From: [identity profile] techwork.livejournal.com
нет никаких костылей — ты просто не знаешь как это делать вот и всё. И своё не знаение более близких к металлу языков ты оправдываешь бредом в расччёте на то что собеседник тоже ничего не знает .

Date: 2022-04-09 04:41 am (UTC)
From: [identity profile] paskin.livejournal.com
А вы ничего и не знаете. Языки высокого уровня придумали для того чтобы не надо было обьяснять компьютеру каждый шаг. Поэтому в Гугле и придумали TensorFlow, а в Nvidia — TensorRT, потому что на "близких к металлу языках" они бы задолбались писать алгоритмы, да и работало бы это гораздо медленнее.

Date: 2022-04-09 05:19 am (UTC)
From: [identity profile] techwork.livejournal.com
Я то как раз в отличии от тебя как раз таки знаю. Как раз таки то что писалось CtM и работало и работает на порядки быстрее того говнокода который вырабает обьектная модель программирования.

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

Просто с ростом сложности программ требовалось всё больше программистов и времени на разработку — чтобы существенно сэкономить затраты и была придумана ООП . Точнее там было так .

Сначала сварганили ЛИСП — в рамках проекта распознавания естественного языка и ИИ. То есть идея написания программы как описания обьекта на обычном языке. Однако естественно в 1960е компьютеры это не могли

Потом Алан Кай в 1967 начал на основе провала лисп делать Симула — но симула вышла откровенным адски тормознутым говном. Попытка провал Лиспа и Алгол скрестить.

Идею выкинули на помойку и там она провалялась до 1981 когда компьютеры стали всё таки быстрее в разы , начался ИТ бум в Японии и программистов стало просто не хватать. И тогда появился С++ который был " скрежетом зубов" и из-за свое прожорливости стал популярен только когда началась эпоха 386 и 32 битного адресного пространства.

Я помню ещё времена когда Турбо-Паскаль уделывал C++

А вот в 1996 году начался dot com пузырь и вместе с ним эпоха Java потому что нужно было радикально повысить скорость разработки и сделать мультиплатформеность а в ходу уже были Пентиумы и SPARC V8 которые своими мощностями пернежёвывали накладные расходы на java хотя она тоормозила и засирала память мусором.

Задолбались бы только такие говнокодеры как ты которые " не программисты" как ты сказал. Которые даже не понимают о чем говорят но делают это с умным видом.

Если в государстве не стоит проблема сделать так чтобы сократить количество программистов на проекте до минимума — что прямое следствие капиталистической формулы " прибыль немедленно" то можно сделать программы которые вообще не потребуют никаких обновлений и могут работать десятками лет\ Проблема тут только в том что нужно долгосрочное государственное планирование а не " прибыль немедленно"

Код который сейчас пишут это говно. Ruby Phyton это вообще вредительские языки которые просто невозможно скомпилировать так чтобы они работали без адскогого выгрызания процесорного ресурса. Java за счёт долгого вылизывания стала приемлимлимым говном .

Ну и фреймфорки и постоянная линковка с библиотеками это вообще адский ПИЗДЕЦ. Почему браузер сейчас при той же пользовательской функиональности что и 15+ лет назад выжирает в 4-8 раз больше памяти и процессорного ресурса не давая за это совершенно ничего.

Почему игры имеют обьёмы исполняемого кода нет не просто моделек там понятно там сложность возрасла это да понятно — но это всё отработка видеокарты. Так вот сам код имеет такие обьёмы и процессорные потребности что просто пиздец. 18 летней давности суперкомп самый быстрый чтобы просто поиграть.

Сейчас код просто говно. и это не делает работу приложения на пользователи быстрее это нахуй кладёт любое железо. именно потому что используется модель разработки — как можно меньше писать . И если раньше человек получал миксер, то теперь он получает чудовище из многофункиональных модулей 95% функций которых не используется но грузит систему. И естественно всякое дерьмо типа питона это вообще превращает в пиздец.
Edited Date: 2022-04-09 05:20 am (UTC)

Date: 2022-04-08 05:50 am (UTC)
From: [identity profile] viktor ural (from livejournal.com)
Веселись, голубчик! Тебе осталось 2-3 года веселится. А дальше пограмисты будут НЕ НУЖНЫ. Другого ты ничего делать не умеешь....

Date: 2022-04-08 05:51 am (UTC)
From: [identity profile] techwork.livejournal.com
Чуток больше и дальше они будут нужны но не за те деньги к которым привыкли .

Date: 2022-04-08 10:55 am (UTC)
From: [identity profile] paskin.livejournal.com
Спасибо, вы меня насмешили. Во-первых — я не программист. Во-вторых — про "ненужность программистов" мне говорили 30 лет назад, с тех пор их с каждым годом нужно больше и больше.
Ради смеха — поделитесь своими галлюцинациями на тему кто/что заменит программистов... Или вы про Россию? Да — в России все будет печально.

Date: 2022-04-08 11:41 am (UTC)
From: [identity profile] techwork.livejournal.com
сначала ты говоришь так что типа я железячник — но потом говоришь я не железячник.
Потом ты начинаешь гнать про то что работал с тем и стем и вообще фортран прекрасен хотя это очевидная дичь даже для меня, не кодера которого не взяли на джуни потому что когда я выучил достаточно на эту позицию мне было уже больше 30 лет а HR считали тогда что это труп. А потом ты говоришь что ты не программист ...... ну и вишенка на торте то что ты нихуя не знаешь не про DeepMind про выпуск кодеров в Индии в этом году и про перспективы ИТ пузыря ..... Это сцуко ПРЭЛЭСТНО .

Date: 2022-04-08 05:08 pm (UTC)
From: [identity profile] paskin.livejournal.com
Вот видите — вас не взяли, а мне звонят и спрашивают, не хотел бы я поработать. И доходами от этого самого "ИТ-пузыря" я вполне доволен.

Date: 2022-04-09 12:05 am (UTC)
From: [identity profile] techwork.livejournal.com
Ну просто я знаю последствия такой работы HR
https://techwork.livejournal.com/1157954.html

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

Но и у этого последствия уже есть и будут глобально для многих.

Date: 2022-04-07 07:04 am (UTC)
From: [identity profile] elotar.livejournal.com
Ну там же есть "V" в названии! Не Z конечно, но тоже стоит выделения гос деньег!

Date: 2022-04-07 07:31 am (UTC)
From: [identity profile] techwork.livejournal.com
Z есть в режиме работы SVE у Neoverse V1

Date: 2022-04-07 09:53 am (UTC)
From: [identity profile] viktor ural (from livejournal.com)
Тут слишком мало комментаторов прочитавших и понявших 2 книги. "Архитектура компьютера" 'Современные операционные системы" Эндрю Таненбаум. Эх, давно я их читал, лет 15 назад.

Date: 2022-04-07 10:06 am (UTC)
From: [identity profile] techwork.livejournal.com
В РФ вообще таких людей мало . Но тут не о том тут а скорее о Харрисе и ASM — архитектура и проектирование

Date: 2022-04-07 12:50 pm (UTC)
From: [identity profile] ester rn (from livejournal.com)
Япония вернет себе бывший японский архипелаг Курилы, принадлежавший Советскому Союзу по окончании Второй мировой войны, пишет Kyodo News

Япония утверждает, что Советский Союз незаконно захватил четыре Курильских острова — Кунашир, Итуруп, Шикотан и острова Хабомаи — вскоре после капитуляции Японии во Второй мировой войне в августе 1945 года, в то время как Москва утверждает, что право собственности было передано России в качестве законного мирного соглашения.

Просочившиеся документы показывают, что Япония планирует предъявить России требования вернуть себе Курилы, которые теперь описываются как «незаконно оккупированные» во внутренних документах, с которыми ознакомился Kyodo News.

Российское вторжение в Украину обострило тон между Россией и Японией, и дипломатия между странами сейчас находится под сильным давлением.

«Мы не в том положении, чтобы вести беседу», — констатируют японцы в своих внутренних документах, имея в виду переговоры о статусе островов.Image
Edited Date: 2022-04-07 12:51 pm (UTC)

Date: 2022-04-07 11:20 pm (UTC)
From: [identity profile] techwork.livejournal.com
во первых владелец этого СМИ Тёрнер помнишь такого ?
Во вторых — РФ регулярно и хамски наезжает на Японию стараясь напасть на Японию — благодаря корейскому лобби в Кремле.
В третьих — КОТРА и британцы активно работают по антирусской пропаганде в Японии уже очень давно но это не работает так как им хотелось но совместные усилия кремля , высказывания кремлёвских о планируемом захвате Хоккайдо создаёт благоприятный фон для того чтобы такие заявления в бритсанских СМИ не взывали отторджения среди народа.


В целом же картина такова .

Япония имеет способы поставить РФ раком и без войны и будет это делать раз РФ напала на Японию своими действиями отвергнув тихий обход санкций предложеный Японией, и ведёт себя хамски в отношении Японии позволяя себе те выходки которые совершенно не приемлимы и оскорбительны. Да за этим стоят корейцы, но именно русские виноваты в том что терпят такое руководство. И отдали корейцам власть над собой.

Япония понимает что корейское лобби в кремле стремится легитимизировать пуск ядерных ракет РФ по Японии. И не будет предпринимать действий которые допустят это.

Но ещё раз раком поставить элитку в РФ Япония может и без войны. И корейцам нажиться на этом не даст.

Date: 2022-04-07 05:16 pm (UTC)
From: [identity profile] villipuh.livejournal.com
Это ж микроэлектроника, за нее в РФ денег не дают. Максимум — зачеты ставят, по курсовым мультиплексор на ттл-логике, бгг.

Date: 2022-04-07 11:21 pm (UTC)
From: [identity profile] techwork.livejournal.com
Поэтому смерть РФ это хорошо .

Date: 2022-04-08 04:45 am (UTC)
From: [identity profile] paskin.livejournal.com
Когда я работал со SPARC — V8 уже считался позавчерашним днем, Sun продвигали UA2005/2007 (T1/T2 соответственно). А Солярис безраздельно царил в телекоме — предоставляя возможности, которые Линуксу в то время только снились (вроде 40000 соединений к одной машине или отладку syscalls) и аптайм в годы. Но, к сожалению, 31-ядерные серверы Sun по производительности уступали 2х-ядерным десктопам на Линуксе, причем на тестах имитирующих их "родное" применение — массовое обслуживание, не требующее сложных вычислений.

Date: 2022-04-08 05:57 am (UTC)
From: [identity profile] techwork.livejournal.com
Что говорит о том что столкнулся ты с ними гораздо позднее чем я. И я обьяснил с избытком причины почему тогда они уже отживали свой век.

Но столнувшиь с ними ты ничего не знал Юнипере
Нет в 2005 году в телекомев парашке их покупали уже только ради откатов. 2005 это даже в телекоме MIPS а не SPARC . B HP лезвия на винде полюс циски и юниперы

Date: 2022-04-08 05:58 am (UTC)
From: [identity profile] viktor ural (from livejournal.com)
Юниксы не только солярисами и пингвинами известны. Весь мир на них клином не сошелся. А как же FreeBSD? Тут в комментариях не лыком шитые пишут. Гонял я ради интереса этот опенСолярис 10-15 лет назад, фряха на то время оказалась на порядок лучше.

Date: 2022-04-08 06:19 am (UTC)
From: [identity profile] techwork.livejournal.com
никсы вообще сами по себе с самого начала были грузанутей чем CP/M подобные системы. Они не на оптимизацию вычислительных ресурсов направлены а на работу с корпоративной сетью. А это всегда затратно.

В качестве клиентской системы они проигрывали винде до 8 винды однозначно.

В качестве серверной системы им альтернативы не было до 2000 года — только если сервер-контроллер на RTOS. Но с Win2000 они резко шлёпнулись везде и только старания майкрософт всё уговнить сделала из сервера 2012 тормознутое, не надёжное говно. в том числе и благодаря попытке включить в Сервер SuSeшный а точнее новеловский код и всеми этими ReFS которые как декларировалось никогда не работали.

Все виндовые сервера после 2008 R2 говно.

Все ОС после 7 говно.

И у линукса 5 ядро — говно галимое .

Profile

techwork: (Default)
techwork

August 2025

S M T W T F S
      1 2
3 4 5 6 7 8 9
10 11 12 13141516
17181920212223
24252627282930
31      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 13th, 2025 12:53 pm
Powered by Dreamwidth Studios