Помнится когда начинал изучать Rust, написал небольшую программку, которая считала что-то (площадь которую покрывают 100500 рандомных прямоугольников, которые могут пересекаться). Так вот эта штука на моём андроид телефоне работала быстрее раза в 1.5 чем на десктопном Intel i7 .

В x86 накопилось слишком много легаси, которое наверняка тормозит его. И наверное делает дороже.

Если и так то будет как с флешем, 15 лет хоронили, и вот только на днях сам Adobe наконец его закопал

Интел создавал новые архитектуры после x86... Не зашло

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

По последним новостям - ТОП 500 суперкомпьютеров  возглавил комп Фуджитсу построенный на ARM атрхитектуре. Он почти в три раза опережает "второе место" (там комп от IBM).

суперкомпы очень специфичная штука. сейчас одна из ключевых основная проблема - энергоэффективность(флопс на ватт). прототип Fugaku занял в ноябре первое место в green500, сейчас 9, сразу за той самой машиной IBM.

вообще, интересно. кажется, что японцы "тупо" деньгами залили проблему. в три раза выше производительность, но и ядер, и kW тоже в три раза больше :)

а чем принято lua-объекты в python3-объекты преобразовывать? нужно считать luarocks-манифест, там lua-шная табличка вроде. есть альтернативы https://github.com/IlyaSkriblovsky/slpp-23 ?

Нет, просто никто не хотел перекомпилировать тонну кода.

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

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

только что было же

жуть

А может уже кто-то сделал дефрагментатор? По идее устройство встроенных типов данных известно - можно хотя бы их перемещать безопасно. Самое ресурсоёмкое там будет конечно поиск всех объектов, которые ссылаются на тот, который требуется переместить. Но я даже на такое готов пойти - всё равно у приложения есть моменты простоя, когда оно ничего не делает.

типа сборщика мусора жабы? или это не о том?

А простой gc.collect не помогает? У меня в одном асинхронном сервисе пришлось делать периодический вызов, иначе память утекала. Там было из-за циклических ссылок, которые gc.collect хорошо собирал

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

Я к тому же анализировал чем память занята в рантайме, при этом вызывается gc.collect() и общее потребление меньше не становилось