Но вроде-бы это и так понятно из контекста производимых действий и начала текста.
Тогда Вы не поняли вопрос. Переформулирую - какой в этом смысл?
Изменение частоты имело бы смысл, если бы у Эльбрусов была бы перспектива достичь 3 ГГц вот прям в ближайшем будущем без микроархитектурных изменений. Такой перспективы нет, значит занижение частоты не имеет смысл, так как, как ни странно, микроархитектура на нее влияет напрямую.
То есть уже один момент где сравнение заведомо некорректно.
Собственно, я же уже отвечал "этот бенчмарк - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42". Проще говоря, такой размер сортируемого массива просто подходит (вроде-бы очевидно?) для сравнения скорости сортировок между собой и просто остался в исходниках с его предыдущего использования.
Прочитайте, пожалуйста, мой вопрос повнимательнее. К сожалению для качественного сравнения "потому что 42" не является достаточным ответом.
Я напомню - я пытаюсь понять какую конкретно часть аппаратуры вы тестируете (чтобы понимать ожидаемое). Потому что пока что ваш пример очевидно может показать проблемы с оптимизацией кода на стороне компилятора (тут то что нужно делать изменение чтоб получить +10% - показательно, но нет объяснений почему тот же самый код что на Эльбрусах не был проверен на интеле). Почему это важно? Потому что Вы привели тест в рамках рассуждений о микроархитектурной скорости, значит нужно обоснование что тест является показательным и будет показывать сильные и/или слабые стороны архитектуры.
С подходом, отрицающим объяснения и попыток докопаться до сути тест не имеет никакого теоретического или практического смысла. Почему? Представим себе гипотетическую ситуацию что вы тестируете по факту скорость работы кэша (комбинированно throughput + latency), в таком случаи у вас практически любая железка, включая простой in-order risc-v или arm (кстати тоже было бы неплохо проверить Ваш тест) будет давать крайне схожие результаты, если компилятор конечно делает хоть какие-то оптимизации, на базе этого строить какие либо выводы будет невозможно.
Еще у вас были упоминания про управление частотой в тестах на энерго-эффективность - но я сравнивал/оценивал другое.
Я не говорил что вы сравниваете что-то в таком духе, я это использовал только в рамках указания другому человеку что есть другие способы получить разумные и даже повторяемые результаты без отключения энергосбережения.
Но такое сравнение было бы интересно, потому что, как ни странно, электричество это важная статья расходов какого-нибудь ЦОДа и если у тебя есть железка которая выдает X попугаев потребляя Y Ватт, и другая железка, выдающая X*2 попугаев потребляя те же Y Ватт, это очень весомый довод в пользу железки №2 даже если она стоит вдвое дороже (на горизонте типичной эксплуатации железа, затраты на электроэнергию выйдут на первое место, помноженное на десятки тысяч серверов это составит уже нехилую такую сумму). Но корректное тестирование железа в таком режиме уже не так просто реализовать (нужно как минимум уметь понимать свое энергопотребление, а по хорошему вообще отдать это на откуп внешнего устройства, которое на выходе даст лог за время проведения теста). И такое я вполне требую от людей из МЦСТ, как от компании (и требовал бы от тестовых лабораторий и прочих журналистов, в это влезших), но Вы вроде бы в категорию "человек из МЦСТ" не попадаете?
Упоминание про "прогрев" и отбрасывание первых итераций - тоже не релевантно, так как при фиксированной частоте и замере по wall clock первая итерация растворяется в 1000 повторений.
Оно также имело смысл для другого человека в первую очередь. Но для Вас оно имеет тот смысл, что во время первых нескольких итераций частота ядра успеет подняться до стабильного уровня и достаточно откинуть первые несколько значений чтобы избавиться от негативного эффекта скейлинга частоты, то есть не обязательно фиксировать ее на одном уровне. Да, зафиксировать базовую частоту проще, особенно когда не хочется разбираться в том как работают режимы энергосбережения, но это даст тоже слегка искаженные результаты относительно реального мира (и это придется учитывать всем кто читает такого рода тесты).
Плюс на x86 иногда можно взять вместо cpython'а pypy и получить небольшой прирост скорости, а вот на Эльбрус его никто не портировал. Да, юз-кейс не очень распространенный, но тем не менее местами в production'е используется (соответственно разницу можно еще примерно на 10 умножать если брать pypy @ x86 и cpython на эльбрусе).
Так там Бабаян поясняет, почему Itanium не взлетел — потому что мог в параллель выполнять лишь 6 команд
Бабаян там явным образом говорит о несостоятельности VLIW подхода, фразой "Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…"
Дальше итаниум он приводит как ещё одно подтверждение, что даже у конкурентов не вышло. Не надо вырывать фразы из контекста, иначе смысл их теряется.
Да не, в том что это алгоритмы сортировки и что они работают у вас пока еще есть benefit of a doubt в этом. На авторитетов можно не ссылаться, а то начинает напоминать карго культ немного.
в тех условиях и с теми параметрами, которые нужны запускающему.
Ну я вам, как выбравшему тест, задал несколько вопросов. Получил на них ответы? Нет. Это достаточно, на мой взгляд, очерчивает уровень в первую очередь вашего понимания что вы делаете. А за сим дальнейший разговор теряет смысл. Разберетесь в вопросе достаточно чтобы обосновано дискутировать - можно будет продолжить.
Пардон, так как-раз таки я разобрался в вопросе, написал об этом и (даже, вынужденно) оформил еще один багрепорт в поддержку Supermicro.Теперь, похоже, Ваша очередь «разобраться в вопросе».
Так я ссылаюсь на ваш же пост раньше, где вы заявляли
похоже что постоянная работа на 3 ГГц - это вранье/маркетинг, а реальный стабильный максимум только 2800 МГц
И порадовался за Вас, что Вы наконец-то разобрались в мат. части в этом вопросе и понадеялся что больше не будет голословных обвинений.
Теперь буду ждать когда вы освоите мат часть теста, который сами же предложили в достаточно мере.
И вы проигнорировали половину того, что я сказал. Но, впрочем, ожидаемо. Уровень теста зато понятен.
Причина соскока на 2800 была в одной из ~20 опций BIOS в X12DPi-NT6 и (видимо, всё-таки) неточности, из-за которой некоторый захардкоженный/дефолтовый суммарный бюджет по частоте на все ядра был меньше чем 3000*12 на сокет.
Ну вот видите, а вы уже пытались обвинять интел, даже не разобравшись в вопросе.
Кто это сказал? Если глянуть тот же SPEC CPU, то никто там частоты не фиксирует. Управление питанием это такая же часть микроархитектуры и нынче чрезвычайно важная. Для бенчмарков надо не частоты лочить, а несколько раз их прогонять как это делается в том же SPEC CPU.
Более того - я не просто так в прошлом посте просил дать SPEC Power, который как раз фокусируется на энергоэффективности. Там умение менять частоту одно из основополагающих.
Но вообще типично еще используют прогрев и условно первые несколько итераций не засчитывают в общий зачет.
В целом к бенчмаркам человека выше есть ряд вопросов. Нарпимер что он меряет с размером массива в 42 тысячи элементов (и почему 42 тысячи это хорошее число?). Есть у меня предчувствие, что все упрется в L2 кэш (который при зарезании частот до 1.5 ГГц будет рабоать как ни странно на 1.5 ГГц) и у кого latency выше тот и победит (например из x86 скорее всего в топе окажется Sandy Bridge старенький, насколько я помню у него кэш чуть-чуть побыстрее как раз), если только компилятор совсем плохой код не сгенерировал. Впрочем надо конечно разобрать бенчмарк и посмотреть, но немного ради спора лень это проделывать (подожду мнения и доказательства от автора). Правда мне кажется автор обиделся за то что его второй аккаунт забанили.
Если процессор работает ниже спеки, то платформа говно и, по сути, не может работать с этим процессором, посему он должен быть исключен из ее списка поддерживаемых процессоров.
Не обязательно. Мог ошибиться сборщик системы или эксплуататор (перегрев VRM платы может вызывать троттлинг процессора, а это может быть вызвано тем что эксплуататор допустим поставил систему в закрытый шкаф рядом с трубой горячей воды или еще чем-нибудь подобным). По хорошему систему надо сдать по гарантии (если не сам собирал, если сам - долго и нудно дебажить в чем проблема).
А то я поискав нашел случай 2009 года про попытку купить Опель консорциумом из канадской Magna и Сбербанка, а потом на базе документов из wikileaks уже в 2011 году стало известно что сделка сорвалась потому что потенциальные покупатели хотели позже продать заводы российскому государственному автопроизводителю, что вкупе с рестуктуризацией GM позволило им выбить гос поддержку и опель стало продавать не нужно.
Это в общем и целом не звучит как "не дали купить", причины были сугубо внутри GM.
Вы противоречите сам себе. С одной стороны утверждая что с выходом Opteron в 03 году Iyanium-у "настал капец",
Во первых я не говорил что настал капец, а я говорил что это был жесткий тайминг и весомый кусок преимуществ испарился.
а с другой стороны подтверждая. что запрос клиентов на Itanium в 08 у HP был таков, что бы склонить их к целесообразности разработки нового поколения Itanium.
Во вторых я ничего не говорил про запрос клиентов у HP. Более того, насколько я знаю, публично количество клиентов на Итаниумы у HP в 2008 году неизвестно. Так что это можно использовать как подтверждение веры HP в платформу, но не более того.
В 03 году Opteron, конечно, вышел, и, спасибо плотному сотрудничеству с Sun, умел в 8-сокетные сервера, но ещё несколько лет не было нормальных программных решений (ОС, СУБД и т.д.), которые позволяли бы эффективно такие системы использовать.
Windows Server 2003 x64 вышел примерно в том же году, Linux в amd64 научился практически сразу (с софтом да, где-то год-полтора еще надо было потерпеть). Тем более это открывало простор для горизонтального масштабирования в рамках виртуальных машин на одном сервере, если уж очень хотелось "здесь и сейчас"
Да и стоимость таких серверов ничем не уступала стоимости Itanium/PA-RISC/Power/SPARC серверов
К сожалению я недостаточно хорошо помню цены на 8-и сокетные сервера в те времена, а также довольно плохо помню цены и на итаниумы со спарками. Поэтому с одной стороны не готов Вам верить на слово (как минимум потому что на рынке commodity серверов всегда были игроки второго и третьего эшелона, которые продавали железо качеством похуже, но и значально дешевле чем HP и прочие крупные товарищи).
Например, "смерть" SPARC в "борьбе" с x86 является следствием подковёрных игр представителей высшего менеджмента Oracle борьбе за "трон" (пост CEO) при грядущем "отходе от дел" Ларри Эллисона.
Извините, но смерть SPARC случилась по факту раньше чем Oracle купил SUN. Посмотрите на доли на рынке и на revenue в период до января 2010 года (момент окончания покупки SUN'а).
Если вкратце, то начиная с 2004 года SUN выпускает x86 сервера, потому что доля на рынке начинает падать (хотя выручка все еще растет). В 2007 году SUN уже не первые на рынке, а всего лишь третьи по выручке и 6-ые по доле.
То есть к моменту покупки их Oracle'ом там никакого доминирования не было уже годы. На тот момент (если посмотреть) x86 владел уже половиной рынка серверов, а доля SPARCов из года в год только падала. (если что я понимаю что по хорошему надо еще отдельно смотреть на доли SPARC-решений от Fujitsu, но они в целом вели себя также как SUN, а прям полноценный таймлайн делать это очень много кропотливой работы)
В общем и целом у SUNа было все плохо еще когда он был SUN'ом. Так что не вижу как борьба за власть в Oracle могла повлиять.
Про "банки уходят в облака" отдельно улыбнуло. Прям "табор уходит в небо". :) Не пересказывайте эту байку представителям российских и немецких финансовых структур, что бы не попасть в неловкую ситуацию.
Так а где байка то? Вбейте в поиск:
Deutsche Bank signs cloud deal
HSBC Cloud Strategy
Goldman Sachs Cloud
JPMorgan Chase cloud
Это только про крупные, которые заявили о заключении контрактов предполагающих миграцию критичных для банка систем в облака. В целом почитайте тот же forbs с их аналитикой или аналитику от accenture (прошу прощения что не оригинальный язык, искал информацию про российские банки).
Нет, нельзя. Если только вы не планируете выкупить Арм со всеми потрохами
Можете доказать, что нельзя без покупки ARM?
Соседи живут в крепости, построенной врагами. А так да, мы будем чувствовать себя в большей безопасности, а у купленной стены поставим сторожа.
Продолжая такую аналогию - вы всего лишь проектируете помещение, используя уже предоставленный список материалов, притом строят стены тоже внешние подрядчики, да и САПР импортный (делается чип на TSMC, используя их библиотеки и иностранный САПР). Поставленный сторож тоже будет импортным, к слову (как и его будка и ружжо). Можно разве что разобрать здание по кирпичикам и раскрошить кирпичики, но потом надо будет все изучать под микроскопом, чтобы точно убедится что ни на каком этапе не было включено в проект чего-то странного (а то поди докажи что это арматура в стенах, а не хитроумное устройство для ослабления конструкции или подрыва всего здания или что арматура не будет выполнять роль антенны).
Если этот самый PHY умеет подменять данные так чтобы конторольные суммы сходились, тогда лучше сразу сдаться.
Не надо пенять на научные работы плохого качества. То что в России в целом отсутствует культура написания научных работ (и публикаций результатов изысканий) не значит что это нормальная практика и так надо делать.
Простите, но звучит как очень слабое оправдание. Так что я продолжу настаивать что либо не пишите статью, либо выкладывайте нормально результаты.
возможно мне стоило выразиться мягче, не как провал, а как производительность ниже ожидаемой по заявлениям на презентации.
Да в общем-то нет, как заявляли что будет холоднее и быстрее - так примерно и вышло.
Я обзор смотрел по выходу m1, результаты запомнил, конкретные тесты\блоки нет. Мне техника apple неинтересна. ЕМНИП там было ускорение редактирования видео.
Вот не только в редактировании было. По факту прирост был везде. Естественно в плане видеокодирования - аппаратные блоки сыграли свою роль, но вот прирост в скорости работы браузера - чисто за счет микроархитектуры. Также и в других задачах, типа компиляции и даже, как ни странно, в обработке фото (фотшопы, лайтрумы и прочие capture one на M1 везде где не задействован GPU работают быстрее чем старые Macbook Pro 16" на Intel'ах, но вот где GPU-интенсивные задачи, там они проседают).
Собственно гипотеза "да это все из-за ускорителей" была в начале, пока была доступна только официальная презентация (в ней упор был на видеоредакторе сделан), но этот миф развенчали как только у людей устройства появились на руках.
Ассемблер и, тем более, исходники у нас в России никто не показывает.
Когда пишешь статью об оптимизации и сравнении и не показываешь исходники - сводит на нет полезность статьи и по сути статья ничем не отличается от фразы "мы что-то потестировали и что-то получили".
Я просто хочу указать, что в публичных компаниях есть документы, к которым выдвигаются жесткие требования.
Само собой, это достаточно очевидная вещь.
Конечно же, директор в такой компании должен вести себя соответственным образом.
А вот тут уже не совсем очевидный момент - директор должен вести себя соответствующим образом даже не в публичной компании. Я повторюсь уже в который раз - даже если компания закрытая, но директор соврал в публичном заявлении - он может понести ответственность за это, вплоть до уголовной. Это будет сложнее доказать, чем манипуляцию цен на акции, но вполне возможно, особенно если события повторяются периодически. Собственно когда CEO публикует такие цифры у себя в твиттере, скорее всего он видел бумажку где эти цифры были продемонстрированы, это достаточно разумное предположение, если конечно человек не мазохист и не хочет в будущем слегка присесть.
А какая связь между твиттером и инвесторами? В частных компаниях владельцы информацию не из Интернета получают, а, к примеру, через отчеты назначенных директоров.
Небольшой ликбез - когда C-level пишет или говорит что-то публично это считается авторитетным заявлением и за ложь в них он несет такую же ответственность как за ложь в официальной отчетности. На самом деле не только про C-level речь, но чем ниже должность и вовлеченность человека в бизнес, тем больше свободы в высказываниях позволяется. У Маска, как основателя, свободы в высказывании таких вещей самый минимум, иначе есть неиллюзорный шанс повторить судьбу Теранос в будущем, если вдруг на практике это не реализуется.
И раз уж мы об этом говорим, то проведу небольшой ликбез. К торгуемым на биржах компаниям применяются свои правила.
И опять же за определенные публичные высказывания торгуемой на бирже компании тоже могут настучать по шапке, там это чуть проще, так как показать связь с манипуляцией ценой на акции чуть проще, чем доказать введение инвесторов в заблуждение. Но разница не принципиальная.
Я почему-то думал что торгуется. В общем принципиально картины не меняет - есть инвестеры кроме Маска, за распространение ложных сведений будет ответственность как перед инвестерами, так и вплоть до уголовной.
Меряться Твитами мистера Маска - это Вы конечно "здорово" (читать - не научно) придумали.
Тут какое дело - SpaceX - публичная компания, мистер Маск отвечает головой перед инвесторами за то что пишет касательно SpaceX и их продуктов. То есть если он соврал в твитте - это может грозить ему лично большим штрафом или уголовкой (вы в соседнем треде правильно упоминали Theranos, там собственно текущие суды над основателями идут, упрощенно, за введение инвесторов в заблуждение). Поэтому не понимаю почему это не может являться надежным источником информации.
Серия 1, она же просто Raptor, имеет официальные ТТХ по тяге в 185 тон. Именно эти данные и указаны в Вики в описании устройства. Это не опечатка.
Вы сослались на википедию. Википедия пишет про 185 тс ссылаясь на твитт маска, заявляющий "225 тс".
Если есть более официальное место - можете просто на него дать ссылку и поправить википедию (указав корректный источник и/или исправив цифру).
Вы же ссылаетесь на пиковое значение стендового прототипа, которое зафиксировано Твитом мистера Маска.
А где в его твитте это написано?
Более того - как понять на какое значение ссылается табличка про РД-181? (вопрос совсем серьезный, потому что на википедии пруф-линки дохлые)
Позвольте заметить, что используя метод от обратного к вашему утверждению: "у плохих товаров случаются продажи" можно ли утверждать, что: "у хороших товаров продажи не случаются"?
Метод "от обратного" обычно применяется в математике. Укажите пожалуйста что позволило вам сделать выводы, что я говорю в математическом поле?
Я, например, не считаю что спор выше можно к таковому отнести, а значит "от обратного" не применимо напрямую к фразам (и более того, это тоже будет примером подмены совпадения на следствие, как делал человек, с которым я дискутировал).
Считаю, что наличие продаж (неважно каким методом обеспеченных) - это позитивный знак для любого начинания в целом, нежели "классные технические перспективы" и полное отсутствие продаж. Вспомним историю Theranos? За технику отвечал целый лауреат премии Шао в области молекулярной биологии. Супер перспективно и технически обоснованно (на допустимом в тот момент уровне).
Theranos хороший пример того, что продажи и перспективы - вещи не связанные друг с другом (потому что у них как раз продажи были, а вот технология отсутствовала даже в теории, на момент продаж).
Тогда Вы не поняли вопрос. Переформулирую - какой в этом смысл?
Изменение частоты имело бы смысл, если бы у Эльбрусов была бы перспектива достичь 3 ГГц вот прям в ближайшем будущем без микроархитектурных изменений. Такой перспективы нет, значит занижение частоты не имеет смысл, так как, как ни странно, микроархитектура на нее влияет напрямую.
То есть уже один момент где сравнение заведомо некорректно.
Прочитайте, пожалуйста, мой вопрос повнимательнее. К сожалению для качественного сравнения "потому что 42" не является достаточным ответом.
Я напомню - я пытаюсь понять какую конкретно часть аппаратуры вы тестируете (чтобы понимать ожидаемое). Потому что пока что ваш пример очевидно может показать проблемы с оптимизацией кода на стороне компилятора (тут то что нужно делать изменение чтоб получить +10% - показательно, но нет объяснений почему тот же самый код что на Эльбрусах не был проверен на интеле). Почему это важно? Потому что Вы привели тест в рамках рассуждений о микроархитектурной скорости, значит нужно обоснование что тест является показательным и будет показывать сильные и/или слабые стороны архитектуры.
С подходом, отрицающим объяснения и попыток докопаться до сути тест не имеет никакого теоретического или практического смысла. Почему? Представим себе гипотетическую ситуацию что вы тестируете по факту скорость работы кэша (комбинированно throughput + latency), в таком случаи у вас практически любая железка, включая простой in-order risc-v или arm (кстати тоже было бы неплохо проверить Ваш тест) будет давать крайне схожие результаты, если компилятор конечно делает хоть какие-то оптимизации, на базе этого строить какие либо выводы будет невозможно.
Я не говорил что вы сравниваете что-то в таком духе, я это использовал только в рамках указания другому человеку что есть другие способы получить разумные и даже повторяемые результаты без отключения энергосбережения.
Но такое сравнение было бы интересно, потому что, как ни странно, электричество это важная статья расходов какого-нибудь ЦОДа и если у тебя есть железка которая выдает X попугаев потребляя Y Ватт, и другая железка, выдающая X*2 попугаев потребляя те же Y Ватт, это очень весомый довод в пользу железки №2 даже если она стоит вдвое дороже (на горизонте типичной эксплуатации железа, затраты на электроэнергию выйдут на первое место, помноженное на десятки тысяч серверов это составит уже нехилую такую сумму). Но корректное тестирование железа в таком режиме уже не так просто реализовать (нужно как минимум уметь понимать свое энергопотребление, а по хорошему вообще отдать это на откуп внешнего устройства, которое на выходе даст лог за время проведения теста). И такое я вполне требую от людей из МЦСТ, как от компании (и требовал бы от тестовых лабораторий и прочих журналистов, в это влезших), но Вы вроде бы в категорию "человек из МЦСТ" не попадаете?
Оно также имело смысл для другого человека в первую очередь. Но для Вас оно имеет тот смысл, что во время первых нескольких итераций частота ядра успеет подняться до стабильного уровня и достаточно откинуть первые несколько значений чтобы избавиться от негативного эффекта скейлинга частоты, то есть не обязательно фиксировать ее на одном уровне. Да, зафиксировать базовую частоту проще, особенно когда не хочется разбираться в том как работают режимы энергосбережения, но это даст тоже слегка искаженные результаты относительно реального мира (и это придется учитывать всем кто читает такого рода тесты).
Плюс на x86 иногда можно взять вместо cpython'а pypy и получить небольшой прирост скорости, а вот на Эльбрус его никто не портировал. Да, юз-кейс не очень распространенный, но тем не менее местами в production'е используется (соответственно разницу можно еще примерно на 10 умножать если брать pypy @ x86 и cpython на эльбрусе).
Бабаян там явным образом говорит о несостоятельности VLIW подхода, фразой "Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…"
Дальше итаниум он приводит как ещё одно подтверждение, что даже у конкурентов не вышло. Не надо вырывать фразы из контекста, иначе смысл их теряется.
Да не, в том что это алгоритмы сортировки и что они работают у вас пока еще есть benefit of a doubt в этом. На авторитетов можно не ссылаться, а то начинает напоминать карго культ немного.
Ну я вам, как выбравшему тест, задал несколько вопросов. Получил на них ответы? Нет. Это достаточно, на мой взгляд, очерчивает уровень в первую очередь вашего понимания что вы делаете. А за сим дальнейший разговор теряет смысл. Разберетесь в вопросе достаточно чтобы обосновано дискутировать - можно будет продолжить.
Так я ссылаюсь на ваш же пост раньше, где вы заявляли
И порадовался за Вас, что Вы наконец-то разобрались в мат. части в этом вопросе и понадеялся что больше не будет голословных обвинений.
Теперь буду ждать когда вы освоите мат часть теста, который сами же предложили в достаточно мере.
И вы проигнорировали половину того, что я сказал. Но, впрочем, ожидаемо. Уровень теста зато понятен.
Ну вот видите, а вы уже пытались обвинять интел, даже не разобравшись в вопросе.
Более того - я не просто так в прошлом посте просил дать SPEC Power, который как раз фокусируется на энергоэффективности. Там умение менять частоту одно из основополагающих.
Но вообще типично еще используют прогрев и условно первые несколько итераций не засчитывают в общий зачет.
В целом к бенчмаркам человека выше есть ряд вопросов. Нарпимер что он меряет с размером массива в 42 тысячи элементов (и почему 42 тысячи это хорошее число?). Есть у меня предчувствие, что все упрется в L2 кэш (который при зарезании частот до 1.5 ГГц будет рабоать как ни странно на 1.5 ГГц) и у кого latency выше тот и победит (например из x86 скорее всего в топе окажется Sandy Bridge старенький, насколько я помню у него кэш чуть-чуть побыстрее как раз), если только компилятор совсем плохой код не сгенерировал. Впрочем надо конечно разобрать бенчмарк и посмотреть, но немного ради спора лень это проделывать (подожду мнения и доказательства от автора). Правда мне кажется автор обиделся за то что его второй аккаунт забанили.
Не обязательно. Мог ошибиться сборщик системы или эксплуататор (перегрев VRM платы может вызывать троттлинг процессора, а это может быть вызвано тем что эксплуататор допустим поставил систему в закрытый шкаф рядом с трубой горячей воды или еще чем-нибудь подобным). По хорошему систему надо сдать по гарантии (если не сам собирал, если сам - долго и нудно дебажить в чем проблема).
А есть где почитать про "не дали купить" это?
А то я поискав нашел случай 2009 года про попытку купить Опель консорциумом из канадской Magna и Сбербанка, а потом на базе документов из wikileaks уже в 2011 году стало известно что сделка сорвалась потому что потенциальные покупатели хотели позже продать заводы российскому государственному автопроизводителю, что вкупе с рестуктуризацией GM позволило им выбить гос поддержку и опель стало продавать не нужно.
Это в общем и целом не звучит как "не дали купить", причины были сугубо внутри GM.
Во первых я не говорил что настал капец, а я говорил что это был жесткий тайминг и весомый кусок преимуществ испарился.
Во вторых я ничего не говорил про запрос клиентов у HP. Более того, насколько я знаю, публично количество клиентов на Итаниумы у HP в 2008 году неизвестно. Так что это можно использовать как подтверждение веры HP в платформу, но не более того.
Windows Server 2003 x64 вышел примерно в том же году, Linux в amd64 научился практически сразу (с софтом да, где-то год-полтора еще надо было потерпеть). Тем более это открывало простор для горизонтального масштабирования в рамках виртуальных машин на одном сервере, если уж очень хотелось "здесь и сейчас"
К сожалению я недостаточно хорошо помню цены на 8-и сокетные сервера в те времена, а также довольно плохо помню цены и на итаниумы со спарками. Поэтому с одной стороны не готов Вам верить на слово (как минимум потому что на рынке commodity серверов всегда были игроки второго и третьего эшелона, которые продавали железо качеством похуже, но и значально дешевле чем HP и прочие крупные товарищи).
Извините, но смерть SPARC случилась по факту раньше чем Oracle купил SUN. Посмотрите на доли на рынке и на revenue в период до января 2010 года (момент окончания покупки SUN'а).
Если вкратце, то начиная с 2004 года SUN выпускает x86 сервера, потому что доля на рынке начинает падать (хотя выручка все еще растет). В 2007 году SUN уже не первые на рынке, а всего лишь третьи по выручке и 6-ые по доле.
То есть к моменту покупки их Oracle'ом там никакого доминирования не было уже годы. На тот момент (если посмотреть) x86 владел уже половиной рынка серверов, а доля SPARCов из года в год только падала. (если что я понимаю что по хорошему надо еще отдельно смотреть на доли SPARC-решений от Fujitsu, но они в целом вели себя также как SUN, а прям полноценный таймлайн делать это очень много кропотливой работы)
В общем и целом у SUNа было все плохо еще когда он был SUN'ом. Так что не вижу как борьба за власть в Oracle могла повлиять.
Так а где байка то? Вбейте в поиск:
Deutsche Bank signs cloud deal
HSBC Cloud Strategy
Goldman Sachs Cloud
JPMorgan Chase cloud
Это только про крупные, которые заявили о заключении контрактов предполагающих миграцию критичных для банка систем в облака. В целом почитайте тот же forbs с их аналитикой или аналитику от accenture (прошу прощения что не оригинальный язык, искал информацию про российские банки).
Можете доказать, что нельзя без покупки ARM?
Продолжая такую аналогию - вы всего лишь проектируете помещение, используя уже предоставленный список материалов, притом строят стены тоже внешние подрядчики, да и САПР импортный (делается чип на TSMC, используя их библиотеки и иностранный САПР). Поставленный сторож тоже будет импортным, к слову (как и его будка и ружжо). Можно разве что разобрать здание по кирпичикам и раскрошить кирпичики, но потом надо будет все изучать под микроскопом, чтобы точно убедится что ни на каком этапе не было включено в проект чего-то странного (а то поди докажи что это арматура в стенах, а не хитроумное устройство для ослабления конструкции или подрыва всего здания или что арматура не будет выполнять роль антенны).
Технически что ему помешает так делать?
Не надо пенять на научные работы плохого качества. То что в России в целом отсутствует культура написания научных работ (и публикаций результатов изысканий) не значит что это нормальная практика и так надо делать.
Простите, но звучит как очень слабое оправдание. Так что я продолжу настаивать что либо не пишите статью, либо выкладывайте нормально результаты.
Да в общем-то нет, как заявляли что будет холоднее и быстрее - так примерно и вышло.
Вот не только в редактировании было. По факту прирост был везде. Естественно в плане видеокодирования - аппаратные блоки сыграли свою роль, но вот прирост в скорости работы браузера - чисто за счет микроархитектуры. Также и в других задачах, типа компиляции и даже, как ни странно, в обработке фото (фотшопы, лайтрумы и прочие capture one на M1 везде где не задействован GPU работают быстрее чем старые Macbook Pro 16" на Intel'ах, но вот где GPU-интенсивные задачи, там они проседают).
Собственно гипотеза "да это все из-за ускорителей" была в начале, пока была доступна только официальная презентация (в ней упор был на видеоредакторе сделан), но этот миф развенчали как только у людей устройства появились на руках.
В каком месте совместное предприятие = покупка?
Когда пишешь статью об оптимизации и сравнении и не показываешь исходники - сводит на нет полезность статьи и по сути статья ничем не отличается от фразы "мы что-то потестировали и что-то получили".
Само собой, это достаточно очевидная вещь.
А вот тут уже не совсем очевидный момент - директор должен вести себя соответствующим образом даже не в публичной компании. Я повторюсь уже в который раз - даже если компания закрытая, но директор соврал в публичном заявлении - он может понести ответственность за это, вплоть до уголовной. Это будет сложнее доказать, чем манипуляцию цен на акции, но вполне возможно, особенно если события повторяются периодически. Собственно когда CEO публикует такие цифры у себя в твиттере, скорее всего он видел бумажку где эти цифры были продемонстрированы, это достаточно разумное предположение, если конечно человек не мазохист и не хочет в будущем слегка присесть.
Небольшой ликбез - когда C-level пишет или говорит что-то публично это считается авторитетным заявлением и за ложь в них он несет такую же ответственность как за ложь в официальной отчетности. На самом деле не только про C-level речь, но чем ниже должность и вовлеченность человека в бизнес, тем больше свободы в высказываниях позволяется. У Маска, как основателя, свободы в высказывании таких вещей самый минимум, иначе есть неиллюзорный шанс повторить судьбу Теранос в будущем, если вдруг на практике это не реализуется.
И опять же за определенные публичные высказывания торгуемой на бирже компании тоже могут настучать по шапке, там это чуть проще, так как показать связь с манипуляцией ценой на акции чуть проще, чем доказать введение инвесторов в заблуждение. Но разница не принципиальная.
Спасибо. Тут тоже интересное - разница тяги в вакууме и на уровне моря и для английской википедии указывается только одно значение.
И вот разница - в вики 209 тс, в документе 212.2 (или 196), опять же к вопросу о данных в википедии.
Я почему-то думал что торгуется. В общем принципиально картины не меняет - есть инвестеры кроме Маска, за распространение ложных сведений будет ответственность как перед инвестерами, так и вплоть до уголовной.
Зависит от масштаба лжи, вплоть до уголовного преследования.
Вы сослались на табличку на вики, которая ссылается на твитт, я лишь прошёл по ссылке проверить правильность данных.
Более того, я уже указал ранее ссылкой, что на той же странице есть вторая табличка где значения другие. Вы её проигнорировали.
Извините, но я не вижу причин доверять вашим заявлениям, так как я уже указал вам на несоответствия в вашем же источнике информации.
Тут какое дело - SpaceX - публичная компания, мистер Маск отвечает головой перед инвесторами за то что пишет касательно SpaceX и их продуктов. То есть если он соврал в твитте - это может грозить ему лично большим штрафом или уголовкой (вы в соседнем треде правильно упоминали Theranos, там собственно текущие суды над основателями идут, упрощенно, за введение инвесторов в заблуждение). Поэтому не понимаю почему это не может являться надежным источником информации.
Вы сослались на википедию. Википедия пишет про 185 тс ссылаясь на твитт маска, заявляющий "225 тс".
Если есть более официальное место - можете просто на него дать ссылку и поправить википедию (указав корректный источник и/или исправив цифру).
А где в его твитте это написано?
Более того - как понять на какое значение ссылается табличка про РД-181? (вопрос совсем серьезный, потому что на википедии пруф-линки дохлые)
Метод "от обратного" обычно применяется в математике. Укажите пожалуйста что позволило вам сделать выводы, что я говорю в математическом поле?
Я, например, не считаю что спор выше можно к таковому отнести, а значит "от обратного" не применимо напрямую к фразам (и более того, это тоже будет примером подмены совпадения на следствие, как делал человек, с которым я дискутировал).
Theranos хороший пример того, что продажи и перспективы - вещи не связанные друг с другом (потому что у них как раз продажи были, а вот технология отсутствовала даже в теории, на момент продаж).