Здравствуйте, ·, Вы писали:

V>>·>Ты просто споришь сам с собой, отвечая на вопросы, которые тебе никто не задавал и выдаёшь информацию вообще не в тему.
V>>Ты вообще кто такой, чтобы единолично ставить вопросы или задавать тему?
·>Если ты хочешь обсуждать поставленные в теме вопросы, обсуждай. Если ты хочешь ставить новые — иди в другую тему. А заниматься софизмом, отвечая свои же вопросы потоком тривиальщины в попытках сойти за умного — это ведёт к непониманию.

Это если голову не включать.

Например, часто массивы используются как indexed map, в этом смысле "уплотнение" по ссылке, скорее всего, всё ухудшит в сравнении с исходной последовательностью создания объектов при наполнении такого массива.

Я всё время забываю, что ты не воспринимаешь и половины даваемой тебе тривиальнейшей информации. ))
Приходится на пальцах.

Простой пример — в массиве содержатся отображения горизонтальной таблицы парсера или лексера после минимизации, т.е. отображения терминалов на некие объекты — нетерминалы.
Для лексера x = char, y = nterm.
Наиболее выгодно с т.з. хитов в память расположить y таким образом, чтобы сначала шли наиболее часто встречающиеся нетерминалы, потом всё реже и т.д., т.е. отсортировать в памяти согласно некоему прикладному знанию о характере обрабатываемых данных.
Но GC такой информацией не обладает, т.е. тупо отсортирует y согласно x, т.е. просто по алфавиту в этом примере.

ИМХО, тут даже объяснять особо ничего не надо, если голова на месте.

Как только тебе начинают рассказывать о некоей фиче, которая "сама" что-то делает, не обладая инфой о прикладном характере происходящего, так сразу должна включаться как минимум осторожность в рассуждениях.
Я же вижу строго обратное.
Т.е., "играя" инфой, умалчивая одни аспекты и выпячивая другие, ты ведешь де-факто некорректный спор.
Сознательно вводишь коллег в заблуждение.
Приходится за тобой прибирать, бо многие коллеги (и я в том числе) ходят сюда за пополнением своей технической эрудиции.
Ты же гонишь сплошное недостоверное фуфло.


V>>озвучивая свои заблуждения вслух, вы сами формулируете проблематику — "раскрыть внутренее устройство алгоритмов и/или структур данных".
·>Т.е. ты сам придумал вопрос, сам ответил.

Э, нет, "вопрос" придумал ты, ввиду недостаточности выдаваемой инфы о происходящем.
Независимо от того, по незнанию ли ты выдаёшь неполную инфу, или преднамеренно с целью спекуляций, раскрыть подробности происходящего будет полезным делом.
А вот юлить, бегать, оправдываться — бесполезным.


V>>Потому что, если включить объективность,
·>Вот наконец-то что-то касающееся темы обсуждения. Непонятно почему это было нельзя сказать сразу?

Ты пока на первый аргумент так и не смог адекватно ответить, а уже просишь следующих. ))
Это как с той "разметкой памяти", ты 10 постов не мог воткнуть в суть исходного вопроса, что тебе уже читатели замечания стали делать.
Не понял вопроса или аргумента — переспроси, а не возражай своим непониманием.
Ты же всё-равно тут аноним, "реноме" пострадает не сильно.


V>>то достаточно было просто напомнить, что уплотнение происходит при уборке 2-го поколения,
·>В той статье Шипилёва это и говорится, что мол, после срабатывания GC результаты другие.

У GC несколько этапов "срабатывания".
В фазе перемещения объектов stop world есть всегда, независимо того, какая конкретная стратегия GC используется.
У навороченных просто длительность одного stop world меньше, за счёт того, что самих их гораздо больше и общая производительность падает.


·>О поколениях вообще разговора у нас не было. Если ты это забыл или не прочитал... я-то тут причём? А в телепатию я не умею, уж извини.

В нулевом поколении GC умеет выделять память повторно без уплотнения, особенно если ссылки не убегают в другие потоки, т.е. когда объекты рождаются и умирают в пределах одного потока.
Причём, GC способен работать в таком режиме относительно долго, т.е. описанный по ссылке эффект может не наступить никогда.
И смысл тогда вообще этот булшит обсуждать?

Походу ты плохо понимаешь логику современных разработок, которые долгоиграющие и которые "на виду", как грится.
Ведущие разработчики таких проектов ОБЯЗАНЫ вести блоги.
Более того, если ты не умеешь вести "интересные" блоги, шанс попасть в ведущие разработчики/руководители подобных проектов резко ниже.
Такова се ля ви.
Чувак в основном занят написанием тестовых фреймворков.
(офигенно интересная работа, угу :facepalm
Периодически получает какие-то там результаты и добровольно-принудительно пишет обо всём этом "интересные" статьи.
И ты такой ты, натыкаешься на подобную добровольную принудиловку и показываешь реакции вчерашниго слепого щеночка, только что увидевшего солнце — рот открыл и застыл в немом удивлении. ))
Пффф...
Отключать критичность, таки, не следует, когда речь об инженерии.


