x86 vs ARM: сложность инструкций

Сложение двух чисел - это вообще линейная логика. Какой тут FSM, недоносок, если отсутствует state?!? А вот тот же сдвиговый регистр это уже FSM. Учи матчасть, школоло ничтожное.

Софт есть. Нет мозгов у серенького быдла, у 95% разработчишек, страдающих синдромом утенка.

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

OLTP - нагрузка нехарактерная для десктопов и характерная для определённых серверов.

Давай конкретно что в OLTP нетипично для процессора :). Большой OLTP обычно характеризуется требованиями к толстому IO с низкими задержками, большому кол-ву памяти ядер. Всё это не имеет непосредственного отношения к архитектуре.

Но если ты готов поддержать разговор какие инструкции, скажем, Itanium делают его назаменимым для OLTP то я готов :)

можно вспомнить кластеры на игростанциях

По-моему, это были просто игрушки. Это предложение было интересно только в те годы когда не было CUDA и доступных многоядерных процов. А 256метров памяти было ацтоем уже тогда.

для десктопа нетипична необходимость МНОГОпоточной обработки. Итаники, кстати, в силу средних характеристик мультитредовости тут не будут лидерами, зато очень неплохо себя покажут, каждый в своей весовой категории, ниагара и power. Пожалуй, в самый топ выйдет как раз Power, из-за очень быстрой памяти и хорошей частоты. Я пока не вспоминаю о надёжности и масштабируемости, а это тоже важно - например, уже даже x86 серверы имеют 8 сокетов, а уж в машинах типа ИБМ p795...

Нахрена на десктопе RAS функционал? Нахрена много сокетов? Память 2Тб и больше?

шайтан-коробку сонька уделала тогда

SPU=гемор, а PPC ядер у ящика в три раза больше, так кто кого уделал? Сонибои воют каждый раз когда замечают бОльшую детализацию/разрешение у мультиплатформенных игр на ящике.

Давай конкретно что в OLTP нетипично для процессора :)

Ну IBM, например, может сконфигурить power выкинув FPU и засунув побольше ALU, чтобы многопоточка лучше шла и суперскалярность рулила. Но это наверное не для наших бюджетов =)

Большой OLTP обычно характеризуется требованиями к толстому IO

Если база не влезает в память - это же полный П, тут никакой IO не поможет.

для десктопа нетипична необходимость МНОГОпоточной обработки

Тем не менее, ксеоны отодрали ниагару в многопоточных тестах.

в самый топ выйдет как раз Power, из-за очень быстрой памяти

Эээ, можно пруф что у power какая-то особая память? Или ты имеешь в виду «относительно быстрая для своих объёмов»? «Быстрая» и «маленькие задержки» это две разные вещи. Уже давно всё упирается именно в задержи, а не последовательную скорость передачи данных.

Нахрена много сокетов? Память 2Тб и больше?

Я, честно говоря, даже не представляю сколько таких машин продаётся в год. 1000? 10000? Это какой-то очень узкий рынок мэйнфреймов, я бы на стал его причислять к рынку серверов.

Я пока не вспоминаю о надёжности и масштабируемости

Я думаю тут мало что зависит от системы команд. Скорее, речь об обвязке вокруг проца. Кмк, покупать такое вендорное железо это вообще зло. Ну только если ты не работаешь в газпроме.

Хмм. Ты хочешь сказать, что аппаратная платформа шайтан-коробка 360 лучше, чем соньковская станция? Я почему-то был уверен в обратном всю дорогу.

Если база не влезает в память - это же полный П

Главное чтобы самая «горячая» часть влезала. Сама база может быть любого объёма, лишь бы не надо было делать full table scan.

Подход нигелировать тормоза базы наращиванием оперативы популярен. Но, из моей веб-практики, пистон программистам делал чудеса. У меня поэтому есть сомнения что покупки «больших» серверов обоснованы хотя бы в 50% случаев. Вот мой знакомый в банке (правда, небольшом, не помню название) сказал что у них jboss на обычной паре сотен серваков крутится. И ничего, все живы.

Тем не менее, ксеоны отодрали ниагару в многопоточных тестах.

В каких именно?

Эээ, можно пруф что у power какая-то особая память? Или ты имеешь в виду «относительно быстрая для своих объёмов»? «Быстрая» и «маленькие задержки» это две разные вещи. Уже давно всё упирается именно в задержи, а не последовательную скорость передачи данных.

