Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 304
При существующей архитектуре армы не догонят x86 даже если доползут до 2-3ГГц по частоте. Если мы посмотрим на то количество титанических усилий, которое было вдыхано в этот убогий процессор из клавиатур (4004), чтобы получить современную скорость работы, то увидим, что арму нужны какие-то нереальные подвиги для этого.
А ведь у интела в закромах есть что-то более крутое, чем «быстрая математика». Это быстрый ввод-вывод, позволяющий получать от переферии десятки гигабайт данных в секунду (я не преувеличиваю — на JBOD массивах с direct attach можно смело видеть цифры порядка 3-5ГБ/с с одного HBA, а таких HBA может быть по числу слотов, то есть, теоретически, можно иметь скорость ввода-вывода, приближающуюся к скорости оперативной памяти). Причём речь идёт не только о байтах, но и о скорости операций, то есть, например, сети, которая может выдавать скорость среды на 10G на любых пакетах и показывать что-то очень крутое на 40G.
Кто-то может подумать «ну и нафига это», но скорость ИО — это то, из-за чего тормозит большинство мобильных устройств сейчас (а вовсе не из-за raw computing power). А в эпоху злых SSD, где 100-200кIOPS в одну глотку это уже реальность, а 50к ввобще стоит приемлимых денег, каждая запятая на пути IO — это проигрыш в субъективной скорости всей железки.
То есть «поджать интел на атомах» они могут (но, нафига это эппл?), а вот пихнуть в десктопы — сомневаюсь. Уж скорее эппл выпустит какой-нибудь «суперэйр», который займёт нишу неттопов, то есть «медленее эйра, но живёт дольше и в полтора раза быстрее».
А ведь у интела в закромах есть что-то более крутое, чем «быстрая математика». Это быстрый ввод-вывод, позволяющий получать от переферии десятки гигабайт данных в секунду (я не преувеличиваю — на JBOD массивах с direct attach можно смело видеть цифры порядка 3-5ГБ/с с одного HBA, а таких HBA может быть по числу слотов, то есть, теоретически, можно иметь скорость ввода-вывода, приближающуюся к скорости оперативной памяти). Причём речь идёт не только о байтах, но и о скорости операций, то есть, например, сети, которая может выдавать скорость среды на 10G на любых пакетах и показывать что-то очень крутое на 40G.
Кто-то может подумать «ну и нафига это», но скорость ИО — это то, из-за чего тормозит большинство мобильных устройств сейчас (а вовсе не из-за raw computing power). А в эпоху злых SSD, где 100-200кIOPS в одну глотку это уже реальность, а 50к ввобще стоит приемлимых денег, каждая запятая на пути IO — это проигрыш в субъективной скорости всей железки.
То есть «поджать интел на атомах» они могут (но, нафига это эппл?), а вот пихнуть в десктопы — сомневаюсь. Уж скорее эппл выпустит какой-нибудь «суперэйр», который займёт нишу неттопов, то есть «медленее эйра, но живёт дольше и в полтора раза быстрее».
Ну может быть, я не настаиваю на своём мнении.
Но слухи-то ведь ходят — см.: «Bloomberg: Apple обдумывает перевести Mac с процессоров Intel на собственные чипы» — нету дыма без огня:)
Да и по поводу всякого быстрого ввода-вывода в Apple тоже ведь не дремлют — вы я надеюсь в курсе, что технологию Thunderbolt разработала Apple совместно с Intel — см: Thunderbolt на сайте Apple.
И первоначально торговая марка Thunderbolt была зарегистрирована Apple, но позже была передана к Intel.
Но слухи-то ведь ходят — см.: «Bloomberg: Apple обдумывает перевести Mac с процессоров Intel на собственные чипы» — нету дыма без огня:)
Да и по поводу всякого быстрого ввода-вывода в Apple тоже ведь не дремлют — вы я надеюсь в курсе, что технологию Thunderbolt разработала Apple совместно с Intel — см: Thunderbolt на сайте Apple.
И первоначально торговая марка Thunderbolt была зарегистрирована Apple, но позже была передана к Intel.
И thunderbolt проиграл usb 3
Это миф и заблуждение — такое же как и заблуждение, что Firewire якобы проиграл USB. Ни Firewire, ни уж тем более Thunderbolt никогда и не собирались конкурировать с USB — это совсем разные интерфейсы для совсем разных применений. Никто в своем уме не предлагал подключать в Thunderbolt вебкамеры, мышки, клавиатуры и прочую легковесную периферию.
зачем всей перечисленной вами периферии скорости usb 3.0? значится, там где скорости пересекаются, всё-таки конкуренция на лицо. Плюс к тому, почему Intel так долго не внедряла поддержку usb 3.0 в свою чипсеты? не связано ли это с желанием продвинуть thunderbolt, хоть и в первой, медной версии?
Вообще-то в USB 3.0 не только пропускная способность выше чем у USB 2.0, но лучше показатели latency & jitter. Впрочем для нормальных аудио устройств все так же не подходит, а вот вэбкамерам и внешним винтам (винтам, не а не наворочем data bank'ам которые по thunderbolt запитываются) пойдет как раз. Это как конкуренция MS Paint и Photoshop.
а у меня — дурака внешняя usb карта за 9к 24 битная — а оказывается не подходит…
У меня Pioneer DDJ-SX — вполне себе роялит одновременно как MIDI/HID и ASIO. И там 24-битный DAC с подавлением джиттера. Латентность же порта заведомо меньше, чем буффер ASIO, который зависит от производительности компа и операционки (извините, но Mac OS тут почему-то круче винды).
С ноутбуком трехлетней давности буффер стоит 5 ms. и это на порядки больше латентности порта, при этом совершенно незаметно по отзывчивости.
Но это резкий как понос ASIO. Если же аудиоустройство работает как MIME / DirectX — то буффер может доходить до 100 ms., что означает лишь задержку между нажатием Play и началом звучания музыки из динамиков, джиттер же зависит больше от DAC и тактового генератора на материнке, но даже с пологим фронтом/спадом сигнала научились бороться.
Вообще, страх джиттера — это навязанный аудиофилами миф.
Если у вас один канал (одно оконечное устройство, один DAC) — вам абсолютно по барабану джиттер. Джиттер страшен при многоканальном применении, когда у вас всё заводится в микшерский пульт и вы работаете одновременно с >4 каналов с разных устройств которые синхронизируются по MIDI-clock при этом в тракте проходят через различные аудиопроцессоры и эффекторы с DAC/ADC преобразованиями, и тогда уже джиттер накапливается так, что случается фазовая рассинхронизация между каналами — но это уже заморочки у звукорежиссеров, есть специальный вид осциллограмм для контроля этой неприятности.
В домашнем же применении про джиттер и латентность можно совершенно не заморачиваться.
С ноутбуком трехлетней давности буффер стоит 5 ms. и это на порядки больше латентности порта, при этом совершенно незаметно по отзывчивости.
Но это резкий как понос ASIO. Если же аудиоустройство работает как MIME / DirectX — то буффер может доходить до 100 ms., что означает лишь задержку между нажатием Play и началом звучания музыки из динамиков, джиттер же зависит больше от DAC и тактового генератора на материнке, но даже с пологим фронтом/спадом сигнала научились бороться.
Вообще, страх джиттера — это навязанный аудиофилами миф.
Если у вас один канал (одно оконечное устройство, один DAC) — вам абсолютно по барабану джиттер. Джиттер страшен при многоканальном применении, когда у вас всё заводится в микшерский пульт и вы работаете одновременно с >4 каналов с разных устройств которые синхронизируются по MIDI-clock при этом в тракте проходят через различные аудиопроцессоры и эффекторы с DAC/ADC преобразованиями, и тогда уже джиттер накапливается так, что случается фазовая рассинхронизация между каналами — но это уже заморочки у звукорежиссеров, есть специальный вид осциллограмм для контроля этой неприятности.
В домашнем же применении про джиттер и латентность можно совершенно не заморачиваться.
Latency у USB 2.0 порядка единиц миллисекунд, чего за глаза хватит и для аудио, и, тем более, для вебкамер. Опять-таки, как обладатель usb-аудиоинтерфейса заявляю, что никаких задержек не ощущается.
USB стал так популярен именно из-за меди и адекватной в своей нише скорости, к тому же 5В идёт вместе с данными, не нужно беспокоиться насчёт индивидуального источника питания для каждого устройства.
Thunderbolt скорее для другого — HD-видео + внешние накопители. Уже существуют проекты внешних видеокарт (sic!) подключаемых по Thunderbolt (Sony Vaio Z21 и Power Media Dock). Вообще Thunderbolt — это ничто иное как гибрид кабельного PCIe и DisplayPort. 10Гбит/с по каждому интерфейсу дают суммарные 20 (для первой версии интерфейса).
Вообще лучше держаться на меди пока это возможно. Питание в линии это хорошо (только если прожорливость подключаемых устройств значительно не вырастет), плюс это дешевле — обслуживание, медные кабели vs оптоволокно, обычный разъём vs терминатор…
Thunderbolt скорее для другого — HD-видео + внешние накопители. Уже существуют проекты внешних видеокарт (sic!) подключаемых по Thunderbolt (Sony Vaio Z21 и Power Media Dock). Вообще Thunderbolt — это ничто иное как гибрид кабельного PCIe и DisplayPort. 10Гбит/с по каждому интерфейсу дают суммарные 20 (для первой версии интерфейса).
Вообще лучше держаться на меди пока это возможно. Питание в линии это хорошо (только если прожорливость подключаемых устройств значительно не вырастет), плюс это дешевле — обслуживание, медные кабели vs оптоволокно, обычный разъём vs терминатор…
Если мы посмотрим на то количество титанических усилий, которое было вдыхано в этот убогий процессор из клавиатур (4004), чтобы получить
современную скорость работы, то увидим, что арму нужны какие-то нереальные подвиги для этого.
Поржал. Тоже самое можно сказать и про x86 без всяких проблем и вместо 4004 написать 8086. И да что ARM что Intel базируются на RISC архитектуре. Только вот в отличии от x86 у ARM нет еще слоя трансляции CISC->RISC и много внимания уделяется энергоэффективности. В итоге производительность на ватт x86 проигрывает ARM с треском. Intel уже несколько лет подряд пыжится догнать ARM по энергоэффективности. И все еще не догнала, так-как эти подлые люди каждый раз выпускают новое поколение :]
Вопрос вроде бы стоял о десктопах, а не о калькуляторах… А на десктопах вопрос энергоэффективности — последнее дело.
Извините вы можете рассказать зачем вам на десктопе большая мощность процессора?
Для разработки, например.
Играть в компьютерный игры, смотреть видео, греть комнату.
Играть в компьютерные игры можно уже и на планшете. Качество графики больше зависит от GPU чем от CPU
Качество 3-D графики и от CPU тоже порой сильно зависит.
Например очень модный физический движок Havok — до сих пор использует исключительно мощности CPU!
Да, когда Havok была независимой компанией, то они разрабатывали новый движок Havok FX, который должен был использовать мощности GPU от ATI и NVIDIA для физических расчётов, но продукт был заморожен после того, как в 2007 году Intel купила Havok — см.: «Intel покупает Havok — разработчика ПО для трехмерного моделирования»:(
Например очень модный физический движок Havok — до сих пор использует исключительно мощности CPU!
Да, когда Havok была независимой компанией, то они разрабатывали новый движок Havok FX, который должен был использовать мощности GPU от ATI и NVIDIA для физических расчётов, но продукт был заморожен после того, как в 2007 году Intel купила Havok — см.: «Intel покупает Havok — разработчика ПО для трехмерного моделирования»:(
На планшете можно играть в каких-нибудь Angry Birds. Для Quake II (управление) или «Сталкера» (графика, физика) все-таки пока лучше привычная писишка.
Если CPU слишком слаб, то GPU будет нечем заняться ибо ему никто не передает данных с достаточной скоростью.
десктопы вроде как стремительно усыхают. вместо них интел двигает свой NUC. а у эпл есть мак мини. и аймак в котором непонятно от чего больше от ноута или от десктопа.
Фингню не говорите. Сравнивать CISC с Trumb полный бред. В случае CISC у вас больше команд транслируются в меньшее количество. В случае же Trumb меньше команд транслируется в большее и да в случае CISC вы не можете использовать RISC так-как это просто банально не доступно. Так же отмечу что трансляция из Trumb -> ARM существенно меньше жрет ресурсов нежели CISC -> RISC. Внимательно почитайте еще зачем был сделан Trumb.
И давно у нас в CISC одна команда?
А сколько?
Зависит от процессора.
Приведите тогда количество x86 команд и количество микроопераций, в которые они транслируются.
Может сходите сами почитаете? У вас только одна команда CISC транслируется в три команды RISC. А фактически одна команда CISC может транслироваться не в один десяток команд RISC. Это требует выполнения микрокода. В случае же RISC этого микрокод для исполнения команды не требуется.
Вам там уже дали ниже ответ. У нас в случае CISC больший набор команд. Эта команда далее перед ее выполнением транслируется в меньший набор команд, но с увеличением их количества. Была одна команда стало три, была одна команда стало 20 и т.п. Какими фактами это мне надо подтвердить? Дать ссылку на википедию где про это написано? В случае Trumb у вас это не так. Процитирую
Просто по таблице подставляется команда. А не транслируется в большее количество команд.
режим процессоров ARM, в котором используется сокращенная система команд. Она состоит из 36 команд, взятых из стандартного набора 32-разрядных команд архитектуры ARM и преобразованных до 16-разрядных кодов.
Длина команд Thumb составляет половину длины стандартных 32-разрядных команд, что позволяет существенно сократить необходимые объёмы памяти программ (порядка 30 %) и, кроме того, позволяет использовать более дешёвую 16-разрядную память.
При выполнении эти команды дешифруются процессором в эквивалентные операции ARM, выполняемые за то же количество тактов.
Просто по таблице подставляется команда. А не транслируется в большее количество команд.
Википедию я так понимаю не осилили?
ru.wikipedia.org/wiki/CISC
Тут указано с какого процессора x86 стал внутри RISC с транслятором CISC в RISC.
ru.wikipedia.org/wiki/CISC
Наиболее распространённая архитектура современных настольных, серверных и мобильных процессоров построена по архитектуре Intel x86 (или х86-64 в случае 64-разрядных процессоров). Формально, все х86-процессоры являлись CISC-процессорами, однако новые процессоры, начиная с Intel Pentium Pro, являются CISC-процессорами с RISC-ядром. Они непосредственно перед исполнением преобразуют CISC-инструкции процессоров x86 в более простой набор внутренних инструкций RISC.
В микропроцессор встраивается аппаратный транслятор, превращающий команды x86 в команды внутреннего RISC-процессора. При этом одна команда x86 может порождать несколько RISC-команд (в случае процессоров типа P6 — до четырёх RISC-команд в большинстве случаев). Исполнение команд происходит на суперскалярном конвейере одновременно по несколько штук.
Это потребовалось для увеличения скорости обработки CISC-команд, так как известно, что любой CISC-процессор уступает RISC-процессорам по количеству выполняемых операций в секунду. В итоге, такой подход и позволил поднять производительность CPU.
Тут указано с какого процессора x86 стал внутри RISC с транслятором CISC в RISC.
Можете пояснить что именно даст вам знание количества CISC команд у процессора x86 и количество RISC команд после транслятора? Вы вообще разницу архитектур CISC и RISC понимаете?
набор внутренних инструкций может быть как больше, так и меньше от исходного
Давайте я вам встречный вопрос задам? Если набор RISC конструкций больше чем CISC то зачем транслятор CISC->RISC? Проще тогда сразу CISC процессор без транслятора в RISC делать. Общая идея CISC типа у нас больше команд процессора, программисту проще писать программы. Общая идея RISC у нас проще процессор и меньше команд, по этой причине они выполняются быстрее, но муторнее писать команды.
Пример из прошлого. В CISC есть умножение, которое отсутсвует в RISC (лет 10 назад так было). Так вот, умножение транслируется в кучу сложений и сдвигов. Количество операций увеличилось (вместо одного действия несколько), но множество (математическое) команд сократилось.
Эм какие временные переменные? Вы о чем? Вы вообще знаете как простейший АЛУ работает?
Множетво алгоритмических команд. Мы же не называем командой служебный синхросигнал на шине.
add [ebx+edi], eax
Тут записано сразу несколько действий. Под копотом процессора сначала вычислится сумма регистров, по получившемуся адресу загрузятся данные в безымянный регистр, прибавится eax и выгрузится обратно по адресу.
Со стороны CISC это выглядит элементарно. Но процессор не может оперировать ячейками памяти. Её нужно считать в безымянный регистр, выполнить действие, выгрузить обратно. Все эти действия скрыты за одной командой CISC, о которой RISC ничего и не слышал.
Я так понимаю вы знаете ассемблер? Вы в курсе что процессор используя эти команды работает совсем по другому? И что фактически под RISC тут кода будет поболее.
Вы видимо тоже не уловили суть. Трансляция идет из CISC ISA -> RISC ISA, а уже далее в то что вы называете микро операциями. И в случае RISC множество команд меньше чем в CISC. Фактически одна команда в CISC может быть целой процедурой в RISC, так-как команды проще.
В смысле? У x86 есть промежуточный набор команд между macro-ops и micro-ops? Почему вы так решили?
В x86 начиная с Pentium Pro CISC ISA транслируется в RISC ISA. Дальше команда из RISC ISA выполняется процессором. И RISC не настолько примитивен как вы думаете. Он близок к CISC ISA но беднее из-за этого там где у CISC выполняется одна команда в RISC их будет больше.
Ну ни откуда это не следует, что множество команд CISC больше множества команд micro-ops.
Следует. Вы вообще понимаете в чем идея RISC? Сделать более простые команды которые быстро выполняются процессором. В случае CISC идея сделать больше команд которые процессором могут выполнятся дольше, но зато проще программировать. Теперь поясните почему множество команд RISC должно быть больше чем в CISC если сам по своей идее в RISC должны команды быть простые и более примитивными? Потому что примитивные поэтому их больше? Тогда смысла делать транслятор CISC -> RISC нет никакого.
Пример: в языке c++ есть примерно 60 операторов (аналог CISC). Программа на C++ компилируется в x86 код, в котором примерно (не менее) 120 операторов (аналог micro-ops). Здесь множество «micro-ops» больше, чем множество «CISC».
Для начала в языке C++ операторов не 60 штук. Я в любой момент могу определить свой оператор. Во вторых сам по себе язык и его конструкции существенно богаче ассемблера и более высокоуровневый. Проще говоря в C++ я пишу std:out << «Hello world», а на выходе получается портянка x86 кода. В случае CISC тоже самое.
Ну так эти «RISC ISA» и есть micro-ops, я их называю micro-ops, а не «что-то дальше».
Что в вашем понимании micro-ops?
Не следует. Для этого просто нужно вспомнить смысл этой трансляции — скорость работы (а не удобство программирования и простота процессора). Была бы не нужна скорость — оставили бы исполнитель команд как есть. Если добавление избыточной команды в набор micro-ops увеличит скорость, несмотря на то, что она будет избыточной — ее добавят.
Добавление в процессор дополнительной команды это усложнение процессора и добавление транзисторов. По этой причине в RISC стараются закладывать как можно меньше команд и оптимизировать выполнение каждой команды, а не добавлять команды на каждый чих. В этом и смысл трансляции CISC в RISC внутри x86 процессора. Тем кто делает процессоры проще оптимизировать RISC процессор нежели CISC.
Это будет суть оператор (), не более.
Особенно если я перегружу операцию сложения для сложения матриц.
См. en.wikipedia.org/wiki/Micro-operation
RISC этим не является. Т.е. сначала идет CISC -> RISC далее micro-operation
Только цель этого — повышение производительности процессора. Набор команд micro-ops формируется с целью быстрой работы, а не простоты архитектуры.
Фишка в том что RISC в который идет трансляция CISC это не micro-operation. Вы что действительно думаете что под ARM кто-то пишет на micro-operation?
Происходит трансляция команд в наборы micro-ops (µops).
То что вы называете micro-ops это RISC команды. Тут возражений нет?
Под формулировкой RISC скрывается то что написано. Это вообще идеология построения процессора и не более того. И там основное требование чтобы команда выполнялась быстро и была проста в реализации. И если внезапно RISC команд больше чем CISC команд, то это овчинка выделки не стоит. Так-как тогда проще сразу реализовывать CISC и не парится с всей этой трансляцией в RISC.
Если и то и то выполняется за один такт то в целом не мешает. Опять OUT позволяет сделать за одно действие то что для ST потребует не одно действие.
OUT пишет в порт ввода вывода, а ST в память. То что сейчас при его помощи можно записать туда же куда пишет OUT ни о чем не говорит. Может быть реализация когда порты хранятся в отдельном своем пространстве и с памятью не пересекаются.
В смысле не надо фантазировать? Я сходил и почитал разницу команд. Если команды заложили именно в таком виде, то я допускаю что предполагалось что пространство портов может быть отдельным. Если потом внезапно товарищи передумали, то уже другой вопрос. А так к примеру они могут избавиться от того что в разных моделях пространство портов находится в разных областях памяти. Так что тут все хорошо и я не вижу никакой избыточности. Первая команда пишет в порт, вторая команда пишет в память. Если разрботчик в следующей реализации процессора ВНЕЗАПНО поменяет адресное пространство куда отображаются порты, то в случае OUT ничего не сломается. В случае же ST сломается еще как.
Нет. В том что OUT пишет в пространство портов. И это пространство может быть не в этом диапазоне на другом контроллере. Из-за наличия OUT я могу писать переносимый код. RISC подразумевает разумный минимальный объем команд, а не максимально минимальный. Максимально минимальный уже существует это машина тьюринга.
OUT не захватывает все пространство «портов», поэтому для доступа к портам вне этого пространства требуется использовать ST.
На тот момент когда инструкцию добавляли, захватывало.
Ха-ха-ха. «Разумный» — это субъективное понятие.
Конечно. Я даже знаю кто эти субъекты в AVR, это разработчики. RISC это не четкая догма, это набор идей как сделать процессор удобным и для разработчика процессора и для тех кто пишет под него ПО. Не более. CISC точно такой же набор идей.
Ничего что там указанны совсем разные процессоры и разного времени выпуска? А у нас тут речь идет о том что RISC внутри x86 CISC меньше по количеству команд чем CISC. Это просто следует из того что из идей заложенных в CISC и RISC.
Даже в названии да? Вообще говоря поясните смысл делать больше операций в RISC чем в CISC? В чем смысл? Чтобы каждую CISC команду своим уникальным набором RISC команд описывать? И чтобы те кто пишет реализацию пользовались гигантской таблицей и искали какую же тут функцию использовать? И как вы собираетесь с этим всем реализовывать суперскалярность?
Знаете у меня ощущение что на лицо проблема терминологии и того что происходит в процессоре. Давайте для начала уточню. Вот у нас есть CISC ISA в случае x86 начиная с Pentium Pro CISC ISA транслируется при помощи микрокода в RISC ISA что является более простыми командами. К примеру команда переместить из ячейки памяти в другую ячейку памяти развернется в операцию взять из памяти в регистр и далее положить из регистра в память. Есть возражения?
Простота — это субъективное понятие. Это мое главное возражение.
Что значит субъективное? Там вполне четкое понятие есть в случае RISC команда выполняется за один такт.
Могу предположить, что набор micro-ops похож на набор 40-битных инструкций Itanium.
Itanum вообще VLIW
Про это вам уже ниже отвечали. ARM RISC
Потому что кому-то это было надо. Вы еще скажите что FPU Neon делает ARM процессор не RISC.
Это оптимизация того же характера что и свертывание циклов компилятором и происходит при анализе поступающего CISC кода.
А я где-то говорил что они есть? Вообще говоря если вернутся к вашему же примеру по C++ то у вас будет так же оператор в ассемблере которого нет по вашим же словам в C++. У вас множество RISC команд и не должно собственно обязательно иметь все аналоги команд в CISC. Но при этом RISC команд меньше чем CISC и они простые. Иначе смысла особо нет в трансляции CISC в RISC.
еще раз говорю вам проблема терминологии. Хоть ужом назовите. Смысл в том что с Pentium Pro вместо своего особенного пути в micro-ops в качестве основы был выбран RISC. За счет этого Intel стало проще делать процессор. То что оно не документируется это не говорит, что он от этого не становится не RISC. И опять же в случае выбора RISC разумнее делать там меньше команд чем в CISC, а недостающие команды реализовывать в виде микрокода на базе RISC, а не делать элементарный чих отдельную команду.
Т.е. там уменьшилось число транзисторов, или что? Где упрощение?
Упрощение в базовых блоках. К примеру за счет этого стало возможно реализовать суперскалярность.
Кому интересны упрощения в базовых блоках (если они есть), есть сложность процессора в целом возрастает?
Разработчикам процессора. Начинает работать принцип черного ящика.
Вы что многоуровневые системы не делали? Делаем сначала простые блоки потом из них собираем сложную систему. Это работает и в случае процессоров.
> больше команд транслируются в меньшее количество
Речь шла именно про набор команд, а не про то что код из Н команд протранслируется в код из К команд где Н больше К — понятно что наоборот.
Набор же команд в RISC по определению меньше чем в CISC — _reduced_ instruction set ведь.
Речь шла именно про набор команд, а не про то что код из Н команд протранслируется в код из К команд где Н больше К — понятно что наоборот.
Набор же команд в RISC по определению меньше чем в CISC — _reduced_ instruction set ведь.
Имелось ввиду большее число наименований команд в меньшее число наименований. Разумеется, при этом абсолютное число команд при трансляции конкретной последовательности возрастает.
Разные.
Потому что nop ничего не делать и к примеру и при этом текущий процессор реально никаких операций проводить не будет, а при указанной xchg воздух процессор погреет.
А вот и не угадали —
По опкоду 0x90+r лежит команда
xchg r, eax,
при r = eax получаем, 0x90, что есть NOP
Короче, NOP, это частный случай xchg
По опкоду 0x90+r лежит команда
xchg r, eax,
при r = eax получаем, 0x90, что есть NOP
Короче, NOP, это частный случай xchg
Хорошо и что это доказывает кроме того что в частном случае мы получаем nop? Мне просто посылка автора вообще не понятна.
Посыл автора был в том, что наименование команды != команда.
Тот же nop это просто наглядный пример: процессору без разницы, напишите ли вы в коде nop или xchg ax, ax, xchg al, al или xchg eax,eax — для него (процессора) это одна команда.
Кстати верно и обратное:
xchg bx,ax и xchg ax,bx — с точки зрения процессора это разные команды.
Тот же nop это просто наглядный пример: процессору без разницы, напишите ли вы в коде nop или xchg ax, ax, xchg al, al или xchg eax,eax — для него (процессора) это одна команда.
Кстати верно и обратное:
xchg bx,ax и xchg ax,bx — с точки зрения процессора это разные команды.
Вообще это частный случай. В большинстве же случаев наименование команды = команда.
Совсем наоборот — для каждой ассемблерной команды есть десяток машинных инструкций. В зависимости от аргументов. Причем, часто не только от типов аргументов (число, память, регистр), но и (в случае с регистровой командой) — от регистра.
Например для некоторых арифметических операций есть «облегченная» инструкция процессора с регистром A.
Например для некоторых арифметических операций есть «облегченная» инструкция процессора с регистром A.
Хорошо. Судя по всему вся путаница возникает из-за слова команда. В моем понимании это не мнемоника ассемблера, а именно машинная команда.
У каждой команды mov регистр, регистр свой код. Вы будете считать их разными командами, или одной? Если разными, то набор команд RISC будет намного больше — там ведь даже константы являются частью кода (правда, я сужу по DSP TI 6xxx, который вообще VLIW, но это ведь частный случай RISC?). А если одной — то надо долго и аккуратно считать все возможные режимы адресаций, автоинкрементов и условных выполнений по всем командам. Подозреваю, что разницы практически не будет, и там и там — несколько сотен. Впрочем, можно просто сравнить длину руководства по ассемблеру RISC и CISC. Кто длиннее — у того и команд больше (в некоем усредненном понимании).
В случае Trumb просто как раз упаковываются не мнемоники ассемблера, а именно машинные инструкции.
Про thumb я с вами полностью согласен — сравнить Thumb режим АРМов с трансляцией CISC->RISC в современных процессорах просто глупо, хотя бы по причине, того, что Thumb есть «еще более Reduced RISC», и соответственно все инструкции Thumb являются полноценными инструкциями RISC и транслировать ничего никуда не нужно.
Стоп, это вы по RISC в целом, а не Thumb->RISC. Если представить, что ядро процессора понимает RISC как есть, то Thumb будет работать без каких-либо трансляций, поскольку является сокращенным набором инструкций того же RISC. Разве что дешифратор команд другой использует.
А если ядро реализует что-то другое, а не инструкции RISC — то без трансляции, конечно же не обойтись.
А если ядро реализует что-то другое, а не инструкции RISC — то без трансляции, конечно же не обойтись.
Чтобы память экономить, а не чтобы плотность кода приближалась к CISC. У CISC вообще-то длина команд не фиксированная, а у Trumb фиксированная по этой причине транслировать Trumb проще. При использовании Trumb у вас как раз размер бинарника под ARM будет меньше чем под x86
У CISC вообще-то длина команд не фиксированная, а у Trumb фиксированная по этой причине транслировать Trumb проще.
У Thumb2 (т.е. начиная с ARMv6) длина переменная (16/32 бита).
16 или 32 бита. Четко зафиксирована. В случае CISC у вас команда может быть любой длины какой вам хочется.
А в 8086 длина инструкции может быть 1, 2, 3, 4, 5 или 6 байтов. Чётко зафиксированная.
Наверное, это был RISC?
Наверное, это был RISC?
У x86 всяких модификаторов полно, и одна и та же инструкция процессора может быть разной длины в зависимости от параметров
Но если за инструкцию принять полный опкод операции (с префиком и модификатором) — то да, длина будет фиксированной. Вот только набор при этом никак не Reduced будет
Но если за инструкцию принять полный опкод операции (с префиком и модификатором) — то да, длина будет фиксированной. Вот только набор при этом никак не Reduced будет
Нет. Thumb2 у вас это метод упаковки кода не более того. Далее перед выполнением он просто в RISC команды по таблицы заменяются и все.
В итоге производительность на ватт x86 проигрывает ARM с треском.Это не так, они примерно на одном уровне плюс-минус.
Интеловские процессоры (за AMD не скажу) пару лет назад выигрывали в high-end-сегменте по производительности на ватт, а в low-power-сегменте у Интела есть Silvermont и даже Haswell, которые по заверениям Интела эффективнее ARM-аналогов. Но и ARM, конечно же, говорят, что их Cortex-A15 эффективнее, чем интеловские Haswell :)
Зависит от того что менять и как. Intel любит синтетику рисовать по энергопотреблению с типа вот тут мы смотрим видео и у нас все
хорошо. По high-end сегмент речи не идет, там обычно вообще ARM неучавствует. Ну и да Intel очень сильно лез из кожи чтобы HP первым для Moonshot выпустил микросервера на Atom, а не на ARM.
хорошо. По high-end сегмент речи не идет, там обычно вообще ARM неучавствует. Ну и да Intel очень сильно лез из кожи чтобы HP первым для Moonshot выпустил микросервера на Atom, а не на ARM.
Можно пруф
С 22 нм техпроцессом это справедливо только для некоторых синтетических тестов, да и тогда теоретически MIPS должен обувать ARM вместе с x86 (хотя это не так).
роизводительность на ватт x86 проигрывает ARM с треском?С 22 нм техпроцессом это справедливо только для некоторых синтетических тестов, да и тогда теоретически MIPS должен обувать ARM вместе с x86 (хотя это не так).
Тут вообще приводили попугаи
E5-2630 — 95 ватт
свежий арм (Qualcomm APQ8064, 1500 МГц) — 1ватт
Итог:
105 попугаев на ватт в случае E5
2200 попугаев на ватт в случае ARM.
Да если будете говорить а вот у Intel есть специализированные решения, то могу сказать что Atom'ы в пределах ватта есть пока чисто фиктивно в основном же Atom даже в виде SoC потребляет 3-4 Ватта. Они там правда новые SoC на 14 нанометров анонсировали. Но тут могу сказать что пожуем увидим. Но пока же как-то у x86 производительность на ватт хуже чем у ARM
E5-2630 (мой рабочий процессор) — 10к попугаев
мой ноутбук (i7-2640M) — 8.6k попугаев.
домашний компьютер 4х-летней давности (core quad) — 6k попугаев
Свежий-свежий арм (цифр на сайте не нашёл, верю вашим) — 2.2k.
E5-2630 — 95 ватт
свежий арм (Qualcomm APQ8064, 1500 МГц) — 1ватт
Итог:
105 попугаев на ватт в случае E5
2200 попугаев на ватт в случае ARM.
Да если будете говорить а вот у Intel есть специализированные решения, то могу сказать что Atom'ы в пределах ватта есть пока чисто фиктивно в основном же Atom даже в виде SoC потребляет 3-4 Ватта. Они там правда новые SoC на 14 нанометров анонсировали. Но тут могу сказать что пожуем увидим. Но пока же как-то у x86 производительность на ватт хуже чем у ARM
Я просил ссылку на пруф. Её не получил. (Более того вменяемой не нашел в гугле).
Не корректное сравнение. Сравниваете оптимизацию по быстродействию с оптимизацией по энергопотреблению. Ко всему прочему непонятный синтетический тест. Поставьте более менее одинаковые условие — и картина меняется.
В начале глупый пример.
galaxy note II vs Asus VivoBook S551LB, выключенный экран, сеть итп. Жаваскрипт код, бесконечно выполняющийся, который ищет оптимальный путь в графе. 30 минут работы, считаем потребление по индикатору батарейки. Потребление у асуса в ~7 раз выше, количиство прощитаных путей в 41,3 раза выше. Получается, что энергоэффективность в почти 6 раз выше. Правильно?
Нет. Я специально попал в максимум кэша, по этому я сравнивал в том числе и пропускную памяти с пропускной кэша. Я уже молчу о том, что сравнивается эффективность выполнения промежуточного кода.
Точно так-же Вы не коректно сравнили.
Для обеспечения роста производительности везде идёт экспоненциальный рост энергопотребления. Это еще одна причина не корректности сравнения. Вспомните гонку за производительность MIPS.
Теоретически ARM должен быть энергоэффективнее. Но на практике это так только в некоторых случаях. Как только реч заходит о высокой производительности на ядро (ведь с этим связана тема), так amd64 рвётся вверх. Ведь у Intel не только тех процесс лучше, и различные обвязки толковее (к примеру связи SMP + cache +DMA). А они компенсируют энергозатраты декодирование инструкций итп. Различные out-of order parallel execution позволяют поднять производительность при сохранении частоты. А именно повышение частоты один из основных факторов роста энергопотребления.
По этих причинах не стоит ожидать высокопроизводительных 64bit ARM SMP решений с >1 процессорами в ближайшие годы.
Не корректное сравнение. Сравниваете оптимизацию по быстродействию с оптимизацией по энергопотреблению. Ко всему прочему непонятный синтетический тест. Поставьте более менее одинаковые условие — и картина меняется.
В начале глупый пример.
galaxy note II vs Asus VivoBook S551LB, выключенный экран, сеть итп. Жаваскрипт код, бесконечно выполняющийся, который ищет оптимальный путь в графе. 30 минут работы, считаем потребление по индикатору батарейки. Потребление у асуса в ~7 раз выше, количиство прощитаных путей в 41,3 раза выше. Получается, что энергоэффективность в почти 6 раз выше. Правильно?
Нет. Я специально попал в максимум кэша, по этому я сравнивал в том числе и пропускную памяти с пропускной кэша. Я уже молчу о том, что сравнивается эффективность выполнения промежуточного кода.
Точно так-же Вы не коректно сравнили.
Для обеспечения роста производительности везде идёт экспоненциальный рост энергопотребления. Это еще одна причина не корректности сравнения. Вспомните гонку за производительность MIPS.
Теоретически ARM должен быть энергоэффективнее. Но на практике это так только в некоторых случаях. Как только реч заходит о высокой производительности на ядро (ведь с этим связана тема), так amd64 рвётся вверх. Ведь у Intel не только тех процесс лучше, и различные обвязки толковее (к примеру связи SMP + cache +DMA). А они компенсируют энергозатраты декодирование инструкций итп. Различные out-of order parallel execution позволяют поднять производительность при сохранении частоты. А именно повышение частоты один из основных факторов роста энергопотребления.
По этих причинах не стоит ожидать высокопроизводительных 64bit ARM SMP решений с >1 процессорами в ближайшие годы.
Ну знаете. Тут еще тогда можно сравнить декодирование ARM чипом при помощи DSP h.264 и декодирование процессором x86 h.264 и сказать что вот у нас x86 очень плохой :] Сравнивать мы можем только синтетику, так-как в реальности еще много чего другого начинает стрелять. По синтетике лучше, как будет в реальной задаче тот еще вопрос.
Thunderbolt — это хитро вывернутый PCI-E, причём довольно малоканальный. Эппл там участвовала, но очень мало, так как с Интелом в понимании ситуации вокруг и знания инсайдерских трендов x86 невозможно, и всю техническую часть делала именно Intel.
Проблема быстрого IO — это очень сложная проблема. Даже такая простая вещь как DMA на высоких скоростях обрастает кучей нюансов (недавно для меня было откровением узнать про существование DCA и DDIO, позволяющие устройству во время операции записи в память обновлять соответствующую cache line на процессоре для снижения latency получения данных (то есть за время цикла DMA устройство не только пишет в память, но и обновляет кеш процессора, так что у того не происходит долгой задержки при чтении из памяти, то есть устройство «работает быстрее»).
Другой пример — MSI-X, система перевода слишком быстро возникающих прерываний в очередь (то есть снижение числа прерываний при высокой нагрузке).
Отдельная возня идёт вокруг балансировки прерываний вокруг нескольких ядер.
Всё это притащить на ARM можно, но у арма свои проблемы (не очень комфортный набор инструкций, идиотизмы в районе управления памятью), и скручивать это «кое как» — опасный путь, а делать на совесть — это очень долгая работа.
Давайте скажем так, я не говорю, что apple не выпустит лаптопа на арме, я говорю, что она в обозримое будущее (допустим, до 2018 года) не переведёт туда свои основные продукты высокой производительности (ака десктопы и pro'шки).
Проблема быстрого IO — это очень сложная проблема. Даже такая простая вещь как DMA на высоких скоростях обрастает кучей нюансов (недавно для меня было откровением узнать про существование DCA и DDIO, позволяющие устройству во время операции записи в память обновлять соответствующую cache line на процессоре для снижения latency получения данных (то есть за время цикла DMA устройство не только пишет в память, но и обновляет кеш процессора, так что у того не происходит долгой задержки при чтении из памяти, то есть устройство «работает быстрее»).
Другой пример — MSI-X, система перевода слишком быстро возникающих прерываний в очередь (то есть снижение числа прерываний при высокой нагрузке).
Отдельная возня идёт вокруг балансировки прерываний вокруг нескольких ядер.
Всё это притащить на ARM можно, но у арма свои проблемы (не очень комфортный набор инструкций, идиотизмы в районе управления памятью), и скручивать это «кое как» — опасный путь, а делать на совесть — это очень долгая работа.
Давайте скажем так, я не говорю, что apple не выпустит лаптопа на арме, я говорю, что она в обозримое будущее (допустим, до 2018 года) не переведёт туда свои основные продукты высокой производительности (ака десктопы и pro'шки).
Согласен:)
Я думаю, что Кук не революционер, а поэтому если и будет переход, то весьма и весьма постепенный.
Конечно я не утверждаю, что завтра же Apple выпустить свои основные ноутбуки 15" и 17" MacBook, а тем более Mac Pro на ARM`ах — нет конечно.
Но вот например что-то типа 13" MacBook Air на ARM-чипе Apple A7 вполне может появится даже и в 2014 году (лично я это допускаю) — конечно с новым названием и не как замена существующим продуктам, а как дополнительный новый продукт совмещающий в себе качества планшета и ноутбука.
Ну и естественно для этого нового продукта Apple придётся поженить или скрестить свою настольную ОСь Apple OS X и мобильную ОСь Apple iOS. И самое интересное, что это постепенно уже происходит, и в каждой новой версии настольной Apple OS X появляется всё больше элементов интерфейса, библиотек и других софтин из мобильной Apple iOS:)
Я думаю, что Кук не революционер, а поэтому если и будет переход, то весьма и весьма постепенный.
Конечно я не утверждаю, что завтра же Apple выпустить свои основные ноутбуки 15" и 17" MacBook, а тем более Mac Pro на ARM`ах — нет конечно.
Но вот например что-то типа 13" MacBook Air на ARM-чипе Apple A7 вполне может появится даже и в 2014 году (лично я это допускаю) — конечно с новым названием и не как замена существующим продуктам, а как дополнительный новый продукт совмещающий в себе качества планшета и ноутбука.
Ну и естественно для этого нового продукта Apple придётся поженить или скрестить свою настольную ОСь Apple OS X и мобильную ОСь Apple iOS. И самое интересное, что это постепенно уже происходит, и в каждой новой версии настольной Apple OS X появляется всё больше элементов интерфейса, библиотек и других софтин из мобильной Apple iOS:)
Не знаю как у вас, но у меня в Nexus 4 в тесте Geekbench 2200 очков. В это время мой ноут на не слабом AMD A10 набирает около 5000. По скорости то оно неплохо работает. К слову, ARM потребляет меньше энергии при той же производительности. Т.е. натыкав кучу процессоров ARM в один кластер можно получить меньшее энергопотребление. Ну и вообще для потребителя на данный момент хватит какого нибудь Snapdragon 800 для браузера на компе, документов, средненьких игрушек, фильмов и т.д.
Вы забываете про мать всех матерей — закон сохранения энергии. Меньшего энергопотребления вы не получите никаким образом на такое же количество работы транзисторов. Работа = Энергия. Энергия = Работа.
Изобретайте какие угодно архитектуры, вы все-равно упретесь в энтропию и этот закон, — может выиграете доли процента на архитектурных решениях, по сравнению с вводом поколений MMX и уменьшением техпроцесса, и все. Специализированные процессоры — лучшее на что способно человечество.
Вы должны тратить Энергию на Работу и порождать Энтропию при этом в виде тепла. Волшебства нет. И будете это делать с примерно одинаковой эффективностью на любых универсальных вычислительных процессорах. На специализированных процессорах вы это можете делать эффективнее, но лишь для узкого круга задач под специализированные процессоры.
Вам нужно вычислить миллиардный знак после запятой в числе Пи? Неважно как быстро это сделают процессоры общего назначения разных архитектур, одни быстрее, другие медленнее — они в итоге потратят примерно одинаковое количество энергии + энтропии. Как много закачаной в вычисление энергии уйдет в энтропию — вопрос в наше время скорее размера техпроцесса, а не архитектуры процессора общего назначения.
Мать всех матерей не дала нам чит-кодов, и блюдет сохранение энергии.
Изобретайте какие угодно архитектуры, вы все-равно упретесь в энтропию и этот закон, — может выиграете доли процента на архитектурных решениях, по сравнению с вводом поколений MMX и уменьшением техпроцесса, и все. Специализированные процессоры — лучшее на что способно человечество.
Вы должны тратить Энергию на Работу и порождать Энтропию при этом в виде тепла. Волшебства нет. И будете это делать с примерно одинаковой эффективностью на любых универсальных вычислительных процессорах. На специализированных процессорах вы это можете делать эффективнее, но лишь для узкого круга задач под специализированные процессоры.
Вам нужно вычислить миллиардный знак после запятой в числе Пи? Неважно как быстро это сделают процессоры общего назначения разных архитектур, одни быстрее, другие медленнее — они в итоге потратят примерно одинаковое количество энергии + энтропии. Как много закачаной в вычисление энергии уйдет в энтропию — вопрос в наше время скорее размера техпроцесса, а не архитектуры процессора общего назначения.
Мать всех матерей не дала нам чит-кодов, и блюдет сохранение энергии.
Что не так с комментом, за что минусы? Есть опровержения? Давайте, обсудим.
Физическая безграмотность. Ограничение на энергопотребление действительно есть, но оно относится к квантовой механике и на много порядков меньше современного тепловыделения. С классической точки зрения, работа с информацией не требует энергии вообще, т. е. КПД всех вычислительных устройств — 0%, вся энергия переходит в бесполезное тепло. Тепловыделение современных чипов определяется неидеальностью транзисторов и сопротивлением металлических соединений.
Не просто на порядки. С теоретической точки зрения, энергии батареи моего телефона 6.11 Wh хватит хватит для обработки примерно 8076668869795109 гибабайт информации. В идеальном случае, конечно :) см. Принцип_Ландауэра
Любопытно, хотя статью о физическом опыте по подтверждению этого принципа читал еще на мембране, я ее даже нашел — www.membrana.ru/particle/17709 Но я не уверен в эквивалентности уничтожения информации и порождения ее.
Поправьте меня.
Приведение квантовой системы в неопределенное состояние из определенного это ведь тоже уменьшение энтропии? и на это тратится энергия. В чем я не прав?
Поправьте меня.
Приведение квантовой системы в неопределенное состояние из определенного это ведь тоже уменьшение энтропии? и на это тратится энергия. В чем я не прав?
Лениво возиться с писиськомерками, беру данные с их сайта:
browser.primatelabs.com/processor-benchmarks (вкладка 64 бита)
E5-2630 (мой рабочий процессор) — 10к попугаев
мой ноутбук (i7-2640M) — 8.6k попугаев.
домашний компьютер 4х-летней давности (core quad) — 6k попугаев
Свежий-свежий арм (цифр на сайте не нашёл, верю вашим) — 2.2k.
Вы чувствуете разницу? 4 года назад интел на среднем десктопном процессоре уделывала текущий арм в 3 раза. Сейчас уделывает в 4 раза. Даже если предположить, что скорость роста производительности у арма будет как была у интела, а у интела остановится (маловероятно) — то потребуется около 12 лет (полуторакратный рост производительности за 4 года, 1.5*1.5*1.5 ~= 8.6/2.2) до момента достижения сравнимой производительности.
Когда вы говорите «для потребителя хватит» вы повторяете нелепую ошибку, которую приписывают Гейтсу (насчёт 640к). Не хватит. И я лично видел совершенно не разбирающихся в компьютерах людей, которые плевались неттопы на атомах, потому что:
* флеш игрушки
* яваскрипт в браузерах на мегабайты
* скорость открытия любимых программ
* отзывчивость интерфейсах в оных
Определяется процессором и скоростью IO. Чтобы выкатить неттоп атом или арм отлично подходят. Но их не зря выделяют в отдельную нишу, потому что они — лагалище чистой воды в сравнении с «взрослыми» системами.
А когда речь идёт про рынок десктопов, даже если мы примем теорию о смерти десктопа (не верю), то это десятки мегабайт JS в веб-приложениях. Написанные в рассчёте на быстрый интел, а не на медленный арм. (а те, кто «на медленный арм», называются m.example.com, да?).
browser.primatelabs.com/processor-benchmarks (вкладка 64 бита)
E5-2630 (мой рабочий процессор) — 10к попугаев
мой ноутбук (i7-2640M) — 8.6k попугаев.
домашний компьютер 4х-летней давности (core quad) — 6k попугаев
Свежий-свежий арм (цифр на сайте не нашёл, верю вашим) — 2.2k.
Вы чувствуете разницу? 4 года назад интел на среднем десктопном процессоре уделывала текущий арм в 3 раза. Сейчас уделывает в 4 раза. Даже если предположить, что скорость роста производительности у арма будет как была у интела, а у интела остановится (маловероятно) — то потребуется около 12 лет (полуторакратный рост производительности за 4 года, 1.5*1.5*1.5 ~= 8.6/2.2) до момента достижения сравнимой производительности.
Когда вы говорите «для потребителя хватит» вы повторяете нелепую ошибку, которую приписывают Гейтсу (насчёт 640к). Не хватит. И я лично видел совершенно не разбирающихся в компьютерах людей, которые плевались неттопы на атомах, потому что:
* флеш игрушки
* яваскрипт в браузерах на мегабайты
* скорость открытия любимых программ
* отзывчивость интерфейсах в оных
Определяется процессором и скоростью IO. Чтобы выкатить неттоп атом или арм отлично подходят. Но их не зря выделяют в отдельную нишу, потому что они — лагалище чистой воды в сравнении с «взрослыми» системами.
А когда речь идёт про рынок десктопов, даже если мы примем теорию о смерти десктопа (не верю), то это десятки мегабайт JS в веб-приложениях. Написанные в рассчёте на быстрый интел, а не на медленный арм. (а те, кто «на медленный арм», называются m.example.com, да?).
а вы сравните по параметру мощность*число транзисторов*частота/ техпроцесс. Фишка армов это потребление — это почти самое важное для портативных устройств, да — интел сейчас производительней, но сколько эта, жрущая over100 Ватт молотилка проработает от батареи?
Массовые настольные процессоры intel содержат сейчас более миллиарда транзисторов (например, Core i5 с HD4000 – 1,4 млрд.), а Core i7 Extreme – 2,2 млрд. С другой стороны, ARM уровня Tegra2 включает всего около 250 млн. транзисторов, а выпущенный в позапрошлом году 5-ти ядерный чип Tegra 3 только подобрался к миллиарду. Хотя nvidia умеет и больше – в видеокартах на “кепплерах” по 7 млрд. транзисторов. Ну, правда, площадь чипа совсем другая.
При этом, многие новые процессоры intel уже выпускает по нормам 22 нм, тогда как “мобильные производители” еще сидят на 32 нм и, даже, 45 нм.
При этом, многие новые процессоры intel уже выпускает по нормам 22 нм, тогда как “мобильные производители” еще сидят на 32 нм и, даже, 45 нм.
2200 это не последний АРМ, это мой нексус :)
3495 это последний octa процессор от Samsung. Но там по сути или 4 или другие 4 ядра включаются.
У вас ноут на i7 — классно. Но сейчас многие берут на i3 и их это устраивает. В итоге установив сейчас 8 ядер A15, можно получить производительность где то 7к попугаев. Как раз около вашего ноута будет. И самое главное 8 ядер постоянно включенный никому не нужны. К слову у меня на нексус 4 4 ядра включаются когда в хроме 2-3 вкладки в фоне грузятся и при этом к слову у меня остается плавная прокрутка.
Последние процы A15 на 2 ггц и 8 ядер дадут схожую производительность. Только вот для чатиков, всяких вк, ютуба и т.д. будет хватать одного ядра, которое продержится 20 часов автономной работы.
И кстати интерфейс отзывчив, программы открываются замечательно. ява скрипты тоже летают, даже флеш работает без лагов.
Аппаратное ускорение есть, и оно уже тянет достаточно сложные игры с красивой графикой, почему же оно вдруг не сможет тянуть интерфейс, приложения, ява скрипт и простенькие флеш игрушки (к слову сейчас мало знаю людей играющих в такие)
3495 это последний octa процессор от Samsung. Но там по сути или 4 или другие 4 ядра включаются.
У вас ноут на i7 — классно. Но сейчас многие берут на i3 и их это устраивает. В итоге установив сейчас 8 ядер A15, можно получить производительность где то 7к попугаев. Как раз около вашего ноута будет. И самое главное 8 ядер постоянно включенный никому не нужны. К слову у меня на нексус 4 4 ядра включаются когда в хроме 2-3 вкладки в фоне грузятся и при этом к слову у меня остается плавная прокрутка.
Последние процы A15 на 2 ггц и 8 ядер дадут схожую производительность. Только вот для чатиков, всяких вк, ютуба и т.д. будет хватать одного ядра, которое продержится 20 часов автономной работы.
И кстати интерфейс отзывчив, программы открываются замечательно. ява скрипты тоже летают, даже флеш работает без лагов.
Аппаратное ускорение есть, и оно уже тянет достаточно сложные игры с красивой графикой, почему же оно вдруг не сможет тянуть интерфейс, приложения, ява скрипт и простенькие флеш игрушки (к слову сейчас мало знаю людей играющих в такие)
E5-2630 (мой рабочий процессор) — 10к попугаев
мой ноутбук (i7-2640M) — 8.6k попугаев.
домашний компьютер 4х-летней давности (core quad) — 6k попугаев
Мне кажется, Вы только что сами как раз и дали отличный пример того, почему Intel достаточно успешно «догоняют». Посмотрите еще раз на относительные цифры указанных Вами процессоров Intel и оцените динамику их увеличения — за четыре года никакого удвоения производительности не произошло, даже и близко, даже с учетом наличия Xeon'а в сравнении… а теперь посмотрим на динамику роста производительности процессоров в iPhone, как раз с вчерашней презентации:
С SSD не все так безоблачно по IOPS, отличное когда читаем и значительно хуже на рандомную запись(процедура очистки ячеек перед записью).
Даже сильно устаревшие intel 320, в самом ужасном случае показывали 400-600 IOPS на запись. И чтобы так сделать надо было ставить тест на сутки непрерывно писать особо мерзкими паттернами. Для шпинделей же даже цифра в 400 выглядит как невероятные понты и экстремальный хайэнд (15к RPM, FC/SAS, etc). А ведь при 400 IOPS'ах она ещё несколько тысяч на чтение выдавала.
Сейчас же все приличные SSD уже достигли показателей, когда скорость IO в IOPS'ах просто не является существенным фактором, а важными становятся latency и линейная скорость. (да-да, внезапно).
Причём я говорю уже не про серверный хай-энд, а про десктопы (на примере моего ноутбука, которому уже больше года, и который показывает 50к IOPS на чтение).
Сейчас же все приличные SSD уже достигли показателей, когда скорость IO в IOPS'ах просто не является существенным фактором, а важными становятся latency и линейная скорость. (да-да, внезапно).
Причём я говорю уже не про серверный хай-энд, а про десктопы (на примере моего ноутбука, которому уже больше года, и который показывает 50к IOPS на чтение).
А есть -ли какой-то Roadmap?
Конечно же есть, без планов крупный бизнес не работает, а чипы Apple — это уже очень крупный бизнес.
Например на последней презентации было заявлено, что «в октябре планируется отгрузка 700-миллионного iOS-гаджета» — а это означает, что за последние годы Apple выпустила не менее 700-миллионов ARM-чипов Apple Ax!
Но все же знают, что Apple это секретная компания и поэтому я думаю, что нам Roadmap в ближайшем времени не увидеть:(
Например на последней презентации было заявлено, что «в октябре планируется отгрузка 700-миллионного iOS-гаджета» — а это означает, что за последние годы Apple выпустила не менее 700-миллионов ARM-чипов Apple Ax!
Но все же знают, что Apple это секретная компания и поэтому я думаю, что нам Roadmap в ближайшем времени не увидеть:(
Я имел ввиду именно публичный Roadmap.
Вы с ума сошли, каких 700 лямов чипов, когда Самсунг пол дороги им делал процессоры?
Samsung и до сих пор участвует (и скорее всего будет еще не один год, несмотря на разногласия Apple и Samsung), вот только Samsung является лишь изготовителем, который предоставляет свои фабы для изготовления процессоров, разработали которые в Apple.
Вы ведь не станете говорить, что iPhone является продуктом Foxconn (а не Apple), ведь они участвуют в его сборке, верно?
Вы ведь не станете говорить, что iPhone является продуктом Foxconn (а не Apple), ведь они участвуют в его сборке, верно?
Так было не всегда. Процессоры для первого айфона и делал, и разрабатывал Самсунг. А первое поколение Apple TV и вовсе имело внутри Pentium M.
Ну так, а кто говорит, что так было всегда? Суть в том, что начиная с A4 в той или иной мере процессоры Apple разрабатывает для своих мобильных устройств сама. Если же посмотреть на кривую продаж этих самых устройств, то окажется, что примерно с этого момента перехода на A4 (iPhone 4) продажи и достигли таких высоких значений, что все предыдущие объемы моментально оказались небольшими, по сравнению с новыми.
Ну первый iPhone 2007 года разошёлся не очень большим тиражом.
Да и первые поколения Apple TV 2007 года не были iOS-устройствами.
До сентября 2010 года Apple TV действительно работали на Pentium M и под управление операционной системы Apple TV OS — урезанный и модифицированный вариант настольной ОС Apple Mac OS X Tiger.
И только лишь 1 сентября 2010 года была представлена компактная и дешёвая новая версия Apple TV (2010) в основе которой был ARM-процессор Apple A4, и вот с тех самых пор она работает под управление модифицированного варианта мобильной ОС Apple iOS.
Да и первые поколения Apple TV 2007 года не были iOS-устройствами.
До сентября 2010 года Apple TV действительно работали на Pentium M и под управление операционной системы Apple TV OS — урезанный и модифицированный вариант настольной ОС Apple Mac OS X Tiger.
И только лишь 1 сентября 2010 года была представлена компактная и дешёвая новая версия Apple TV (2010) в основе которой был ARM-процессор Apple A4, и вот с тех самых пор она работает под управление модифицированного варианта мобильной ОС Apple iOS.
Samsung делал и дальше будет штамповать чипы по заказу Apple. Но именно Apple их разработала — это нормально и большинство разработчиков чипов не имеет своих заводов, например компании AMD, Qualcom и т.д.
У AMD были свои заводы. Они их выделили в отдельное предприятие.
Ну да, но сегодня ведь с 2009 года GlobalFoundries является независимым от AMD контрактным производителем полупроводниковых интегральных микросхем.
А AMD с 2009 года является fabless-компанией (без собственных заводов), проектирующая микроэлектронные устройства.
Тот же пример можно привести и с Freescale Semiconductor — когда-то это было славное подразделение Motorola Semiconductor со своими собственными заводами, конкурировавшая с Intel. Но они проиграли конкуренцию и продали все свои заводы и с 2004 года Freescale является независимой fabless-компанией.
Да и сегодня почти все компании проектирующие микросхемы не имеют своих собственных заводов (так что Apple это не исключение, а правило для этой отрасли), и заказывают производство микросхем у независимых контрактных производителей — основными из которых являются:
1. TSMC,
2. United Microelectronics Corporation,
3. GlobalFoundries.
А исключением из этого правила данной отрасли по-моему остаются лишь три компании:
1. Intel,
2. IBM,
3. Samsung Electronics,
— которые как сами проектируются, так сами и производят микросхемы. Причем последние две компании не гнушаются выпуском микроэлектроники по контракту для других разработчиков (например Samsung выпускает чипы для Apple). И только лишь Intel упрямо не хочет ни кого пускать на свои простаивающие заводы, хотя и здесь похоже постепенно происходит сдвиг с мёртвой точки — см.: «Intel будет работать по контракту».
Поправьте меня — если я не прав:)
А AMD с 2009 года является fabless-компанией (без собственных заводов), проектирующая микроэлектронные устройства.
Тот же пример можно привести и с Freescale Semiconductor — когда-то это было славное подразделение Motorola Semiconductor со своими собственными заводами, конкурировавшая с Intel. Но они проиграли конкуренцию и продали все свои заводы и с 2004 года Freescale является независимой fabless-компанией.
Да и сегодня почти все компании проектирующие микросхемы не имеют своих собственных заводов (так что Apple это не исключение, а правило для этой отрасли), и заказывают производство микросхем у независимых контрактных производителей — основными из которых являются:
1. TSMC,
2. United Microelectronics Corporation,
3. GlobalFoundries.
А исключением из этого правила данной отрасли по-моему остаются лишь три компании:
1. Intel,
2. IBM,
3. Samsung Electronics,
— которые как сами проектируются, так сами и производят микросхемы. Причем последние две компании не гнушаются выпуском микроэлектроники по контракту для других разработчиков (например Samsung выпускает чипы для Apple). И только лишь Intel упрямо не хочет ни кого пускать на свои простаивающие заводы, хотя и здесь похоже постепенно происходит сдвиг с мёртвой точки — см.: «Intel будет работать по контракту».
Поправьте меня — если я не прав:)
думаю, что очередная рекламная кампания Apple — не более
«Реклама заставляет нас полюбить машины и шмотки; мы ходим на работу, которую ненавидим, чтобы купить вещи, которые нам не нужны».
Как всегда — много красивых лозунгов, мало конкретики — ну и какие преимущества дает 64 битная архитектура в смартфоне?
«Реклама заставляет нас полюбить машины и шмотки; мы ходим на работу, которую ненавидим, чтобы купить вещи, которые нам не нужны».
Как всегда — много красивых лозунгов, мало конкретики — ну и какие преимущества дает 64 битная архитектура в смартфоне?
Я думаю, что в смартфоне 64 битная архитектура полезна в основном для реалистичных 3D-игр — в них обрабатываются огромные массивы цифровой информации — и там чем больше бит — тем лучше!
в iphone 4S — 512 мб оперативки — о каких огромных объемах данных вы говорите? основные плюсы 64 разрядной архитектуры — большая скорость обмена с оперативкой, больше пространство адресное, больше диапазон данных. Второе и третье нафиг смартфону не нужно, первое — сходу конечно так говорить не стоит, но скорей всего тоже
Имелись ввиду большие по размеру структуры данных. И вообще, что-то все молчат, что теперь памяти понадобится больше.
ru.wikipedia.org/wiki/TrueColor
может я конечно отстал от жизни — буду рад если объясните, но пока я считаю, что для хранения видеоинформации достаточно 24 бит
может я конечно отстал от жизни — буду рад если объясните, но пока я считаю, что для хранения видеоинформации достаточно 24 бит
Во-первых, недостаточно. 8 бит на канал, и вы получаете ужансые градиенты смежных оттенков. Но это вообще из другой оперы. Для начала нужно пустить в массовое производство 10-битные матрицы. А то пока только в кино и медицине. Когда маркетологи разовьют тему с 4K/8K, обязательно возьмутся за 10-битный цвет.
Во-вторых (ближе к программированию), ru.wikipedia.org/wiki/High_Dynamic_Range_Rendering.
В-третьих, я вообще имел ввиду совсем не цвет, а например, позицию объекта на виртуально сцене, или какие-то физические расчеты и т.д. Вообще, все это очень зависит от процессора, что и чего он может делать за один такт.
Во-вторых (ближе к программированию), ru.wikipedia.org/wiki/High_Dynamic_Range_Rendering.
В-третьих, я вообще имел ввиду совсем не цвет, а например, позицию объекта на виртуально сцене, или какие-то физические расчеты и т.д. Вообще, все это очень зависит от процессора, что и чего он может делать за один такт.
Наличие 64 bit float никак не зависит от ширины адресной шины или размеров основных регистров. И собственно для игр никакой особой пользы от 64 бит нету, всякие crysis, unreal tournament и прочие большие игры на ПК отлично работают в 32 битном режиме и пока переходить на 64 бит даже не торопятся.
Собсно с новым armv8 такая же история как и с arm7s: зачем компилировать целый отдельный бинарник, увеличивая размер итогового приложения (а он ограничен 50 мб для казуалок — ровно столько можно скачать по 3g), не имея никакой пользы? Бинарники ведь не сжимаются в IPA архиве, а каждый бинарник это от 2 до 10 мб в зависимости от интегрированных фреймворков и движка.
Собсно с новым armv8 такая же история как и с arm7s: зачем компилировать целый отдельный бинарник, увеличивая размер итогового приложения (а он ограничен 50 мб для казуалок — ровно столько можно скачать по 3g), не имея никакой пользы? Бинарники ведь не сжимаются в IPA архиве, а каждый бинарник это от 2 до 10 мб в зависимости от интегрированных фреймворков и движка.
а он ограничен 50 мб для казуалок
Вы давно заходили в App Store? Давно уже полно игр которые занимают от 500 до 1000 МБ.
логично было бы сделать два разных бинарника. и чтобы аппстор различал какой из бинарников отдавать.
> 50 мб
Понимаю, что оффтопик, но — руки поотрывать иным авторам за эти «всего 50 Мб» весящие игрушки. Притом функционал (не увлекательность!) в игре чуть не как у старого доброго тетриса, разве что текстуры намалеваны с большими dpi. Зайдешь в Аппстор, посмотришь, а там то же самое по функционалу ПО что 3 года назад весило 2-3 Мб, теперь весит 20-30, отличается задумчивостью старта и показом баннеров по делу и нет. И (тупо) никакой более заметной пользы от распухания.
На выходе — раньше телефон на 16 Гб вмещал и программы, и медия (фото, фильмы, музыку), и еще место было. Теперь 16 Гб забиваются сравнимыми программами так, что на медиа уж нужно думать, сколько оставить.
Напомнило ситуация с Visual Basic, когда с бинарником на 150 Кб шло 5 Мб библиотек, без которых программа не работала, и которые память кушали мама-не-горюй как. Собственно, так и есть в отношении многих программ сейчас :)
Так что, если по теме, 64 бита адресации скоро уже станут в тему, ибо — нет того объема памяти и диска, который бы не занял деятельный юзер или криворукий программист. Куда уж тут лимитам в 50 мб? :)
Понимаю, что оффтопик, но — руки поотрывать иным авторам за эти «всего 50 Мб» весящие игрушки. Притом функционал (не увлекательность!) в игре чуть не как у старого доброго тетриса, разве что текстуры намалеваны с большими dpi. Зайдешь в Аппстор, посмотришь, а там то же самое по функционалу ПО что 3 года назад весило 2-3 Мб, теперь весит 20-30, отличается задумчивостью старта и показом баннеров по делу и нет. И (тупо) никакой более заметной пользы от распухания.
На выходе — раньше телефон на 16 Гб вмещал и программы, и медия (фото, фильмы, музыку), и еще место было. Теперь 16 Гб забиваются сравнимыми программами так, что на медиа уж нужно думать, сколько оставить.
Напомнило ситуация с Visual Basic, когда с бинарником на 150 Кб шло 5 Мб библиотек, без которых программа не работала, и которые память кушали мама-не-горюй как. Собственно, так и есть в отношении многих программ сейчас :)
Так что, если по теме, 64 бита адресации скоро уже станут в тему, ибо — нет того объема памяти и диска, который бы не занял деятельный юзер или криворукий программист. Куда уж тут лимитам в 50 мб? :)
Вообще-то всё логично.
Раньше разрешение айфона было 320*480 = 153600 точек.
Потом появился айпад 1024*768, для универсального приложения нужна графика для 320*480 + 1024*768 = 863232 точек, т.е. в 5,62 раза больше.
А потом появилась ретина, и для её поддержки нужна уже графика для (863232 + 4*863232) = 4316160, т.е. ещё в 5 раз больше.
Так что если в результате поддержки новых устройств и разрешений «вес» графики вырос не в 5,62*5 = 28,1 раз, а всего лишь в 10, значит «криворукие программисты» постарались таки ужать графику почти в 3 раза. (Это мы ещё айфон 5 не учли).
А теперь вопрос: а оно того стоило, если пользователи этого совсем не ценят, и не готовы за это доплатить?
Раньше разрешение айфона было 320*480 = 153600 точек.
Потом появился айпад 1024*768, для универсального приложения нужна графика для 320*480 + 1024*768 = 863232 точек, т.е. в 5,62 раза больше.
А потом появилась ретина, и для её поддержки нужна уже графика для (863232 + 4*863232) = 4316160, т.е. ещё в 5 раз больше.
Так что если в результате поддержки новых устройств и разрешений «вес» графики вырос не в 5,62*5 = 28,1 раз, а всего лишь в 10, значит «криворукие программисты» постарались таки ужать графику почти в 3 раза. (Это мы ещё айфон 5 не учли).
А теперь вопрос: а оно того стоило, если пользователи этого совсем не ценят, и не готовы за это доплатить?
64 бита — это не ширина физической шины данных (которая у всех давно в разы шире), не ширина шины адреса и размер адресуемой памяти (32-х битные интелы имеют шину шире 32 бит и умеют адресовать больше 4 гигов, см. PAE). Как правило за «битность» процессора считают ширину регистра общего назначения.
В чистом виде 64-битность делает поудобнее работу с большими объемами памяти, ну и на нее немного получше ложатся некоторые алгоритмы.
Но кроме этого, переделка на 64 бит — это смена системы команд, позволяющая «отрефакторить» процессор, напихать в него много новых плюшек.
Короче фишка в чем — в фразе «64 бита» важно не то, сколько там где бит будет, а что у процессора очень серьезно модернизировали архитектуру. Да, сделали в процессе регистры 64-битными, но на скорость это не влияет (а может быть еще и замедляет). На скорость влияет то, что сделали заодно с переделкой на 64 бита.
В чистом виде 64-битность делает поудобнее работу с большими объемами памяти, ну и на нее немного получше ложатся некоторые алгоритмы.
Но кроме этого, переделка на 64 бит — это смена системы команд, позволяющая «отрефакторить» процессор, напихать в него много новых плюшек.
Короче фишка в чем — в фразе «64 бита» важно не то, сколько там где бит будет, а что у процессора очень серьезно модернизировали архитектуру. Да, сделали в процессе регистры 64-битными, но на скорость это не влияет (а может быть еще и замедляет). На скорость влияет то, что сделали заодно с переделкой на 64 бита.
«основные плюсы 64 разрядной архитектуры — большая скорость обмена с оперативкой».
Ну-ка пруфы сюда! С чего это у нас скорость обмена вырастет?
Ну-ка пруфы сюда! С чего это у нас скорость обмена вырастет?
шина данных шире в 2 раза — за один такт раньше получали 32 бита, а сейчас 64 — пруфы, что 2х2 = 4 тоже надо со ссылкой на авторитетный источник?
А что, кэш у нас уже отменили? Мы уже не строками читаем из памяти?
У наших десктопных процессоров, например, когда они были еще 32-битными, шина данных была 64 бита. И сейчас с 64-битными процессорами, шина данных тоже 64 бита. При этом читаем мы каждый раз строку по 64 байта, так что не надо мне тут это самое.
Это вам не микроконтроллеры!
У наших десктопных процессоров, например, когда они были еще 32-битными, шина данных была 64 бита. И сейчас с 64-битными процессорами, шина данных тоже 64 бита. При этом читаем мы каждый раз строку по 64 байта, так что не надо мне тут это самое.
Это вам не микроконтроллеры!
Как-то после многопоточных вычислений, мне кажется, что разрядность в очерченном круге приложений, не даст такого прироста, как те же сотни ядер, выполняющих простые операции.
Тут мы сможем говорить либо об адресации в памяти, либо об увеличении диапазона целого типа чисел в два раза (я в плане количества бит). То есть, я бы ожидал то, что за один такт мы теперь сможем сложить два 32битных числа, вместо одного.
Но в 3D мире важны вычисления с плавающей точкой (будь то float или double).
Тут мы сможем говорить либо об адресации в памяти, либо об увеличении диапазона целого типа чисел в два раза (я в плане количества бит). То есть, я бы ожидал то, что за один такт мы теперь сможем сложить два 32битных числа, вместо одного.
Но в 3D мире важны вычисления с плавающей точкой (будь то float или double).
Сотни ядер тоже сложно эффективно нагрузить в обычных приложениях.
С большей разрядностью теоретически мы имеем больше места под команды и операнды, но и нуждаемся в большем количестве и более быстрой памяти.
Интересно, как Эпл решил проблемы совместимости с 32-битными приложениями, и придётся ли разработчикам теперь делать два бинарника под соответствующие архитектуры.
Впрочем, на компах в Mac OS X проблем с этим не было, в отличие от Windows и Linux.
С большей разрядностью теоретически мы имеем больше места под команды и операнды, но и нуждаемся в большем количестве и более быстрой памяти.
Интересно, как Эпл решил проблемы совместимости с 32-битными приложениями, и придётся ли разработчикам теперь делать два бинарника под соответствующие архитектуры.
Впрочем, на компах в Mac OS X проблем с этим не было, в отличие от Windows и Linux.
В гайде написано, что будет точно так же, fat binary.
О Господи. Быстрее не значит лучше. (я про скорость разработки).
Другими словами, они — не конкуренты, а ппроприетарщики; цель — не выпустить процессоры, а уйти от открытой архитектуры, рассчитывая на этом, а не на шатком равновесии удач в архитектуре чипов иметь прибыль. Плюс ту, которую зарабатывает себе Интел сейчас.
вот именно что цель — не выпускать процессоры и получать с этого прибыль, Apple (по крайней мере как они сами заявляют) в процессорный бизнес пошли только из-за того, чтобы все стадии разработки и производства держать под своим контролем и выпускать качественные продукты в своей экосистеме.
так что скорее всего, тот же самый их чип отдельно никому кроме них и не нужен
так что скорее всего, тот же самый их чип отдельно никому кроме них и не нужен
если что, мне безумно нравится подход open source но зачастую такой подход потребует времени и прямых рук у конечных пользователей. Вот вчера например соседу планшет на андройде настраивал. Одна из проблем — видео играло с артефактами. Пришлось пробовать несколько плееров, что-то шаманить в настройках приложения в итоге все заработало — видимо настройки по-умолчанию не подходили к железу планшета.
Лично для меня это не проблема, но приятно же когда все из коробки работает и совсем другое впечатления у пользователя (думаю) остается. Хотя многие может об этом и не задумываются
Лично для меня это не проблема, но приятно же когда все из коробки работает и совсем другое впечатления у пользователя (думаю) остается. Хотя многие может об этом и не задумываются
Скажу что теперь у менеджера в магазине по продаже телефонов, кроме тут же камера 158 мегапикселов, появился еще один аргумент — 158 разрядный процессор.
Сегодня прочитал статью про Android NDK, и после этой новости задумался — сколько же будет ещё разных типов процессоров, что бедный компилятор просто замучается под каждый них создавать бинарники?!
Думаю 95% приложений использующих NDK нативно собраны и оттестированы только под armv7, под x86 есть трансляция на лету (интел продвигает атомы под телефоны), а под armv6, armv8, mips и прочие придется скорее всего вручную компилировать.
Компьютер железный, ему всё равно, а вот бедные программисты могут замучаться писать приложения на Си сразу под две архитектуры. Впрочем, поживём — увидим.
А в чем хоть какая-нибудь сложность в написании кода под разные процессорные архитектуры на Си/С++? Этот язык изначально создавался, чтобы как раз таких проблем не было.
проблемы начинаются при неверном использовании типов данных (для мультиплатформенных приложений нужно использовать типы строгой разрядности, типа int32_t и пр.) и при передаче данных между 32- и 64-разрядными системами. У нас недавно была бага из-за того, что на 64 битах time_t имеет размер 8 байт, а на 32 битах — 4, в рез-те sizeof(time_t) возвращает разные значения и данные, передаваемые по сети декодились неправильно
Корректно написанному коду без разницы, LE или BE.
Подробнее: commandcenter.blogspot.co.uk/2012/04/byte-order-fallacy.html
Подробнее: commandcenter.blogspot.co.uk/2012/04/byte-order-fallacy.html
Whenever I see code that asks what the native byte order is, it's almost certain the code is either wrong or misguided. And if the native byte order really does matter to the execution of the program, it's almost certain to be dealing with some external software that is either wrong or misguided. If your code contains #ifdef BIG_ENDIAN or the equivalent, you need to unlearn about byte order.
Только вот если требуется производительность и работа с железом, то C вдруг перестаёт быть платформонезависимым. Там уже появляются интринсики, кешстроки и кеш протоколы.
А чтение байтиков — мелочь
А чтение байтиков — мелочь
unsigned funca(unsigned char *data)
{
return (data[3]<<0) | (data[2]<<8) | (data[1]<<16) | (data[0]<<24);
}
funca(unsigned char*): # @funca(unsigned char*)
movzbl 3(%rdi), %ecx
movzbl 2(%rdi), %eax
shll $8, %eax
orl %ecx, %eax
movzbl 1(%rdi), %ecx
shll $16, %ecx
orl %eax, %ecx
movzbl (%rdi), %eax
shll $24, %eax
orl %ecx, %eax
ret
unsigned funcb(unsigned char *data)
{
unsigned i = *((unsigned*)data);
i = ((i&0xFF)<<24) | (((i>>8)&0xFF)<<16) | (((i>>16)&0xFF)<<8) | (((i>>24)&0xFF)<<0);
return i;
}
funcb(unsigned char*): # @funcb(unsigned char*)
movl (%rdi), %eax
bswapl %eax
ret
Я даже не ожидал, что gcc свернёт вторую функцию в одну инструкцию. cl из VS2010 — не сворачивает.
А по поводу производительности — вы же знаете, что говорил Кнут о преждевременной оптимизации?
А по поводу производительности — вы же знаете, что говорил Кнут о преждевременной оптимизации?
А по поводу производительности — вы же знаете, что говорил Кнут о преждевременной оптимизации?
“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.”
Иначе говоря оптимизировать нужно тогда, когда станет понятно что именно.
Трактовка «написать говнокод а потом пытаться взлететь» не соотвествует действительности.
Если пишешь заведомо критичный участок, не нужно быть гением чтобы предположить что его нужно писать качественно.
К тому же процессоры сейчас другие чем были в 74г. Если не заботится о производительности с самого начала, потом это будет сделать попросту невозможно без переписки с нуля.
Ну и для ARM, чтобы раз уж о них тема.
Кстати на AArch32 часто получается меньше кода чем на x86
Кстати на AArch32 часто получается меньше кода чем на x86
funca(unsigned char*):
ldrb r3, [r0, #1]
ldrb r1, [r0, #2]
ldrb r2, [r0, #3]
lsls r3, r3, #16
ldrb r0, [r0, #0]
orr r3, r3, r1, lsl #8
orrs r3, r3, r2
orr r0, r3, r0, lsl #24
bx lr
funcb(unsigned char*):
ldr r0, [r0, #0]
rev r0, r0
bx lr
Так это не проблема языка, а отсутствие знаний (в частности стандарта и межпроцессорных особенностей). Если писать без нарушения стандарта (там где нужно гарантировать размер — использовать int*_t типы), использовать сетевой формат для передачи чисел (между PowerPC/Arm/x86), то никаких проблем не может быть в принципе.
Действительно, в чём хоть какая-нибудь сложность, и почему Microsoft до сих пор выпускают 32-битный Windows, почему подавляющее количество софта до сих пор в 32 битах, почему ещё пару лет назад не рекомендовали пользоваться 64-битной сборкой Ubuntu, а у меня на десктопе постоянно падал прикладной софт от браузера и почтового клиента до мессенджера и иногда самого гнома? У чего там ещё были проблемы с 64-битностью? Flash? Firefox? Chrome? Java? Zend Studio?
В чём же хоть какая-нибудь сложность? :)
В чём же хоть какая-нибудь сложность? :)
В моем уютном мире я пользуюсь 64-битной Ubuntu уже 4 года, весь софт за некоторым проприетарным исключением все это время стоял 64-битный. Даже более того, Debian официально поддерживает не только такие распространенные архитектуры как x86 и amd64 (начиная с 2005), но и такие как powerpc (2000), armel (2009) и sparc (1999).
У Microsoft (насколько я себе представляю) и у людей пишущих под винду никогда не было особого понимания, что существует что-то кроме традиционной x86 архитектуры, поэтому часто происходили ошибки вида присваивания указателя к целому числу, что на 64-битных системах приводило к неопределенному поведению. Возможно еще возникали проблемы из-за того, что в функции люди передавали по указателю что-то вроде long, вместо DWORD, что в принципе работало, но не соответстовало документации. Далее, до совсем недавнего времени в Windows были большие проблемы с 64-битными системами сборки, еще пару лет назад 64-битного рабочего mingw фактически не было, MSVS Express включал (а может еще и включает, не знаю) в себя только 32-битный компилятор и т.д… По поводу win-специфичных 64-битных проблем, я думаю, Andrey2008 смог бы рассказать лучше чем я.
Но все эти проблемы не касаются Unix/Linux/MacOS миров. Оригинальный Unix и GNU изначально писались с пристрелом на различные платформы. Linux еще с 1995 года стал поддерживать отличные от x86 платформы (Alpha, SPARC и MIPS). MacOS за свою историю уже пережила 3 переезда (PowerPC -> x86 -> amd64).
У Microsoft (насколько я себе представляю) и у людей пишущих под винду никогда не было особого понимания, что существует что-то кроме традиционной x86 архитектуры, поэтому часто происходили ошибки вида присваивания указателя к целому числу, что на 64-битных системах приводило к неопределенному поведению. Возможно еще возникали проблемы из-за того, что в функции люди передавали по указателю что-то вроде long, вместо DWORD, что в принципе работало, но не соответстовало документации. Далее, до совсем недавнего времени в Windows были большие проблемы с 64-битными системами сборки, еще пару лет назад 64-битного рабочего mingw фактически не было, MSVS Express включал (а может еще и включает, не знаю) в себя только 32-битный компилятор и т.д… По поводу win-специфичных 64-битных проблем, я думаю, Andrey2008 смог бы рассказать лучше чем я.
Но все эти проблемы не касаются Unix/Linux/MacOS миров. Оригинальный Unix и GNU изначально писались с пристрелом на различные платформы. Linux еще с 1995 года стал поддерживать отличные от x86 платформы (Alpha, SPARC и MIPS). MacOS за свою историю уже пережила 3 переезда (PowerPC -> x86 -> amd64).
И сегодня Apple доказала, что у них не просто маленький отдел из нескольких сотрудников занимается чипостроением
Вообще-то они это доказали ещё в прошлом году, с выходом A6.
Ну, они там немного переделали архитектуру, получив что-то типа Krait в Snapdragon. Назвали Swift.
Можно поинтересоваться, какую именно архитектуру _переделали_?
Архитектура ARMv7. Это стандарт, его нельзя «переделать» без потери совместимости.
Немного это на сколько?
A6/A6x/A7 это процессоры имеющие full-custom layout.
Ни ARM, ни Qualcomm не могут себе позволить такую роскошь.
Даже AMD делает кастом лишь для топовых процессоров.
Архитектура ARMv7. Это стандарт, его нельзя «переделать» без потери совместимости.
Немного это на сколько?
A6/A6x/A7 это процессоры имеющие full-custom layout.
Ни ARM, ни Qualcomm не могут себе позволить такую роскошь.
Даже AMD делает кастом лишь для топовых процессоров.
>И сегодня Apple доказала, что у них не просто маленький отдел из нескольких сотрудников занимается чипостроением, а целый огромный коллектив (можно сказать отдельная компания) состоящий из нескольких сотен инженеров, готовый на равных конкурировать с Applied Micro Circuits, NVidia, а может быть даже и с AMD, и даже с Intel.
Зря они чтоли покупали тех ребят которые сделали первый PowerPC вне AIM альянса?
Зря они чтоли покупали тех ребят которые сделали первый PowerPC вне AIM альянса?
Может они сейчас такие: БАЦ! подключил АйЭкран и АйКлавиатуру к АйФону и вот тебе уже полноценный АйДесктоп компьютер?
Еще одно преимущество 64 бит — это адресное пространство. А значит и memory mapped доступ к файлам теперь значительно упростился.
Сегодня уже от троих близких к IT людей услышал мнение, что 64битная архитектура должна стать быстрее.
64 битные процессоры страдают от большего размера инструкции. В ARM'е Thumb режим добавили именно чтобы ускориться за счет уменьшения размера инструкции и, как следствие, увеличения плотности кода. Чем меньше плотность кода, тем больше приходится тратить кэша, ресурса шины, оперативки и т.д. Поэтому заявления о том, что 64 битный ARM должен вдруг стать сильно быстрее — довольно опрометчивы.
Тем не менее, архитектура ARMv8 имеет множество преимуществ над ARMv7 и 64битность лишь одно из изменений. Конечно, ARMv8 разрабатывали не просто так и он будет лучше, быстрее сильнее.
64 битные процессоры страдают от большего размера инструкции. В ARM'е Thumb режим добавили именно чтобы ускориться за счет уменьшения размера инструкции и, как следствие, увеличения плотности кода. Чем меньше плотность кода, тем больше приходится тратить кэша, ресурса шины, оперативки и т.д. Поэтому заявления о том, что 64 битный ARM должен вдруг стать сильно быстрее — довольно опрометчивы.
Тем не менее, архитектура ARMv8 имеет множество преимуществ над ARMv7 и 64битность лишь одно из изменений. Конечно, ARMv8 разрабатывали не просто так и он будет лучше, быстрее сильнее.
Кстати, разработчики ARM'а — ребята умные, поэтому они оставили тот же размер инструкции (32 бита), просто добавили возможность работы с 64битными аргументами. Плотность кода снизится не сильно, в основном за счет 64битных указателей.
Тут еще на все влияет что с чем сравнивать, армы они очень уж разные бывают.
Если Cortex-A8 (32 бита, 2-issue, in-order) сравнивать с Cortex-A57 (64 бита, 3-issue out-of-order, вдвое больше регистров) — то разница будет существенная, вероятно двухкратная и более.
А вот если сравнивать Cortex-A15 (32 бита, 3-issue, out-of-order) с Cortex-A57 (64 бита, 3-issue out-of-order, вдвое больше регистров) — то отличие будет на проценты.
Если Cortex-A8 (32 бита, 2-issue, in-order) сравнивать с Cortex-A57 (64 бита, 3-issue out-of-order, вдвое больше регистров) — то разница будет существенная, вероятно двухкратная и более.
А вот если сравнивать Cortex-A15 (32 бита, 3-issue, out-of-order) с Cortex-A57 (64 бита, 3-issue out-of-order, вдвое больше регистров) — то отличие будет на проценты.
О том и речь, что сама по себе 64битность никакого прироста производительности не дает, а скорее наоборот дает некоторое замедление. А вот переделанный конвейер, большее количество регистров, дополнительные инструкции и т.д. вполне себе неплохо ускоряют.
то отличие будет на проценты.
ARM обещает ~25%
оказывается — камера в предыдущем айфоне — на самом деле дерьмо — покупайте новый
--вопрос снят, извините--
Как упомянули в habrahabr.ru/post/193278/#comment_6713192, процессоры десктоп-класса в мобилках — это вполне в тренде на замену десктопов мобилками.
«Десктоп» в кармане, подключаемый без проводов ко всему вокруг, начиная с 4xHD-телевизора и bluetooth-клавиатуры, домашнего NAS, общего облака, и ничем не заканчивая — это будущее. Много оперативки и мощный процессор в мобилке — необходимы и неизбежны.
Беспроводную дистанционную подзарядку вот ещё обеспечить в дополнение к мощному аккумулятору — и наступит очередная эра вычислительной техники.
«Десктоп» в кармане, подключаемый без проводов ко всему вокруг, начиная с 4xHD-телевизора и bluetooth-клавиатуры, домашнего NAS, общего облака, и ничем не заканчивая — это будущее. Много оперативки и мощный процессор в мобилке — необходимы и неизбежны.
Беспроводную дистанционную подзарядку вот ещё обеспечить в дополнение к мощному аккумулятору — и наступит очередная эра вычислительной техники.
Apple уже имеет опыт выпуска собственных серверов. В свете «тренда» на энергоэффективные сервера, который, в частности, сдерживается отсутствием как раз 64битных процессоров, появление А7 может служить намёком на возвращение Apple в серверный бизнес. Причём в самый динамичный его сектор и вполне может стать лидером или законодателем моды.
От яблок можно ожидать чего угодно. Но сервера это B2B, а сильные пизиции яблок в B2C. Они вряд-ли пойдут в сервера по причине не технической, а имидже-политической.
Просто железо они продавать точно не будут, а только со своей осью (а с серверным софтом для корпораций или на все случаи жизни у них плохо). Я бы сказал, что скорее всего они будут продавать SaaS или чо-то типа amazon.
Просто железо они продавать точно не будут, а только со своей осью (а с серверным софтом для корпораций или на все случаи жизни у них плохо). Я бы сказал, что скорее всего они будут продавать SaaS или чо-то типа amazon.
Я вижу много людей говорит, послушав маркетинг ARM, что «Intel уже несколько лет подряд пыжится догнать ARM по энергоэффективности».
Но по бенчмаркам вижу что даже Intel Atom (Z2760) энергоэффективнее Tegra 3 либо на уровне Cortex A15 — www.anandtech.com/show/6536/arm-vs-x86-the-real-showdown/8. И при этом Intel в этом сравнении быстрее.
Ну чтобы по скорости догнать Haswell i7, ARM должен быть раз в 5-10 быстрее.
Но по бенчмаркам вижу что даже Intel Atom (Z2760) энергоэффективнее Tegra 3 либо на уровне Cortex A15 — www.anandtech.com/show/6536/arm-vs-x86-the-real-showdown/8. И при этом Intel в этом сравнении быстрее.
Ну чтобы по скорости догнать Haswell i7, ARM должен быть раз в 5-10 быстрее.
выпуском чужих разработокПочему чужих? Зря, что ли, они P.A. Semi покупали?
Самостоятельную разработку чего именно? Вообще, наоборот — любые готовые наработки (IP cores) у ARM (и не только) нужно покупать, если не хочешь разрабатывать сам.
Wiki:
Wiki:
Многие лицензиаты делают собственные версии ядер на базе ARM: DEC StrongARM, Freescale i.MX, Intel XScale, NVIDIA Tegra, ST-Ericsson Nomadik, Krait в Qualcomm Snapdragon, Texas Instruments OMAP, Samsung Hummingbird, LG H13, Apple A6 и HiSilicon K3.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apple первой начала выпускать 64-битный ARM-чип!