·>Но в общем случае всякое бывает. Во-первых, это зависит от типа GC и настроек. Во-вторых, даже для "обычного" GC уплотнение произойдёт уже при копированиях в Eden/Survivors, ещё до 2го поколения.
·>Вот тут более детальное описание что и когда происходит.

Бггг...

It’s an old joke from the time when Java was new and slow compared to other languages. Over time, Java became a lot faster.

По отношению к самой себе тогдашней.
Но и конкуренты стали намного быстрее.

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

Fortunately, in many cases, it can be tweaked and optimized to improve performance.

И это в той подветке, где обсуждается невозможность управления трюком, о котором рассказано в предыдущей твоей ссылке.
Эдак тебя колбасит...
Ты сам хоть свои ссылки читаешь? ))

И вишенка на торте:

Let’s try another experiment. Let’s run an application that is only creating short-lived objects in multiple threads.
...
We can see that this time, the old generation received objects right after the first minor garbage collection.
...
The young generation garbage collector had no choice but to push these objects to the old generation. This is bad because the objects that got pushed to the old generation were prematurely aged and can only be cleaned up by old generation’s major garbage collection which usually takes more time. W

О чём я тебе несколько раз уже напоминал только в одной этом обсуждении, что стоит начать "бесконечно" производить объекты в разных потоках, и объекты улетают во 2-е поколение сходу. Этим страдает дотнет. Как видишь, этим страдает и джава тоже.

А дальше начинается и вовсе детсад:

How to prevent premature aging of short-lived objects? There are several ways.

И рассказываются способы, как тюнить GC.

Страна непуганых идиотов.
Или професиональных лжецов — на выбор.
Я склоняюсь ко второму.
Потому что стоит накатить "оттюненые" параметры GC на другое железо — с другим кол-вом ядер, другим кол-вом кеша 0-го и 1-го уровней в проце, другой длиной линейки кеша (а она "пляшет" от 64 байт то 512 байт) и всем, что прежде натюнили, можно смело подтереться.

А если еще какие-нить приложения на том же железе работают, или не работают, или имеют апериодическую нагрузку, то и вовсе это был булшит с самого что ни на есть начала.

Здравый смыл и простая инженерная честность видит такие вещи сходу.
И только профессиональные лжецы с умным видом кидают ссылки на такую же ложь и высокомерно (как им самим кажется) изрекают: "пойдите ознакомьтесь".
Это же палево, не?
А вдруг, действительно, ознакомятся?

Здравствуйте, ·, Вы писали:

V>>·>Ты просто споришь сам с собой, отвечая на вопросы, которые тебе никто не задавал и выдаёшь информацию вообще не в тему.
V>>Ты вообще кто такой, чтобы единолично ставить вопросы или задавать тему?
·>Если ты хочешь обсуждать поставленные в теме вопросы, обсуждай. Если ты хочешь ставить новые — иди в другую тему. А заниматься софизмом, отвечая свои же вопросы потоком тривиальщины в попытках сойти за умного — это ведёт к непониманию.

Это если голову не включать.

Например, часто массивы используются как indexed map, в этом смысле "уплотнение" по ссылке, скорее всего, всё ухудшит в сравнении с исходной последовательностью создания объектов при наполнении такого массива.

Я всё время забываю, что ты не воспринимаешь и половины даваемой тебе тривиальнейшей информации. ))
Приходится на пальцах.

Простой пример — в массиве содержатся отображения горизонтальной таблицы парсера или лексера после минимизации, т.е. отображения терминалов на некие объекты — нетерминалы.
Для лексера x = char, y = nterm.
Наиболее выгодно с т.з. хитов в память расположить y таким образом, чтобы сначала шли наиболее часто встречающиеся нетерминалы, потом всё реже и т.д., т.е. отсортировать в памяти согласно некоему прикладному знанию о характере обрабатываемых данных.
Но GC такой информацией не обладает, т.е. тупо отсортирует y согласно x, т.е. просто по алфавиту в этом примере.

ИМХО, тут даже объяснять особо ничего не надо, если голова на месте.

Как только тебе начинают рассказывать о некоей фиче, которая "сама" что-то делает, не обладая инфой о прикладном характере происходящего, так сразу должна включаться как минимум осторожность в рассуждениях.
Я же вижу строго обратное.
Т.е., "играя" инфой, умалчивая одни аспекты и выпячивая другие, ты ведешь де-факто некорректный спор.
Сознательно вводишь коллег в заблуждение.
Приходится за тобой прибирать, бо многие коллеги (и я в том числе) ходят сюда за пополнением своей технической эрудиции.
Ты же гонишь сплошное недостоверное фуфло.


