Да, вы правы, спасибо за подсказку. Действительно nop-ы добавляют 7 тактов. Судя по всему, они используются для какой-то синхронизации load-store.Тема nop-ов для синхронизации в e2k мало где прояснена, и требуется дополнительный анализ, насколько это влияет.
Впрочем, в других примерах https://ce.mentality.rip/ выдает меньше задержек nop-ами, например, для процедуры Sort 28 задержек nop на 36 широких команд (против 7 на 6). Так что по-прежнему кажется, что стоит проанализировать код посложнее, прежде чем сделать выводы
В примере результата компиляции под e2k широких команд 6 (широкие команды выполняются за такт, в ассемблере они в фигурных скобках, согласно мануалу), а не 13. Отсюда, неверный вывод, что это займет 13 тактов (должно быть 6).
Хотя у x86 получается всего 8 операций, скорее всего он выполнит их быстрее, чем за 8 тактов. Так что примерно паритет, Эльбрус чуть проиграет из-за более низкой частоты.
Но эти числа (6 и 8) слишком маленькие, чтобы делать какой-то далеко идущий статистический вывод. Хотелось пример хотя бы немного сложнее.
Идея транслировать какую-нибудь общепринитую ISA во внутренний VLIW жива до сих пор. Помимо Эльбрус-2000 есть еще NVidia Denver - ядра общего назначения, исполняющие код для ARMv8.
В опциях поиска можно указать образец картинки (URL образца или вставить саму картинку). Опции открываются, если нажать кнопку с фотоаппаратом рядом с кнопкой Найти.
Аналогичное есть и Гугла, но, имхо, Яндекс ищет картинки лучше, чем Гугл.
Был таким, к сожалению. Чатсо встречаются компании, где 1, 2, 3, 6 фактически являются обязанностями лида разработчиков, а 8, 9, 10 идут уже как сдедствия.
Если коротко, то BSD — это набор концепций и API системы. Реализация ядра может быть сделана на основе некоего эталона (FreeBSD), так и «с нуля». Причем совместима только на уровне исходников (и то теоретически), а не бинарно.
Грубо говоря, у macOS X+ свое микроядро, а некоторые подситемы взяты из FreeBSD, NetBSD и др.
Закопайте назад эту статью! Эта проблема уже давно пофикшена (с 8u131 экспериментально и с 8u191 окончательно). Даже в приведенной вами статье добавлена сноска про фикс.
Данная статья вообще не про это, а вообще непонятно про что про типы памяти JVM, и что нативный не-Java код (сюрприз! сюрприз!) не обращает внимания ни на Xmx с Xms и прочими параметры памяти, назначенные JVM, ни вообще на количество доступной памяти, а тем более cgroups, если его разработчик отдельно об этом не подумал.
Это специфичное приложение на Motorola Milestone. Могу выложить APK, но вряд ли оно еще где-то заработает (завязано на док, датчик магнитного поля и пр.)
А где в голосовалке «Нашел им новое применение»?
Из моего Milestone получились часы-будильник с прогнозом погоды, на следующем ZTE пока только Debian стоит и 4-я sim-ка, а еще один совсем сдохший пришлось утилизировать через программу утилизации у Tele2.
2 виртуальные машины в приложении на Android — JVM и Mono
А почему это записано в недостатки? Они же параллельно работают, а не одна в другой docs.microsoft.com/ru-ru/xamarin/android/internals/architecture
К тому же у React JavaScript VM не записана в минусы, а в случае Android JVM там тоже будет присутствовать.
Интересно, как вы написали бы «код, который приведёт процесс в известное состояние». Ведь чтобы прийти в «состояние» нужно освободить выделенную память, а для этого нужно знать все указатели, по которым она была выделена (сложно) и порядок выделения. А так как среди них, вероятно, есть указатели, которые приводят к SEGFAULT (уже приводили), то придется постоянно отлавливать SEGFAULT и продолжать процесс возвращения в состояние заново.
Короче, это а) сложно, б) медленно, в) ненадежно. И чревато утечками памяти.
Гораздо проще сохранять ценные данные в постоянную память на регулярной основе.
Кстати, по поводу утечек. Swap способен продлить uptime процесса с умеренно растущими утечками — он будет складировать на диск неиспользуемые «утекшие» страницы, оставляя «живые» страницы в оперативной. В итоге будет расти занимаемый объем swap, а не оперативной памяти
Возможно много ситуаций, где swap будет вреден. Например, когда необходим быстрое пробуждение давно ждущего процесса. Система может выгрузить старый «ждущий» процесс в swap, и быстрого отклика вы не получите.
Но это всё специфичные случаи, а в среднем swap скорее полезен, чем вреден. Особенно для домашнего пользователя
Сценарий с кучей вкладок в барузере — идельный вариант использования swap. Ценная оперативная память отдается по максимуму тем вкладкам, что использовались недавно. А старые можно сгрузить на диск.
Исключением будет, если вы постоянно переключаетесь между всеми вкладками в хаотичном порядке.
Кстати, Chrome теперь сам сгружает на диск неисользуемые вкладки и сам почти не попадает в swap.
Тоже пользуюсь ноутбуком 10-летней давности (Dell) как основным, без подстраховок.
Только поменял в нем ЖД на SSD, добавил чуток оперативки и поменял WIndows на Ubuntu MATE.
IDEA + браузер = полет нормальный. Весь секрет: не более 5 вкладок в браузере (а зачем больше?)
А для виртуалок, серверов и докера есть облака
Да, вы правы, спасибо за подсказку. Действительно nop-ы добавляют 7 тактов. Судя по всему, они используются для какой-то синхронизации load-store.Тема nop-ов для синхронизации в e2k мало где прояснена, и требуется дополнительный анализ, насколько это влияет.
Впрочем, в других примерах https://ce.mentality.rip/ выдает меньше задержек nop-ами, например, для процедуры Sort 28 задержек nop на 36 широких команд (против 7 на 6). Так что по-прежнему кажется, что стоит проанализировать код посложнее, прежде чем сделать выводы
В примере результата компиляции под e2k широких команд 6 (широкие команды выполняются за такт, в ассемблере они в фигурных скобках, согласно мануалу), а не 13. Отсюда, неверный вывод, что это займет 13 тактов (должно быть 6).
Хотя у x86 получается всего 8 операций, скорее всего он выполнит их быстрее, чем за 8 тактов. Так что примерно паритет, Эльбрус чуть проиграет из-за более низкой частоты.
Но эти числа (6 и 8) слишком маленькие, чтобы делать какой-то далеко идущий статистический вывод. Хотелось пример хотя бы немного сложнее.
Да и в целом в статье много сумбура и манипуляций
Loongson перейдет на свою собственную ISA
На MIPS пока остаются или еще не объявили о планах его оставить только PEZY и Ingenic.
MIPS будет жить еще, наверное, лет 10-20, но как второстепенная архитектура
Идея транслировать какую-нибудь общепринитую ISA во внутренний VLIW жива до сих пор. Помимо Эльбрус-2000 есть еще NVidia Denver - ядра общего назначения, исполняющие код для ARMv8.
У меня даже в "классическом" Palemoon эта кнока есть.
https://yandex.ru/images/
В опциях поиска можно указать образец картинки (URL образца или вставить саму картинку). Опции открываются, если нажать кнопку с фотоаппаратом рядом с кнопкой Найти.
Аналогичное есть и Гугла, но, имхо, Яндекс ищет картинки лучше, чем Гугл.
Ой, оказывается, это уже разбирали на Хабре: habr.com/ru/post/198016
Если коротко, то BSD — это набор концепций и API системы. Реализация ядра может быть сделана на основе некоего эталона (FreeBSD), так и «с нуля». Причем совместима только на уровне исходников (и то теоретически), а не бинарно.
Грубо говоря, у macOS X+ свое микроядро, а некоторые подситемы взяты из FreeBSD, NetBSD и др.
Данная статья вообще не про это, а
вообще непонятно про чтопро типы памяти JVM, и что нативный не-Java код (сюрприз! сюрприз!) не обращает внимания ни на Xmx с Xms и прочими параметры памяти, назначенные JVM, ни вообще на количество доступной памяти, а тем более cgroups, если его разработчик отдельно об этом не подумал.Из моего Milestone получились часы-будильник с прогнозом погоды, на следующем ZTE пока только Debian стоит и 4-я sim-ка, а еще один совсем сдохший пришлось утилизировать через программу утилизации у Tele2.
А почему это записано в недостатки? Они же параллельно работают, а не одна в другой docs.microsoft.com/ru-ru/xamarin/android/internals/architecture
К тому же у React JavaScript VM не записана в минусы, а в случае Android JVM там тоже будет присутствовать.
С удовольствием почитал бы вашу статью про работу с памятью в Chrome(ium)))
Короче, это а) сложно, б) медленно, в) ненадежно. И чревато утечками памяти.
Гораздо проще сохранять ценные данные в постоянную память на регулярной основе.
Но это всё специфичные случаи, а в среднем swap скорее полезен, чем вреден. Особенно для домашнего пользователя
Исключением будет, если вы постоянно переключаетесь между всеми вкладками в хаотичном порядке.
Кстати, Chrome теперь сам сгружает на диск неисользуемые вкладки и сам почти не попадает в swap.
Только поменял в нем ЖД на SSD, добавил чуток оперативки и поменял WIndows на Ubuntu MATE.
IDEA + браузер = полет нормальный. Весь секрет: не более 5 вкладок в браузере (а зачем больше?)
А для виртуалок, серверов и докера есть облака