Size: a a a

2020 July 05

KK

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

KK

Kirill (Cykooz) Kuzm... in rannts
В x86 накопилось слишком много легаси, которое наверняка тормозит его. И наверное делает дороже.
источник

SZ

Sergey Z in rannts
Kirill (Cykooz) Kuzminykh
Есть идея что эпоха x86 заканчивается. И есть вероятность что скоро все мы будет на АРМ, как только винда туда тоже свинтит.
Если и так то будет как с флешем, 15 лет хоронили, и вот только на днях сам Adobe наконец его закопал
источник

ИК

Иван Кривошеев... in rannts
Kirill (Cykooz) Kuzminykh
В x86 накопилось слишком много легаси, которое наверняка тормозит его. И наверное делает дороже.
Интел создавал новые архитектуры после x86... Не зашло
источник
2020 July 06

KK

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

KK

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

in

ildar nizamov in rannts
Kirill (Cykooz) Kuzminykh
По последним новостям - ТОП 500 суперкомпьютеров  возглавил комп Фуджитсу построенный на ARM атрхитектуре. Он почти в три раза опережает "второе место" (там комп от IBM).
суперкомпы очень специфичная штука. сейчас одна из ключевых основная проблема - энергоэффективность(флопс на ватт). прототип Fugaku занял в ноябре первое место в green500, сейчас 9, сразу за той самой машиной IBM.
источник

in

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

in

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

ИК

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

KK

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

KK

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

in

ildar nizamov in rannts
только что было же
источник

in

ildar nizamov in rannts
источник

SZ

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

KK

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

AS

Artem Savinov in rannts
типа сборщика мусора жабы? или это не о том?
источник

RH

Roman Haritonov in rannts
Kirill (Cykooz) Kuzminykh
А может уже кто-то сделал дефрагментатор? По идее устройство встроенных типов данных известно - можно хотя бы их перемещать безопасно. Самое ресурсоёмкое там будет конечно поиск всех объектов, которые ссылаются на тот, который требуется переместить. Но я даже на такое готов пойти - всё равно у приложения есть моменты простоя, когда оно ничего не делает.
А простой gc.collect не помогает? У меня в одном асинхронном сервисе пришлось делать периодический вызов, иначе память утекала. Там было из-за циклических ссылок, которые gc.collect хорошо собирал
источник

KK

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

KK

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