V>>озвучивая свои заблуждения вслух, вы сами формулируете проблематику — "раскрыть внутренее устройство алгоритмов и/или структур данных".
·>Т.е. ты сам придумал вопрос, сам ответил.

Э, нет, "вопрос" придумал ты, ввиду недостаточности выдаваемой инфы о происходящем.
Независимо от того, по незнанию ли ты выдаёшь неполную инфу, или преднамеренно с целью спекуляций, раскрыть подробности происходящего будет полезным делом.
А вот юлить, бегать, оправдываться — бесполезным.


V>>Потому что, если включить объективность,
·>Вот наконец-то что-то касающееся темы обсуждения. Непонятно почему это было нельзя сказать сразу?

Ты пока на первый аргумент так и не смог адекватно ответить, а уже просишь следующих. ))
Это как с той "разметкой памяти", ты 10 постов не мог воткнуть в суть исходного вопроса, что тебе уже читатели замечания стали делать.
Не понял вопроса или аргумента — переспроси, а не возражай своим непониманием.
Ты же всё-равно тут аноним, "реноме" пострадает не сильно.


V>>то достаточно было просто напомнить, что уплотнение происходит при уборке 2-го поколения,
·>В той статье Шипилёва это и говорится, что мол, после срабатывания GC результаты другие.

У GC несколько этапов "срабатывания".
В фазе перемещения объектов stop world есть всегда, независимо того, какая конкретная стратегия GC используется.
У навороченных просто длительность одного stop world меньше, за счёт того, что самих их гораздо больше и общая производительность падает.


·>О поколениях вообще разговора у нас не было. Если ты это забыл или не прочитал... я-то тут причём? А в телепатию я не умею, уж извини.

Походу ты плохо понимаешь логику современных разработок, которые долгоиграющие и которые "на виду", как грится.
Ведущие разработчики таких проектов ОБЯЗАНЫ вести блоги.
Более того, если ты не умеешь вести "интересные" блоги, шанс попасть в ведущие разработчики/руководители подобных проектов резко ниже.
Такова се ля ви.
Чувак в основном занят написанием тестовых фреймворков.
(офигенно интересная работа, угу :facepalm
Периодически получает какие-то там результаты и добровольно-принудительно пишет обо всём этом "интересные" статьи.
И ты такой ты, натыкаешься на подобную добровольную принудиловку и показываешь реакции вчерашниго слепого щеночка, только что увидевшего солнце — рот открыл и застыл в немом удивлении. ))
Пффф...
Отключать критичность, таки, не следует, когда речь об инженерии.


·>Но в общем случае всякое бывает. Во-первых, это зависит от типа GC и настроек. Во-вторых, даже для "обычного" GC уплотнение произойдёт уже при копированиях в Eden/Survivors, ещё до 2го поколения.
·>Вот тут более детальное описание что и когда происходит.

Бггг...

It’s an old joke from the time when Java was new and slow compared to other languages. Over time, Java became a lot faster.

По отношению к самой себе тогдашней.
Но и конкуренты стали намного быстрее.

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

Fortunately, in many cases, it can be tweaked and optimized to improve performance.

И это в той подветке, где обсуждается невозможность управления трюком, о котором рассказано в предыдущей твоей ссылке.
Эдак тебя колбасит...
Ты сам хоть свои ссылки читаешь? ))

И вишенка на торте:

Let’s try another experiment. Let’s run an application that is only creating short-lived objects in multiple threads.
...
We can see that this time, the old generation received objects right after the first minor garbage collection.
...
The young generation garbage collector had no choice but to push these objects to the old generation. This is bad because the objects that got pushed to the old generation were prematurely aged and can only be cleaned up by old generation’s major garbage collection which usually takes more time. W

О чём я тебе несколько раз уже напоминал только в одной этом обсуждении, что стоит начать "бесконечно" производить объекты в разных потоках, и объекты улетают во 2-е поколение сходу. Этим страдает дотнет. Как видишь, этим страдает и джава тоже.

А дальше начинается и вовсе детсад:

How to prevent premature aging of short-lived objects? There are several ways.

И рассказываются способы, как тюнить GC.

Страна непуганых идиотов.
Или професиональных лжецов — на выбор.
Я склоняюсь ко второму.
Потому что стоит накатить "оттюненые" параметры GC на другое железо — с другим кол-вом ядер, другим кол-вом кеша 0-го и 1-го уровней в проце, другой длиной линейки кеша (а она "пляшет" от 64 байт то 512 байт) и всем, что прежде натюнили, можно смело подтереться.

А если еще какие-нить приложения на том же железе работают, или не работают, или имеют апериодическую нагрузку, то и вовсе это был булшит с самого что ни на есть начала.

Здравый смыл и простая инженерная честность видит такие вещи сходу.
И только профессиональные лжецы с умным видом кидают ссылки на такую же ложь и высокомерно (как им самим кажется) изрекают: "пойдите ознакомьтесь".
Это же палево, не?
А вдруг, действительно, ознакомятся?