Хбз, с ходу найти не получается, на сайте года два назад были сравнения с супердомами того времени. Зато нашёл про новые спарки, к счастью, с цыфирями конкретными, можно сравнить с десктопами - http://slashdot.org/topic/datacenter/oracle-claims-title-of-worlds-fastest-mi...

Я, честно говоря, даже не представляю сколько таких машин продаётся в год. 1000? 10000? Это какой-то очень узкий рынок мэйнфреймов, я бы на стал его причислять к рынку серверов.

Ну а сервера с памятью от 64Гб до 2Тб? Их-то много-много продаётся... И поддержка таких объёмов со стороны проца и обвязки - тоже вещь совершенно не нашедшая места на десктопах.

Я думаю тут мало что зависит от системы команд. Скорее, речь об обвязке вокруг проца. Кмк, покупать такое вендорное железо это вообще зло. Ну только если ты не работаешь в газпроме.

Зависит. Куча всяких проверок, чексум и прочей дряни, датчики, флаги...

Всё зависит не от денег, а от задач и от требований к доступности. Например, мне сейчас очень трудно морально внедрять x86, ведь достаточно очевидно, что экономическая эффективность перехода на такие системы будет сильно скорректирована в последствии, за счёт куда меньшей надёжности этого парка серверов

Ну IBM, например, может сконфигурить power выкинув FPU и засунув побольше ALU

Их нечем будет загружать, главные тормоз это память. Интел и так впихивает FPU и ALU под завязку.

аппаратная платформа шайтан-коробка 360 лучше

Именно, даже если в суммарных попугаях фанаты cell'а опустят xenon, то в реальности реализовать его потенциал практически невозможно из-за специфичности SPU.

В каких именно?

Mysql и postress. Не могу найти линков, те тесты что щас гуглятся это тихий ужас. Кроме синтетики ничего толком не гуглится.

Более того, на однопоточных тестах вообще всё ужасно: http://www.mysqlperformanceblog.com/2008/05/01/t2000-cpu-performance-watch-out/

Зависит. Куча всяких проверок, чексум и прочей дряни, датчики, флаги...

Не знаю что за флаги, а чексумы кэша и датчики температуры есть везде. А если чего-то нет то не вижу проблем поставить их на x86 проц, был бы спрос.

Ну, кластеры были и на том и на другом. А чтобы какие-то игры выходили на Сони гораздо раньше чем на XBox я не помню. Кроме эксклюзива, типа MG4, который был только на PS3. Но тут, скорее политка, чем техника.

Впрочем, я могу быть не в курсе какие игры где раньше выходили: брал PS3 ровно только чтобы пройти MG4, и отдал её по завершению.

Но было бы любопытно узнать, для какой приставки игры выходят в среднем раньше. (Подозреваю, что «приставка» эта называется PC).

Mysql и postress. Не могу найти линков, те тесты что щас гуглятся это тихий ужас. Кроме синтетики ничего толком не гуглится.

Классика - TPC-H http://www.tpc.org/tpcc/results/tpcc_perf_results.asp Там всё ожидаемо. Если не брать в расчёт стоимость, то рулят «большие» системы и risc процы.

Не знаю что за флаги, а чексумы кэша и датчики температуры есть везде. А если чего-то нет то не вижу проблем поставить их на x86 проц, был бы спрос.

Вот именно в архитектуре-то и вся соль. Так бы давно уже были на ксеонах отказоустойчивые 16-32 сокетные сервера. Ан нет, пока такое только на Power/SPARC/Itanium...

Я очень хорошо помню, что на заре нынешнего поколения игровых консолей всюду писали, что cell это монстер, и за ним будущее на годы вперёд, а штучка из шайтан-коробки это сегодня-завтра и всё...

Если это не так - то было бы вполне логичным то, что IBM слила cell. Но тогда не ясно, чего сонька вообще полезла в это дело. Х.з., короче, по данному направлению спорить не буду, т.к. все сведения о консолях у меня из интернетов.

TPC-C, конечно же, прошу прощения, а ссылка верная

Там всё ожидаемо.

Оракл заточил своё железо под свою базу. И то, в ихних кластерах почему-то два ксеона для «sql processing» стоят :). Я не буду спорить что оракл знает толк в базах. Но это не доказывает что такое нельзя сделать на x86. Кстати, обычных бенчмарков sparc T5 что-то нигде нет.

