Рекомендация не делить задачи до конца выполняется — константа BASE=500, это значит, примерно за 500 порядков до конца выполнить все в 1 поток.
Я пробовал поднимать до 5000, но тогда теряется смысл ForkJoinPool и задача вырождается в ExecutorService.
Как я понял, конкретно к моей задаче FJP не подходит, т.к. она прекрасно решается в 4 потока, и не нужно создавать много-много тасков.
/usr/lib/jvm/java-7-oracle/bin/java -server -Xss512m -Xms14g -Xmx14g -verbose:gc -XX:+PrintCommandLineFlags org.relgames.test.ForkJoinFarey
-XX:InitialHeapSize=15032385536 -XX:MaxHeapSize=15032385536 -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:ThreadStackSize=524288 -XX:+UseCompressedOops -XX:+UseParallelGC
So far created 10m objects
So far created 20m objects
So far created 30m objects
So far created 40m objects
[GC 3670016K->1945266K(14068416K), 2,0751280 secs]
So far created 50m objects
So far created 60m objects
So far created 70m objects
So far created 80m objects
[GC 5615282K->4063530K(14068416K), 3,6028590 secs]
So far created 90m objects
So far created 100m objects
So far created 110m objects
So far created 120m objects
So far created 130m objects
[GC 7733546K->6251762K(14068416K), 2,9401630 secs]
So far created 140m objects
So far created 150m objects
So far created 160m objects
So far created 170m objects
[GC 9921778K->8448538K(14068416K), 6,7024830 secs]
[Full GC 8448538K->8417111K(14068416K), 44,8352310 secs]
So far created 180m objects
Total 189980091 in 75545ms
Process finished with exit code 0
А вот ExecutorService:
Скрытый текст
/usr/lib/jvm/java-7-oracle/bin/java -server -Xss512m -Xms14g -Xmx14g -verbose:gc -XX:+PrintCommandLineFlags org.relgames.test.ExecutorFarey
-XX:InitialHeapSize=15032385536 -XX:MaxHeapSize=15032385536 -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:ThreadStackSize=524288 -XX:+UseCompressedOops -XX:+UseParallelGC
So far created 10m objects
So far created 20m objects
So far created 30m objects
So far created 40m objects
So far created 50m objects
So far created 60m objects
So far created 70m objects
[GC 3670016K->3394274K(14068416K), 3,1145380 secs]
So far created 80m objects
So far created 90m objects
So far created 100m objects
So far created 110m objects
So far created 120m objects
So far created 130m objects
So far created 140m objects
[GC 7064290K->6877242K(14068416K), 4,8985740 secs]
[Full GC 6877242K->6851983K(14068416K), 30,8669940 secs]
So far created 150m objects
So far created 160m objects
So far created 170m objects
So far created 180m objects
Total 189980091 in 53641ms
Process finished with exit code 0
Если вычесть время на GC, получается 15 секунд у FJP против 14 у ExecutorService
Но его нельзя вычитать — получается, FJP производит больше мусора, чем ExecutorService
Попробовал compute — действительно быстрее, ряд из 7600459 элементов сгенерился за 8 секунд (против 3 секунд на Executor-ах, или против 10 минут на fork, fork, join, join)
1 — зачем? Мне не нужно сферическое измерение в вакууме, мне нужна реализация, которая быстро считает числа Фарея. 100мс и 10секунд — это огромная разница, никакой второй запуск не поможет.
2 — так и сделал в варианте с ExecutorService. Но вопрос-то в другом! Ведь Fork/Join было специально придумано для подобных задач, когда задачи добавляются из самих задач. Почему же такие тормоза?
Пробовал xfce, после Gnome раздражают мелочи, типа — нельзя искать файлы из Thunar. В Gnome нажимаешь Ctrl+F и ищешь, в Thunar нужно совершать некие телодвижения, это очень неудобно.
У меня постоянно открыто несколько окон, развернутых и нормальных, без панели задач это превращается в кошмар, что на одном мониторе, что на двух. Плюс в трее сидит постоянно keepassx и parcellite, они не дружат с юнити и его indicator applet. В принципе, меня все устраивает в Gnome Classic, но вот постоянные баги при обновлении… :(
У меня на другой машине тоже все работает. А вот тут не работает.
Поведение клавиш Alt/Win — стоит Default
Super+<любая клавиша> не работает именно с Lock Screen. Остальные комбинации работают, например, Super+R вызывает Run Dialog и т.д.
Да, когда он строит реактор, этот модуль виден в списке. Скорее всего, придется вынести его отдельно. Но он содержит в себе зависимости на другие модули этого же проекта, поэтому изначально оставили в проекте.
командный репозиторий есть. отдельные артефакты мне не кажутся отличной идеей — мы делаем фреймворк, будет не очень здорово, если разные части фреймворка будут иметь разные версии. да и в целом, это единый проект, коммиты почти всегда содержат изменения из разных модулей, при этом эти модули обязаны быть разными — т.к. филиалы могут захотеть использовать, например, services, но веб-слой пишут полностью свой.
как откуда? из модели проекта, конечно же. когда компилируется мульти-модульный проект, мавен именно это и делает — строит граф зависимостей, компилирует первыми те модули, которые ни от чего не зависят, дальше компилирует зависящие и т.д. docs.codehaus.org/display/MAVENUSER/Multi-modules+projects
Пихать логгирование в объекты, которых миллион — не очень хорошая идея :) Но я уже сверху написал, что есть специфические случаи, когда без non-static логгера не обойтись. В целом меня убедили, что лучше использовать static поле, так что вопрос решен :)
Рекомендация не делить задачи до конца выполняется — константа BASE=500, это значит, примерно за 500 порядков до конца выполнить все в 1 поток.
Я пробовал поднимать до 5000, но тогда теряется смысл ForkJoinPool и задача вырождается в ExecutorService.
Как я понял, конкретно к моей задаче FJP не подходит, т.к. она прекрасно решается в 4 потока, и не нужно создавать много-много тасков.