И всё же… Если в рабочем режиме код падает в HardFault, то это очень и очень плохо. При чем не важно чей это косяк. Программиста, схемотехника, конструктора, трассировщика, монтажника, закупщика, ОТК или ещё кого. Если такое возникает, то просто жизненно необходимо пересмотреть производственный процесс и исключить косяки. Маскировка их пусть даже грамотно написанным обработчиком — смертный грех. Исключение только целенаправленное использование HardFaultHandler'a в собственных целях. Но это экзотика на грани эзотерики.
Спасибо. Я о чём-то похожем читал в руководстве по отлову проблем в IAR EWARM. Однажды словил и сильно удивлялся отсутствия backtrace'a. Давно дело было… Так что хорошо что теперь есть и на русском. Статья однозначно достойна.
Что до критики в комментариях, то размещение кода внутри HardFaultHandler это в любом случае фол последней надежды. Не должна боевая программа сюда попадать. А раз попадает, то надо выжимать максимум. Всеми доступными способами.
Ну и ещё момент. При всей грозности этого обработчика, это только обработчик. И при желании из него можно нормально выйти. На этом можно строить защиту своего кода и сводить с ума дизассемблеры явно не ожидающие такого поведения.
Зевая Я подожду десктопа и проверю. Там и будет видно быстрее ли, энергоэффективнее ли, дешевле ли. А то сравнивать iPhone и десктопную машину все равно что сравнивать пончики с Айвазовским. Буквально недавно Microsoft пытались. Даже не для десктоп, а то ли планшет, то ли ноутбук. По ощущениям у них не получилось.
А тестировать каждую разрекламированную новинку у меня нет ни времени, ни денег, ни желания. Мне деньги не за это платят. К слову а вы не один из сотрудников того новостного портала на который ссылки шлете?
Вы в курсе про чайник Рассела? Надеюсь да, и тогда я жду продолжения. Меня настолько часто обвиняют в некомпетентности, что я даже сопротивляться не буду. Но, думаю, что если б хоть у кого-то был ARM достаточно производительный, чтоб потеснить современный Intel и об этом можно было бы писать не боясь судебных исков, то все бы давно гудели. А так быстрее, но со звёздочкой (на отдельных задачах). И именно понимание архитектуры и процессора как такового и системы в целом и позволяет мне предполагать с хорошей долей уверенности что таковое в принципе невозможно. Если конечно не сравнивать ультра современный ARM с допотопным Intel. Но тогда мой браслет на порядки производительные суперкомпьютеров прошлого. И да, напоминаю про чайник (и жду продолжения).
Как изволите, но мне не пришлось бы разжёвывать элементарные вещи, если бы вы в них ориентировались. Расширяйте кругозор.
Хм… Понимаете какое дело. Мне, как человеку который уже не один десяток лет занимается адаптацией загрузчиков и ядра Linux под разные камни (включая те, на которых ни одно ни другое даже не поддерживается) безусловно стоит расширять кругозор. И конечно мне не надо объяснять элементарные вещи. Хотя не скрою — я очень люблю послушать как именно их объясняют. Очень много сразу становится понятно о человеке. Насколько глубоко он в теме, по каким «учебникам» учился. Потому позволю себе встречный совет вам: вечно расширять кругозор не получится. Мир меняется сильно быстрее, чем вы об этом успеваете даже прочесть. Потому выберите уже тему, в которой вам будет интересно и копайте вглубь. Нет ничего страшного в том, что не знаешь всего.
Давайте так. Если не забуду, то закончится отпуск я напишу сюда ТТХ сервера. Просто не заострял внимания (мне не интересно было).
Про остальное. Ну хорошо, будем считать что я согласился. Мне спорить с редакторами www.anandtech.com совсем не хочется. А не верить им безоговорочно — это мое право. Как и право сомневаться в кроссплатформенных тестах. Даже подсчет хешей или расcчет числа Pi (казалось бы чисто вычислительные задачи) не дают четкого результата.
Потому просто повторю основную идею — ждем. Ждем цен. Ждем реальных оценок (что бы это не значило). Будет любопытно если десктопный ARM от Apple окажется быстрее серверного 1,5-годичной давности. Впрочем, сильно такому раскладу я не удивлюсь.
Ну т.е. ездите на Ладе Приоре, но рассужаете о каком нибудь Porsche, дескать, он точно ничем не лучше. Ясно, понятно.
Может быть. А может быть просто не пытаюсь использовать карьерный Белаз для ежедневных поездок на работу через центр города-миллионника. И тем более не пытаюсь найти оправдания того для чего я этим мог бы заниматься. А межу поршом и приорой общего сильно больше чем кажется. И уж точно нельзя познать особенности реализация порша не зная как работает приора или любой ее импортный аналог (если на отечественные авто стойкая аллергия).
Поправка про SPARC засчитана. Виноват. Все остальное для меня требует пояснения. То что вы пишите или слишком умно и сильно опережает мои знания, или… ровно наоборот (буду политкорректен). Я не понял про Intel и AMD. История этих компаний слишком на слуху для того чтоб так безапеляционно заявлять что их роднит только набор инструкций и так было всегда. Да и методика зарабатывания денег компанией ARM мне представляется несколько по другому.
Наверное. Тут главное не сильно путать теплое с мягким. Мне крайне сложно оценивать то, чего я не видел и не щупал. И если производительность MacBook я примерно представляю, то с iPad Pro темный лес. Впрочем программировать на планшете — это тоже похоже на оживший ночной кошмар. По крайней мере персонально для меня.
Шины и кеши — это мое. Это я должен понимать за счет чего достигается такая производительность и где ждать подводных камней таких решений (понимать границы применимости). Согласен, пользователю это не очень интересно (если вообще интересно). И в этом плане тот же браузер не всегда показателен. Страница для iPad и для десктопа могут оказаться очень разными, даже рекламой разной и по разному напичканными. Одно это может вносить существенные искажения в восприятие скорости работы. Потому давайте я соглашусь с любой позицией. Говорите ARM от Apple в однопоточном режиме быстрее Intel'а — ОК, пусть будет так. Говорите что у Apple самая быстрая реализация AArm64 — не вопрос. Время рассудит что тут правда, а что вымысел и подгон под требуемый ответ.
Давайте начнем сначала. Я не мазохист. Серверный ARM заказали себе прикладники. Там ARM-v8 (64 бита), дай бог памяти 16 ядер и не помню сколько оперативы и тактовую частоту. Настаиваете могу уточнить. Он занят сборкой прикладного ПО (сюрприз-сюрприз как раз на ARM-v7a). Я пробовал собирать свои приколы (U-Boot, Linux 4.x по тем временам). Так вот по времени компиляция выполнялась в разы дольше, чем на настольном 12-ядерном i7-extreme и незначительно быстрее (дай бог памяти процентов на 10), чем на выделенной мне сборочной витруалке на Windows Server под Hyper-V. Дело было год-полтора назад. Повторять эксперимент не хочу, ибо см. второе предложение данного ответа.
Ось почти всегда Linux. Железо — встраиваемые железки с arm-v7a, arm-v8 (последнее время от Freescale). Это наша целевая платформа. Пробовал железки и от NVidia (для нас избыточны) и от более «приземленных» производителей (ST Microelectronics, Atmel). Да, выборка не очень презентативна в части производительности, но я и сравниваю их отзывчивость не с Xenon'ами. Скоре с Atom'ами и Celeron'ами. Что до «нет ощущения тормозов» — так на том что делаем мы тоже нет ощущения тормозов. Иначе бы железки наши не покупали. Не путайте пользовательский опыт и ощущения разработчика. Я знаю о своем изделии сильно больше, чем конечный пользователь. Так что верю — нет ощущения тормозов и славненько. Я буду очень рад оказаться не правым и пересмотреть свои взгляды. Ждем.
Clang, к примеру, на телефоне Apple я не запускал. У меня из Apple есть только macOs на хакинтоше. Потому действительно сказать ничего не могу. Но взялись писать — пишите. Что компилирует Clang на смартфоне и x86 (и который из них самый топовый, участвующий в сравнении)? Они производят один и тот же бинарь или разные? Где вообще описание данного теста?
И все же я позволю себе остаться при своем мнении. Посмотрите свою ссылку. Там много объяснений того, почему а Apple система оказывается быстрее. Ширины шины данных, размер кешей. Другое дело, что есть серьезный вопрос поможет ли это в реальной жизни на реальных задачах, а не на чистой синтетике. И да, Intel и AMD можно (и нужно) сравнивать. Собственно все именно этим и занимаются.
Ну, а то что Apple может «вытягивать» из ARM максимум, так это хорошо. Но я сомневаюсь что на реальных задачах там будут «разы». Хотя… Вспоминая как вел себя ARM-v7 с 16-разрядной шиной памяти в сравнении с тем же ядром, но 32-разрядной шиной могу сказать что все возможно. Ждем. Пока просто ждем.
Давайте с конца. Я нигде не писал, что компилировать нативно нельзя. Можно. Это вполне себе работает. Но попробуйте собрать сколько-нить серьезный проект нативно. В моем случае это обычно ядро Linux, gcc или что-то подобное (chromium, firefox). И тут выяснится что кросс-компиляция на Intel сильно быстрее нативной компиляции. Да и XCode пока работает в основном на Intel, хоть и делает код для ARM'а. Я не фанат мобильной техники Apple, потому не могу объективно ее оценивать. К слову поправьте если не прав, но полагаю что никто не может — та доступ к консоли сильно лучше спрятан чем в том же Android'е. А тесты… это только тесты. Но повторюсь — жду цен. У меня есть желание пощупать desktop на ARM'е. Вопрос как всегда лишь в цене.
А вот про «не те процессоры» я не понял. Упомянутый A12Z основан на ядре ARMv8-A. Вполне понятно чего от ждать просто ориентируясь на построенные на близкородственных ядрах AARM64. Разве нет?
Нет, не сидел. Да, сравниваю с каким-то другим ARM (известность — понятие относительное). И что это меняет? Будет в несколько раз медленнее? Это как? ARM разработает отдельное ядро персонально для Apple? Что может сделать Apple для того чтоб в разы увеличить производительность? У них есть тайное знание, позволяющее обмануть природу?
Вообще сегодняшняя ситуация вокруг ARM до боли похожа на ситуацию с SPARK и SUN. Те тоже пытались подвинуть Intel как минимум на серверном рынке. Конечно, сейчас ARM сильно популярнее чем когда-то SPARK. Где сейчас тот SUN и тот SPARK? А очень похоже по ощущениям от работы с консолью.
И да, я не то что не против. Я за. Я жду цен. И имею (слабую) надежду на то, что какой-нить mac-mini с ARM появится у меня на столе. До тех пор любые разговоры это просто гадание на кофейной гуще. Я мои посты целиком и полностью основаны на собственном опыте работы с Linux на ARM (как 32-, так и 64-разрядных). Пока ощущение такое — жить можно, но только так. Большинство пользовательских задач (игры, видео, музыка, обработка видео) вполне себе выполнимы. А вот разработчиковские (та же компиляция) — одна сплошная боль. И вылечить эту боль может только очень серьезная многоядерность. Но и тут надо помнить про «корень из N» и весьма серьезное усложнение чипа. Потому повторюсь — попкорн запасен. А там посмотрим что за кино получится. Не удивлюсь ни комедии, ни триллеру.
Давайте так. Я не могу спорить с маркетологами. Как говорится «в рекламе вкусно показать можно что угодно». Но первое впечатление любого, кто садится за ARM после любого x86 (даже Atom'а не к ночи будь помянут) — это ощущение тормозной консоли. Все системные утилиты, рассчитанные на работу в однопоточном режиме выполняются сильно дольше привычного времени. Я не работал с «серверными» решениями. Есть такой, но у меня к нему доступа нет за ненадобностью — мне кросс-компиляция больше нравится. И в первую очередь ровно потому, что кросс-компиляция выполняется сильно быстрее, чем нативная. Потому мой собственный опыт и только. Однако, не думаю что Apple будет ставить в свои десктопы серверные ARM'овские решения на полсотни ядер. Но посмотрим.
Чудны дела твои… А если порассуждать? Давайте так — производительность ARM меньше производительности x86 (и x64, конечно) равной тактовой частоты. Гонка гигагерцев закончится довольно быстро. В сухом остатке явное преимущество x86/x64 в «числодробильных» задачах. И это преимущество «покупается» за невысокую энергоэффективность. До поры все было отлично, но некоторое время назад ящик пандоры оказался открытым. Вычисления на GPU (особенно сильно многопотоковые) оказались более эффективными, чем вычисления на CPU. Кодеки «встроенные» в GPU работаю быстрее и эффективнее аналогичных на CPU и меньше влияют на отзывчивость системы. OpenGL и его ближайшие родственники весьма эффективно обсчитывают трехмерные сцены. Таким образом потихоньку роль CPU как главного «числодробительного» механизма планомерно сокращается. А еще появляются многоядерные системы, позволяющие параллелить и базовые системные функции. Apple это очень хорошо прочувствовала на мобильных устройствах. А дальше простой вопрос — как подключить производительную видеокарту к ARM. Как только они решили этот вопрос, так сразу попытались сделать свой персональный десктоп. Посмотрим. Не все идеи Apple стреляют. По мне эта может стрельнуть. А может и не стрельнуть. Потому попкорн у меня уже запасен. Ждем.
Спасибо за поправку. Да, я в курсе что БГ был первым. Но мне в 81-ом было всего три, и, как следствие мне она знакома в исполнении Чайфа. Однако фактическая точность безусловно важна. Абсолютно согласен и принимаю.
Про ошибки в компиляторах и уровни оптимизации. Тот же компилятор С от Sun позволял себе оптимизировать даже ассемблерные вставки. Крайне сомнительная функциональность, которая к счастью отключалась. Вообще я бы поспорил с утверждением «от языка не сильно зависит». Зависит довольно серьезно. Чем проще «внутренний мир» языка, тем меньше простора для оптимизции. Тот же С сам по себе прост. Его за то и любят. По сути его «внутренний мир» эквивалентен «внутреннему миру» практически любого современного процессора. И именно по этой причине не все можно пихать в switch() и в нем настолько неудобная работа со строками. Это обратная сторона переносимости. Да и потом — всем котроллерщикам известна простая истинна — самый большой уровень оптимизации совсем не значит самый лучший. Все ответственные места просто необходимо проверять на ассемблере. Благо JTAG/SWD с современными IDE это позволяют без утомительного изучения промежуточного ассемблера как это было некоторое время назад. И да, очень часто приходится бороться с «шибко умным» компилятором. Впрочем, как правило код пишется так что его уму особо разгуляться негде.
Хотя надо еще посмотреть что будет получаться на выходе у того же Rust'а когда код на нем не будет содержать unsafe блоков (за что ратуют фанаты Rust, и без чего он превращается просто в очередной диалект С/С++).
Ну, мы с Вами так или иначе не первый раз пересекаемся в комментариях. Я бы очень хотел работать с Вами или Вашими студентами. Очень может быть что код выпускаемый компанией стал бы надежнее (что главное), а может даже и быстрее и проще сопровождаемым. Увы, но пока понимание как написать такие вещи красиво есть у очень небольшого числа людей. Я приверженец «классического C» как «платформо независимого ассемблера с элементами структурного синтаксиса» (с) OCTAGRAM Увы, мой опыт говорит о том, что по крайней мере пока от этого подхода не уйти. Да и плюсы от ухода сомнительны. Должна прийти «та молодая шпана, что сотрет нас с лица земли» (с) Чайф и своим результатам покажет динозаврам на дверь. Но строго по тексту от Чайф'а: «Ее нет, нет, не-ет. Hет, нет, не-ет...» Так что жду Ваших студентов. И это вполне серьезно. Лучше таких знатоков плюсов, чем тех кто кричит «дайте Linux, а лучше Windows — без них не могем».
Но жизнь забавно поворачивается. Два моих учителя спорили о том, что лучше С или ассемблер. Один кричал: «ты на асме пишешь как на С — у тебя сплошные макросы», второй отвечал: «за то указателями я кручу куда как более виртуозно и производительно». Первый парировал: «а вот о сохранении регистров и целостности стека я даже не думаю, да и в критических местах ассемблерные вставки никто не запрещал». И не было числа тем спорам. А сейчас вот уже и С с пьедестала низкоуровневого языка двигают. Сначала Java замахнулась, но не смогла. Теперь вот то Rust, то С++. И ведь подвинут. Вопрос только кто именно. И, самое главное, на что мне на старости лет переучиваться придется. И нужен ли я буду хоть кому-то со своим С, как нужны сейчас спецы по коболу (и частично фортрану).
Но это черт возьми риторика. И комментарий здесь оставил ровно за тем, чтоб не возникало мысли о том, что в принципе без указателей обойтись можно. Нельзя. Вопрос только в том кто ими рулить будет — разработчик ПО или разработчик компилятора. И с кого спрашивать будут. Ошибка работы с указателями когда она в исполнении разработчика ПО — это всего лишь ошибка. Неприятно. Временами даже смертельно, но это можно исправить. А вот та же ошибка в компиляторе сильно более опасна. Так кто и как будет контролировать контролеров? Вот те мысли, которые крутятся в моей голове.
Но все равно пишите. Вас приятно читать. Мне плюсы не сильно знакомы, но пока вроде ничего неподьемного нет. Мало ли пригодится где. И еще раз — статья просто шикарна.
Спасибо. Приятно читать статьи от профессионалов. Отличный слог, простое и понятное изложение, фактическая точность — просто отлично. А современное железо делает ее крайне актуальной. Будет куда отправлять тех, кто кричит что хочу современное железо, а не абстрактный или устаревший процессор. И да — решение совершенно не перегружено. В той же FreeFTOS понять что-то становится сложно. Кросплатформенность просто так не дается. Поэтому просто отлично.
Одно жаль — почему-то с телефона комметарий не пошел, потому пишу как только смог добраться до компьютера. Не буду про студентов — опять ветка не туда уйдет. А вот про указатели таки скажу. Мне кажется, что задача отказа от указателей (как минимум применительно к данной задаче) — она фантомная. И фантомно же решена. В том смысле, что указатели никуда не делись. Просто код написан так, что операции с ними явно не упоминаются. Вам удалось сделать это просто классно. Снимаю шляпу. Но в целом — не кажется Вам что это несколько… хм… неправильно. Архитектурно процессор оперирует указателями. Вся адресная арифметика это именно они. И если мы пишем код непосредственно на нем исполняющися, то… по мне знание и понимание адресной арифметики один из краеугольных камней. Ладно, когда речь идет о Java, Python или ком-то подобном. Но С/С++? Да по голому железу. В конце-концов PC и SP тоже указатели…
Спасибо. Принял к сведению и попробую поискать дальше. И, пожалуй, пока на этом остановлюсь. Домыслов сразу появилось много, но… Не люблю озвучивать домыслы. По крайней мере до тех пор, пока они в четкую картину мира не уложились. Пока могу только сказать что концентрация перекиси от 0,018 ± 0,004 до 0,104 ± 0,010 ммоль/г сырой массы в контроле намекает на то, что она скорее всего один из множества промежуточный продуктов коих зватает в растениях. Впрочем, сгласен — и это тоже уже домыслы.
В любом случае спасибо за ссылку.
Это тема отдельного и очень большого разговора. При чем лучше бы в исполнении настоящего биолога. Процесс дыхания все так же необходим и растениям и водорослям. У части растений вырабатываются очень интересные мехнизмы сохранения CO2, вырабатываемого в процессе дыхания в темновй фазе, и сохранения кислорода в светлой. Растительные мир крайне разнообразен и вариативен. А уж про водоросли даже заикаться не хочется. Их период эволюции просто огромен в сравнении с любыми животными.
Впрочем, я не припомню упоминаний о перекисе в вузовском учебнике по физиологии растений. Но надо будет перелистать на досуге.
Да, марганцовка известный окислитель. Она очень многое сделала для популяризации неорганической химии. Только описанное действо лучше проводить за преподвательским столом в кабинете химии или на некотором удалени от наблюдателей. Садиться вокруг может оказаться опасно. А safety first. Ладно, придется побаловать внутреннего ребенка и попробовать самому. А там уже будет видно стоит ли младшему поколению показывать.
Еще раз спасибо. Увы, я читатель — потому кроме как комментарием никак поблагодарить не могу.
И всё же… Если в рабочем режиме код падает в HardFault, то это очень и очень плохо. При чем не важно чей это косяк. Программиста, схемотехника, конструктора, трассировщика, монтажника, закупщика, ОТК или ещё кого. Если такое возникает, то просто жизненно необходимо пересмотреть производственный процесс и исключить косяки. Маскировка их пусть даже грамотно написанным обработчиком — смертный грех. Исключение только целенаправленное использование HardFaultHandler'a в собственных целях. Но это экзотика на грани эзотерики.
Спасибо. Я о чём-то похожем читал в руководстве по отлову проблем в IAR EWARM. Однажды словил и сильно удивлялся отсутствия backtrace'a. Давно дело было… Так что хорошо что теперь есть и на русском. Статья однозначно достойна.
Что до критики в комментариях, то размещение кода внутри HardFaultHandler это в любом случае фол последней надежды. Не должна боевая программа сюда попадать. А раз попадает, то надо выжимать максимум. Всеми доступными способами.
Ну и ещё момент. При всей грозности этого обработчика, это только обработчик. И при желании из него можно нормально выйти. На этом можно строить защиту своего кода и сводить с ума дизассемблеры явно не ожидающие такого поведения.
"Мы наш, мы новый мир построим" ©
Зевая Я подожду десктопа и проверю. Там и будет видно быстрее ли, энергоэффективнее ли, дешевле ли. А то сравнивать iPhone и десктопную машину все равно что сравнивать пончики с Айвазовским. Буквально недавно Microsoft пытались. Даже не для десктоп, а то ли планшет, то ли ноутбук. По ощущениям у них не получилось.
А тестировать каждую разрекламированную новинку у меня нет ни времени, ни денег, ни желания. Мне деньги не за это платят. К слову а вы не один из сотрудников того новостного портала на который ссылки шлете?
А про чайник все же почитайте. Зевая Вдумчиво.
Вы в курсе про чайник Рассела? Надеюсь да, и тогда я жду продолжения. Меня настолько часто обвиняют в некомпетентности, что я даже сопротивляться не буду. Но, думаю, что если б хоть у кого-то был ARM достаточно производительный, чтоб потеснить современный Intel и об этом можно было бы писать не боясь судебных исков, то все бы давно гудели. А так быстрее, но со звёздочкой (на отдельных задачах). И именно понимание архитектуры и процессора как такового и системы в целом и позволяет мне предполагать с хорошей долей уверенности что таковое в принципе невозможно. Если конечно не сравнивать ультра современный ARM с допотопным Intel. Но тогда мой браслет на порядки производительные суперкомпьютеров прошлого. И да, напоминаю про чайник (и жду продолжения).
Хм… Понимаете какое дело. Мне, как человеку который уже не один десяток лет занимается адаптацией загрузчиков и ядра Linux под разные камни (включая те, на которых ни одно ни другое даже не поддерживается) безусловно стоит расширять кругозор. И конечно мне не надо объяснять элементарные вещи. Хотя не скрою — я очень люблю послушать как именно их объясняют. Очень много сразу становится понятно о человеке. Насколько глубоко он в теме, по каким «учебникам» учился. Потому позволю себе встречный совет вам: вечно расширять кругозор не получится. Мир меняется сильно быстрее, чем вы об этом успеваете даже прочесть. Потому выберите уже тему, в которой вам будет интересно и копайте вглубь. Нет ничего страшного в том, что не знаешь всего.
Про остальное. Ну хорошо, будем считать что я согласился. Мне спорить с редакторами www.anandtech.com совсем не хочется. А не верить им безоговорочно — это мое право. Как и право сомневаться в кроссплатформенных тестах. Даже подсчет хешей или расcчет числа Pi (казалось бы чисто вычислительные задачи) не дают четкого результата.
Потому просто повторю основную идею — ждем. Ждем цен. Ждем реальных оценок (что бы это не значило). Будет любопытно если десктопный ARM от Apple окажется быстрее серверного 1,5-годичной давности. Впрочем, сильно такому раскладу я не удивлюсь.
Может быть. А может быть просто не пытаюсь использовать карьерный Белаз для ежедневных поездок на работу через центр города-миллионника. И тем более не пытаюсь найти оправдания того для чего я этим мог бы заниматься. А межу поршом и приорой общего сильно больше чем кажется. И уж точно нельзя познать особенности реализация порша не зная как работает приора или любой ее импортный аналог (если на отечественные авто стойкая аллергия).
Поправка про SPARC засчитана. Виноват. Все остальное для меня требует пояснения. То что вы пишите или слишком умно и сильно опережает мои знания, или… ровно наоборот (буду политкорректен). Я не понял про Intel и AMD. История этих компаний слишком на слуху для того чтоб так безапеляционно заявлять что их роднит только набор инструкций и так было всегда. Да и методика зарабатывания денег компанией ARM мне представляется несколько по другому.
Шины и кеши — это мое. Это я должен понимать за счет чего достигается такая производительность и где ждать подводных камней таких решений (понимать границы применимости). Согласен, пользователю это не очень интересно (если вообще интересно). И в этом плане тот же браузер не всегда показателен. Страница для iPad и для десктопа могут оказаться очень разными, даже рекламой разной и по разному напичканными. Одно это может вносить существенные искажения в восприятие скорости работы. Потому давайте я соглашусь с любой позицией. Говорите ARM от Apple в однопоточном режиме быстрее Intel'а — ОК, пусть будет так. Говорите что у Apple самая быстрая реализация AArm64 — не вопрос. Время рассудит что тут правда, а что вымысел и подгон под требуемый ответ.
Ось почти всегда Linux. Железо — встраиваемые железки с arm-v7a, arm-v8 (последнее время от Freescale). Это наша целевая платформа. Пробовал железки и от NVidia (для нас избыточны) и от более «приземленных» производителей (ST Microelectronics, Atmel). Да, выборка не очень презентативна в части производительности, но я и сравниваю их отзывчивость не с Xenon'ами. Скоре с Atom'ами и Celeron'ами. Что до «нет ощущения тормозов» — так на том что делаем мы тоже нет ощущения тормозов. Иначе бы железки наши не покупали. Не путайте пользовательский опыт и ощущения разработчика. Я знаю о своем изделии сильно больше, чем конечный пользователь. Так что верю — нет ощущения тормозов и славненько. Я буду очень рад оказаться не правым и пересмотреть свои взгляды. Ждем.
Clang, к примеру, на телефоне Apple я не запускал. У меня из Apple есть только macOs на хакинтоше. Потому действительно сказать ничего не могу. Но взялись писать — пишите. Что компилирует Clang на смартфоне и x86 (и который из них самый топовый, участвующий в сравнении)? Они производят один и тот же бинарь или разные? Где вообще описание данного теста?
Ну, а то что Apple может «вытягивать» из ARM максимум, так это хорошо. Но я сомневаюсь что на реальных задачах там будут «разы». Хотя… Вспоминая как вел себя ARM-v7 с 16-разрядной шиной памяти в сравнении с тем же ядром, но 32-разрядной шиной могу сказать что все возможно. Ждем. Пока просто ждем.
А вот про «не те процессоры» я не понял. Упомянутый A12Z основан на ядре ARMv8-A. Вполне понятно чего от ждать просто ориентируясь на построенные на близкородственных ядрах AARM64. Разве нет?
Вообще сегодняшняя ситуация вокруг ARM до боли похожа на ситуацию с SPARK и SUN. Те тоже пытались подвинуть Intel как минимум на серверном рынке. Конечно, сейчас ARM сильно популярнее чем когда-то SPARK. Где сейчас тот SUN и тот SPARK? А очень похоже по ощущениям от работы с консолью.
И да, я не то что не против. Я за. Я жду цен. И имею (слабую) надежду на то, что какой-нить mac-mini с ARM появится у меня на столе. До тех пор любые разговоры это просто гадание на кофейной гуще. Я мои посты целиком и полностью основаны на собственном опыте работы с Linux на ARM (как 32-, так и 64-разрядных). Пока ощущение такое — жить можно, но только так. Большинство пользовательских задач (игры, видео, музыка, обработка видео) вполне себе выполнимы. А вот разработчиковские (та же компиляция) — одна сплошная боль. И вылечить эту боль может только очень серьезная многоядерность. Но и тут надо помнить про «корень из N» и весьма серьезное усложнение чипа. Потому повторюсь — попкорн запасен. А там посмотрим что за кино получится. Не удивлюсь ни комедии, ни триллеру.
Давайте так. Я не могу спорить с маркетологами. Как говорится «в рекламе вкусно показать можно что угодно». Но первое впечатление любого, кто садится за ARM после любого x86 (даже Atom'а не к ночи будь помянут) — это ощущение тормозной консоли. Все системные утилиты, рассчитанные на работу в однопоточном режиме выполняются сильно дольше привычного времени. Я не работал с «серверными» решениями. Есть такой, но у меня к нему доступа нет за ненадобностью — мне кросс-компиляция больше нравится. И в первую очередь ровно потому, что кросс-компиляция выполняется сильно быстрее, чем нативная. Потому мой собственный опыт и только. Однако, не думаю что Apple будет ставить в свои десктопы серверные ARM'овские решения на полсотни ядер. Но посмотрим.
Про ошибки в компиляторах и уровни оптимизации. Тот же компилятор С от Sun позволял себе оптимизировать даже ассемблерные вставки. Крайне сомнительная функциональность, которая к счастью отключалась. Вообще я бы поспорил с утверждением «от языка не сильно зависит». Зависит довольно серьезно. Чем проще «внутренний мир» языка, тем меньше простора для оптимизции. Тот же С сам по себе прост. Его за то и любят. По сути его «внутренний мир» эквивалентен «внутреннему миру» практически любого современного процессора. И именно по этой причине не все можно пихать в switch() и в нем настолько неудобная работа со строками. Это обратная сторона переносимости. Да и потом — всем котроллерщикам известна простая истинна — самый большой уровень оптимизации совсем не значит самый лучший. Все ответственные места просто необходимо проверять на ассемблере. Благо JTAG/SWD с современными IDE это позволяют без утомительного изучения промежуточного ассемблера как это было некоторое время назад. И да, очень часто приходится бороться с «шибко умным» компилятором. Впрочем, как правило код пишется так что его уму особо разгуляться негде.
Хотя надо еще посмотреть что будет получаться на выходе у того же Rust'а когда код на нем не будет содержать unsafe блоков (за что ратуют фанаты Rust, и без чего он превращается просто в очередной диалект С/С++).
Но жизнь забавно поворачивается. Два моих учителя спорили о том, что лучше С или ассемблер. Один кричал: «ты на асме пишешь как на С — у тебя сплошные макросы», второй отвечал: «за то указателями я кручу куда как более виртуозно и производительно». Первый парировал: «а вот о сохранении регистров и целостности стека я даже не думаю, да и в критических местах ассемблерные вставки никто не запрещал». И не было числа тем спорам. А сейчас вот уже и С с пьедестала низкоуровневого языка двигают. Сначала Java замахнулась, но не смогла. Теперь вот то Rust, то С++. И ведь подвинут. Вопрос только кто именно. И, самое главное, на что мне на старости лет переучиваться придется. И нужен ли я буду хоть кому-то со своим С, как нужны сейчас спецы по коболу (и частично фортрану).
Но это черт возьми риторика. И комментарий здесь оставил ровно за тем, чтоб не возникало мысли о том, что в принципе без указателей обойтись можно. Нельзя. Вопрос только в том кто ими рулить будет — разработчик ПО или разработчик компилятора. И с кого спрашивать будут. Ошибка работы с указателями когда она в исполнении разработчика ПО — это всего лишь ошибка. Неприятно. Временами даже смертельно, но это можно исправить. А вот та же ошибка в компиляторе сильно более опасна. Так кто и как будет контролировать контролеров? Вот те мысли, которые крутятся в моей голове.
Но все равно пишите. Вас приятно читать. Мне плюсы не сильно знакомы, но пока вроде ничего неподьемного нет. Мало ли пригодится где. И еще раз — статья просто шикарна.
Одно жаль — почему-то с телефона комметарий не пошел, потому пишу как только смог добраться до компьютера. Не буду про студентов — опять ветка не туда уйдет. А вот про указатели таки скажу. Мне кажется, что задача отказа от указателей (как минимум применительно к данной задаче) — она фантомная. И фантомно же решена. В том смысле, что указатели никуда не делись. Просто код написан так, что операции с ними явно не упоминаются. Вам удалось сделать это просто классно. Снимаю шляпу. Но в целом — не кажется Вам что это несколько… хм… неправильно. Архитектурно процессор оперирует указателями. Вся адресная арифметика это именно они. И если мы пишем код непосредственно на нем исполняющися, то… по мне знание и понимание адресной арифметики один из краеугольных камней. Ладно, когда речь идет о Java, Python или ком-то подобном. Но С/С++? Да по голому железу. В конце-концов PC и SP тоже указатели…
В любом случае спасибо за ссылку.
Впрочем, я не припомню упоминаний о перекисе в вузовском учебнике по физиологии растений. Но надо будет перелистать на досуге.
Еще раз спасибо. Увы, я читатель — потому кроме как комментарием никак поблагодарить не могу.