Так бы давно уже были на ксеонах отказоустойчивые 16-32 сокетные сервера.

Исторически на рынке не присутствуют. Это не нужно большим вендорам, особенно hp и ibm которые свои процы пилили (hp itanium разрабатывала совместно с intel). А так есть и серваки с 4ТБ памятью от hp и xeon-ы с RAS (Reliability, Availability, and Serviceability). Кстати, вот на счёт «аппаратных фишек» как ты любишь: http://www.intel.com/Assets/PDF/whitepaper/323479.pdf :) Что касается 16-32 сокета то есть bullx S6030 с четырьмя сокетами которые могут формировать суперноды до четырёх узлов.

Весёлый молочник, ты уже читать разучился? Сложи натуральные числа давай. Не из кольца вычетов по модулю 2^32, а натуральные. Или ты разницы не знаешь, животное?

обычных бенчмарков sparc T5 что-то нигде нет

А это всё дурная практика запрета на публикацию результатов бенчей.

Весёлый молочник, ты уже читать разучился? Сложи натуральные числа давай.

Иди в жопу, укурок. Пока не определишь «сложение натуральных чисел» на машине Тьюринга - не возвращайся.

И еще, укурок - память частью FSM не является. Сожрал, ничтожество некомпетентное?

Пока не определишь «сложение натуральных чисел» на машине Тьюринга - не возвращайся.

Молочник, мне-то зачем это делать? До меня миллионы раз это делали разные люди. Сходи в гугл что ли, например. http://www.mind.ilstu.edu/curriculum/turing_machines/turing_machine_overview.php — классический вариант по первой ссылке.

память частью FSM не является

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

Так чем же, молочник, ты на жизнь себе зарабатываешь? Неужели дворы метёшь?

Википедия так это описывает:

There are tasks which no FSM can do, but some Turing machine can. This is because the FSM has limited memory. The memory is limited by the number of states.

Впрочем, это всё в рамках треда не важно, кмк. Ну хотя бы потому что процессор состоит из множества параллельных устройств с хитрыми зависимостями между ними. Нужны какие-нить сети для описания, например, out-of-order execution.

Кластеры это немного не то. Кластер в случае, скажем, СУБД Oracle это неминуемо RAC, а это в свою очередь, почти наверняка означает портирование, т.е. изменение продукта. Из реально больших систем с большой базой я лично имел дело только с Oracle M9000, IBM P595 и HP Superdome. Ничем похожим по надёжности на x86 не пахло тогда, и до сих пор не пахнет. Были надежды на Superdome 2 на ксеонах, но по крайней мере пока ничего нет.

Покажите мне систему на x86 в которой при выходе из строя половины памяти и процов не остановится сервис? На которой можно не выключая ничего продуктивного поменять или добавить процессоры и память, на ходу?

Пока что проприетарные risc платформы дают много того, чего нет на x86. То, что кому-то это всё не надо, не делает их в этом смысле менее крутыми для тех, кому оно надо.

Если убрать фактор цены, то железо, конечно крутое. Вопрос не в том что «не надо». Это просто оочень дорого.

Но, если честно, я так и не понял что на них делается чего нельзя сделать на кластере обычных компов.

Именно - FSM, те самые, которые реализуются в интегральных схемах, мало общего имеют с теоретической сранью. У нас FSM отдельно, а память отдельно, и FSM с этой памятью взаимодействует. Та же машина Тьюринга с точки зрения электронщика это простой FSM + бесконечная лента. Компьютер - это FSM (то есть, CPU) плюс всякая неинтересная хрень (память и тому подобное) подключенная к этому FSM через шину.

И потому любой нетривиальный алгоритм для нас это тоже FSM. Любой код на Си можно преобразовать в FSM+память.

Кластер налагает ряд ограничений, например, на то что можно использовать в оракловой базе. Пайпы и т.п. в RAC не будут работать. Подходы к управлению производительностью и многое другое отличаются для standalone db и для clustered db.

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

А то, что x86 серверы стоят сильно дешевле и будущее за ними - очевидно. Так же, как и то, что будущее за дешёвым аутсорсом (где на одного гуру приходятся десятки «негров»-студентов), а не за квалифицированными высокооплачиваемыми собственными админами. Вопрос только в том, насколько это хорошо. И вообще, вопрос в том, стоит ли проводить «оптимизацию» бизнеса, направленную исключительно на снижение издержек. Может быть, лучше направлять усилия на то, чтобы бизнес приносил больше выручки? :)

