switch-based диспетчеризация — не лучший способ написать интерпретатор. Помимо того, что компилятор может не соптимизировать switch в таблицу, на каждую инструкцию байт-кода приходится минимум 2 перехода: в начало цикла и по адресу обработчика инструкции. Direct-threading подход заметно лучше, там в каждом обработчике идет чтение следующей инструкции и переход, так что одна инструкция — один переход. Еще есть на основе базовых блоков диспетчеризация, но это уже к компиляции ближе.
Вот тут можно почитать (применительно к java-байткоду): webdocs.cs.ualberta.ca/~amaral/cascon/CDP05/slides/CDP05-berndl.pdf
Это если будете развивать дальше эту историю.
У вас просто какой-то идеальный ребенок. Бывают дети, у которых в первый год только 2 режима: висеть на источнике питания и орать. И смесь вроде только 20 минут годна, потом ее нужно употребить и выкинуть. Во время колик орал 15 минут — такое вообще бывает? Когда я клал ребенка и бутылочку с водой, то просыпался не утром, а ночью, и бутылочка тоже была пуста, а содержимое — подо мной и под ребенком. Ребенок пересел вам на шею до года — то, что он еще жив, вам несказанно повезло. И еще в статье нет радостей тоддлерства — когда пальцы в розетку, кота за хвост, есть из мусорного ведра весело, из кошачьей миски — тоже, пеленки с сушилки сдергивать — еще веселее, телефон об пол, кастрюли из шкафа, кухня после того, как ребенок «поел» — просто как поле боя, которое надо 4 раза в день оттирать, отмывать, отчищать, а ребенок тем временем орет в кроватке, и когда ты к нему наконец придешь, в тебя летит какашка (!), одна из тех, что размазаны по кровати… А в районе 1.5 лет — тоже красота, не разрешил есть крем для жопы — истерика, запретил лезть пальцем в жопу коту — истерика, голову мыть — истерика с рвотой и оттиранием оной, вместо сна — кувыркание в постели, потом снова рвота, перестирывание постельного белья до 2х ночи… в районе 2х лет — это не хочу, это не буду, буду есть одни конфеты, голову мыть по-прежнему нельзя, поесть, чтобы тебе не залезли в тарелку — тоже не получится, шмон холодильника… короче писос это таки
двоичное возведение в степень делается проще, без разложения на степени двойки (точнее, разложение присутствует неявно):
def binpow(m: Matrix, pow: Int): Matrix = {
assert(pow >= 0, "pow must be non-negative")
if (pow == 0) Matrix.identity
else if (pow == 1) m
else {
val p = binpow(m, pow / 2)
if (pow % 2 == 0) p * p
else m * p * p
}
}
Спасибо за ссылку, утянул к себе в закладки.
В дополнение к статье по ссылке могу добавить, что jmp на холодный бранч — это он в интерпертатор сразу прыгает (который, к слову, в хотспоте так себе сделан)
С BPU на оптимизации компилятора можно эффективно пересесть, если у вас JIT. Тот может сделать branch prediction за процессора, наиболее вероятное место перехода заинлайнить под if и этот if спрямить например (спекулятивным исполнением), что openjdk например и делает. Это дает возможность относительно эффективно прыгнуть за косвенный вызов (по указателю, или через таблицу виртуальных функций, что одно и то же). Если компилятор статический, то он такого делать не умеет, и косвенные вызовы автоматом стопают конвейер и становятся дорогими.
чтобы можно было подкачать и спекулятивно начать исполнять код из вероятного места прыжка, одновременно проверяя правильность предсказания, и в случае чего, то, что спекулятивно наисполнялось — выкинуть. Короче, чтоб конвейер в большинстве случаев не простаивал.
Еще немного дополню из собственного опыта, кому-то может помочь, другим, надеюсь, не повредит: при высокой тревоге помогает отказаться от кофе, совсем. А при тревожности — информационный «детокс», то есть читать что-то спокойное, умиротворяющее, как минимум нейтральное, а про всякое саморазвитие и джедайские техники лучше отложить.
И еще, тут недавно пост был на хабре про уставшую лошадь. Стоит к себе быть бережнее в общем.
потому что слой пенопласта, который будет способен выдержать нужный вес, будет большим и толстым, и за грунт цепляться нужно все равно. Сваи будет дешевле, легче и надежнее.
вот отсюда: d-russia.ru/wp-content/uploads/2017/04/siis2017_UNIPRO.pdf
Пилили 4 года (2013-2017), больше об этом не слышно. Если взять сравнение (строка «Общий счет») и поделить на 4 (разница в тактовых частотах), получится, что Эльбрус в 1.25 раза хуже интела 10летней давности в среднем, хотя VLIW, параллельность, вот это все.
Это пройдёт — рановато ИДЕЮ начали реализовывать, время ещё не пришло
Идее уже десятки лет, и как минимум 2 реализации. Одна (Itanium) — все, потому что не выгодно, другая (Эльбрус) — еще нет, потому что другого своего все равно ничего нет.
Мне кажется, что из скрытого параллелизма выжали уже все, что можно (оптимизирующий компилятор, суперскалярность, предсказатель переходов), дальше крупицы по 10% выжимать — оверхед по стоимости, и оно того не стоит.
Плюс учитываем современные реалии. Java на Эльбрусе работает где-то в полтора раза хуже, чем на интеле, даже если бы он работал на частоте Эльбруса — это конечно финиш. И лучше похоже не сделать. Сразу весь hadoop/spark стек можно выкинуть, и остаемся без больших данных. Либо пилить свои велосипеды на C++, что дорого и никому не нужно.
1) да, у вас оптимальнее
2) объясню свое решение, ваше не понял) у нас есть поток событий — успех/неудача, 0/1 с равной вероятностью, у обоих. Теперь найдем вероятность получить удовольствие. Для первого — это переход 1 -> 1, для второго — 0 -> 1, т.е для первого события вероятность получить удовольствие 0, для второго и последующих — 1/4 для обоих. Так как нам требуется разницу матожиданий найти, то очевидно, что разница матожиданий для одинаковых потоков событий равна 0
мне кажется, действительно за sql зарубили. Прямо даже написали, подтянуть sql. SQL для аналитика данных — мастхэв.
А в компании со словом газ в названии берут за красивое резюме и красивый опыт работы, оценить же все равно не могут, критериев не знают. В трудовой же не пишут, что простейшие проблемы неделю исправлял, и сам он этого не скажет. Но зато условному инженеру по газу там наоборот, на собесе душу вынут и во вторичный рот заглянут
Вот тут можно почитать (применительно к java-байткоду): webdocs.cs.ualberta.ca/~amaral/cascon/CDP05/slides/CDP05-berndl.pdf
Это если будете развивать дальше эту историю.
gcc -funroll-loops ..., не?
В дополнение к статье по ссылке могу добавить, что jmp на холодный бранч — это он в интерпертатор сразу прыгает (который, к слову, в хотспоте так себе сделан)
И еще, тут недавно пост был на хабре про уставшую лошадь. Стоит к себе быть бережнее в общем.
Пилили 4 года (2013-2017), больше об этом не слышно. Если взять сравнение (строка «Общий счет») и поделить на 4 (разница в тактовых частотах), получится, что Эльбрус в 1.25 раза хуже интела 10летней давности в среднем, хотя VLIW, параллельность, вот это все.
Идее уже десятки лет, и как минимум 2 реализации. Одна (Itanium) — все, потому что не выгодно, другая (Эльбрус) — еще нет, потому что другого своего все равно ничего нет.
Мне кажется, что из скрытого параллелизма выжали уже все, что можно (оптимизирующий компилятор, суперскалярность, предсказатель переходов), дальше крупицы по 10% выжимать — оверхед по стоимости, и оно того не стоит.
Плюс учитываем современные реалии. Java на Эльбрусе работает где-то в полтора раза хуже, чем на интеле, даже если бы он работал на частоте Эльбруса — это конечно финиш. И лучше похоже не сделать. Сразу весь hadoop/spark стек можно выкинуть, и остаемся без больших данных. Либо пилить свои велосипеды на C++, что дорого и никому не нужно.
2) объясню свое решение, ваше не понял) у нас есть поток событий — успех/неудача, 0/1 с равной вероятностью, у обоих. Теперь найдем вероятность получить удовольствие. Для первого — это переход 1 -> 1, для второго — 0 -> 1, т.е для первого события вероятность получить удовольствие 0, для второго и последующих — 1/4 для обоих. Так как нам требуется разницу матожиданий найти, то очевидно, что разница матожиданий для одинаковых потоков событий равна 0
А в компании со словом газ в названии берут за красивое резюме и красивый опыт работы, оценить же все равно не могут, критериев не знают. В трудовой же не пишут, что простейшие проблемы неделю исправлял, и сам он этого не скажет. Но зато условному инженеру по газу там наоборот, на собесе душу вынут и во вторичный рот заглянут