Не пробовал. Винды и кубунты мне достаточно. Никто не говорит, что медленный запуск, а вот то, что медленнее чем могло бы быть, зато можно понтануться "на 1 дискете"... В детстве у меня были диски "1000 игр на одном", но те времена уже прошли. Игры стали сложнее и их просто нереально писать на асме. Не говоря про портируемость. Сейчас во главе угла стоят человекочасы, а не машинное время. Написали приложение на C#, чуть-чуть ксамарина и перенесли на iOS, чуть-чуть монодройда и перенесли на андройд. А асм такого никогда в жизни не допустит. Антивирус касперского занимает 2млн сишного кода, если каждая строка сишного кода эквивалентна примерно 5-10 ассмовским, то... Сами посчитаете? И кто этого монстра отлаживать будет и баги вылавливать? Я писал на pascal\delphi\C\C++\C#\TASM\Ruby\F#\Scala и могу достаточно полно судить об идиотизме такого подхода. Напоминает возврат "в пещеры", а что? Ни кредитов за неё платить не надо, ни за отопление, никакого загрязнения ОС...

Стоит попробовать... Мне аж ассемблер захотелось выучить

Ассемблер допустит при условии что проц будет темже(без смены архитектуры с х86 на любой другой), так как привязки к внешним библиотекам отсутствуют(правда пошаманить и так нужно будет).
Вон у первого фотошопа ответственная часть была на асме - старались люди

В интернете. Найти сравнение в 7zip и x264 на ARM и x86 проблем никаких.
Дела индейцев шерифа не волнуют.
Кто куда "портированы"? Ничего не понял.

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


от того там и столько строк, что половина из этого это костыли.

вот тут самая главная фишка.
7зип жрет все доступные ядра и высокие мегагерцы х86 - тест не актуален.
пример сравнения амд и интла в этом тесте - 4*2 и 4+4 проигрывают последние (ака интел) амд берет - высокой частотой и "большим" количеством алу.
х264 - тест строго зацикленный на оптимизациях и ядрах - я не думаю что его хорошо кто то про оптимизировал для армов. (блага я тут уже приводил выкладки по х264 - даже в этой теме) так что А9 уступает ксенки в 6 раз - при этот жрет меньше 5 ватт (когда ксенка жрет все 100).

линукс на армы и вмести сними большинство софта.

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

И что там универсального? Типа подсунь ему бинарник от АРМ и он будет работать? Или то что можно не задействовать все его новейшие SSE4+, ограничившись простым SSE и MMX? Как будто под АРМ нельзя собрать без поддержки скажем NEON(в Тегра 2 нет NEON только FPU)
Может подскажете что есть такое не х86-специфическое что не "пережует" АРМ?

neon класная вещь. mpg123 с этими инстркукциями очень быстро работает, и ffmpeg тоже. в отличае от бесполезных костылей sse2-4. и чего его к x86 не прекрутят.

У больших систем есть видяхи, которые не греясь пережёвывают UHD. В некоторых случаях - встроенные прямо в проц. Зачем делать ненужные костыли?

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

terenty79
Тринитишная встройка нормально пережёвывает UHD, если плеер использует аппаратное ускорение.

только недавно в mpc-be это поправили, а то при перемотке висло и на зелёные квадраты, через один рип mkv сыпался. не уверен что это опять не случится, через какое то время.

Что странно, ведь LA, использующий немного модифицированный код mpc, нормально всё пережёвывает ещё с беты 4.6.7

есть другой плеер, он мне ещё больше mpc нравится. splash pro. в нём с апаратным декодингом ни разу ни одного косяка не было. но там есть куча улучшителей картинки, которые сразу же апаратный декодер вырубают. и всё через основной проц прокачивается.

terenty79
Ну можно использовать связку MPC+MadVR или тот же LA+MadVR, тогда вся нагрузка будет на видеоподсистеме. При этом видеоподсистема будет не сильно грузиться и совсем не греться.
А улучшатели и повыключать можно. Они не совсем оправданы при просмотре UHD, имхо...

Честно говоря, сам был немного удивлен. Ну а отличие от C++ элементарное: все намного проще. Но лично я побаловался во всем этим и вернулся обратно на шарп. Лямбд шарпа вполне достаточно для реализации 99% функционального программирования, благо там и замыкания работают, и все прочее. Конечно вещей, вроде активного сопоставления с образцом (типа switch case 80 lvl) или каррирования нету, но есть свои механизмы, не хуже. Например, вам нужно выбрать из массива элементы, подлежащие какому-то условию, после этого возвести их в квадрат, сгруппировать по какому-нибудь признаку и отсортировать. На шарпе (и функц. языках, вроде скалы) это будет выглядеть так:

что мы видим: автоматический вывод типа, немножко лямбд и вуаля - задача решена в 1 строку.
сколько это займет на C/C++?
Хотя скажу честно, без вывода типа даже на шарпе это выглядело бы примерно так:

А на С++ и того хуже

если там будет не 20 млн асмовского кода, а 10, это сильно все изменит?

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