Значит так, либо Вы немедленно берете себя в руки и ведете себя прилично - либо я нахрен закрывают топик от анонимусов.

Топик читается очень пятнично, если FSM расшифровывать не как Final State Machine, а как Flying Spaghetti Monster.

Т.е. нагрузка должна поддерживать кластеризацию, что не всегда реализуемо.

Вопрос в том насколько часто это не реализуемо. Я понимаю что гораздо проще отвалить кучу бабла и дать умным дядям решить все проблемы.

чтобы бизнес приносил больше выручки

Все об этом мечтают :) Когда ты начинаешь бизнес он не станет приносить сразу много бабла. Он может вообще не приносить существенного заработка N лет. Ты не можешь взять и купить большую тачку, придётся брать то на что деньги есть. И если на этом этапе сделать масштабируемую архитектуру то проблемы производительности будут решаться докупкой нового железа.

Т.е. можно деньги вкладывать в железо, а можно в ПО. Тут уж кому что больше нравится. Я считаю что надо искать баланс.

А что такое «final state machine»?!?

Сергей, привет! А я тебе вопрос google hangouts задал, ты не хочешь на него отвечать?

*Finite

как-то так

Да что уж там, давайте сразу finite automata, как в лучших курсах Стэнфорда :)

Оно всё ж таки конечный, а не конченый автомат. Мож я английского не знаю, но final state machine у меня подсознание перевело как-то так.

automata

finite automaton. Automata — это множественное число.

Вопрос в том насколько часто это не реализуемо. Я понимаю что гораздо проще отвалить кучу бабла и дать умным дядям решить все проблемы.

Лично я это видел в жизни, в банковской среде, в телеком индустрии. Как правило, это большая (десятки и сотни терабайт данных) оракловая база с логикой внутри, десятки тысяч сессий и всё это в итоге на одном физическом сервере. Конечно же, пока это не x86

Что касается оптимизации - это моя больная мозоль. Не хочу заниматься, но приходится...

десятки и сотни терабайт данных

десятки тысяч сессий

на одном физическом сервере

Неужели это нельзя разбить шардингом? На вопрос «зачем» отвечу «чтоб дешевле».

Пайпы и т.п. в RAC не будут работать.

Что такое «пайпы»?

Automata — это множественное число.

Вот это поворот :( (c) hizel

тьфу, очепятка ессно

Ой, а я его не увидел. Где?

В mail.google.com не отображается слева в нижней половине экрана?

Вообще, я думал придёт уведомление на gmail. Видимо, это не всегда работает.

Ну на моих таблетке и мабиле не пришло ничего.

Понял. Долго стеснялся, но таки написал на gmail.

Неужели это нельзя разбить шардингом?

Чем разбить?

Оракловые конвейры или пайпы: http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_pipe.htm

Чем разбить?

Руками на этапе проектирования и внедрения.

Оракловые конвейры или пайпы

Честно говоря, вижу какой-то адский код на смеси бейсика, sql и c. Но вот почему на RAC не работают эти pipes я не понял. Смахивает на урезание продукта, оракл это любит. И вообще, такие вещи давно обкатаны. Берёшь какой-нить большой enterprise message bus и обмениваешься данными между любыми тачками, а не только локально команды дёргаешь.

Cегодня увидел у Алексея Тутубалина призыв читать обновленные мануалы по оптимизации (призыв здесь: http://blog.lexa.ru/2013/09/05/ne_prokhodite_mimo.html , мануалы здесь: http://www.agner.org/optimize/#manuals ).

Про оптимизацию работы с памятью я как-то спрашивал на лоре, но мне по наивности тогда казалось что есть инструменты или библиотеки для начинающих оптимизаторов. Например, спрашиваешь у библиотеки: «а сколько взять памяти чтоб не промазывать мимо кэша?» и она тебе рассказывает. Или вообще - даешь инструменту алгоритм (на инструментовском языке), а он тебе рассказывает как его красиво сделать.

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

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

Касательно RAC - эта хрень ведь не просто так стоит своих денег и по сути не имеет аналогов. Скорее всего дело не в искусственных ограничениях.

Этот вопрос лучше задать спецам по большим ораклам, а я не DBAшник, мне только вершки известны.