tag:blogger.com,1999:blog-410416665291724878.post355200897552296185..comments2022-12-19T13:52:22.907+04:00Comments on >рабочие заметки: Off-heap: троллинг 70-го уровняRuslan Chereminhttp://www.blogger.com/profile/01023948540752159657noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-410416665291724878.post-63773369631548072032012-11-16T23:29:34.060+04:002012-11-16T23:29:34.060+04:00@oleg
Да, позор на мои седины. Хотя очень удачно,...@oleg<br /><br />Да, позор на мои седины. Хотя очень удачно, что итоговый вывод принципиально не изменился -- Unsafe хоть и вырвался вперед, но лишь на полшишечки. С другой стороны -- так ситуация даже более понятна, я ведь так и не придумал, что там такое может наоптимизировать JIT для long[] чтобы он стал быстрее. <br /><br />P.S. А может, это я специально ошибку допустил, чтобы проверить Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-50035879575257185122012-11-16T21:38:04.746+04:002012-11-16T21:38:04.746+04:00Заинтересовали =) Повторил тест у себя и как водит...Заинтересовали =) Повторил тест у себя и как водится, нашел ошибку в тесте.<br />В реализации LongArrayTradeArray.get(int index) ты забыл помножить индекс на длину записи. То есть у тебя<br />flyweight.setBaseIndex( index );<br />а должно быть<br />flyweight.setBaseIndex( index * getObjectSizeInLongs() );<br /><br />за счет этого ты эффективно обращаешься из этого теста к в 6 раз меньшему объему Anonymoushttps://www.blogger.com/profile/14089685342510262860noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-22585243047481280192012-10-29T18:12:35.736+04:002012-10-29T18:12:35.736+04:00Это, так скажем, "прямое" его назначение...Это, так скажем, "прямое" его назначение. А вот использование его для эмуляции структур, для снижения GC -- это косвенное, обычно именно его имеют в виду под off-heap. Потому что для ускорения ввода-вывода "оффхиповость" не принципиальна, это деталь реализации. Можно ведь было бы не писать, что DirectBB использует данные вне кучи, просто упомянуть, что для ввода-вывода он Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-52187089235390084132012-10-28T19:57:36.466+04:002012-10-28T19:57:36.466+04:00>> Это когда DirectByteBuffer/Unsafe использ...>> Это когда DirectByteBuffer/Unsafe используют для организации данных вне java heap. Предположительно, это должно радикально снизить нагрузку на GC, да и, в некоторых случаях, сам доступ к данным ускорить.<br /><br /><br />DirectByteBuffer можно быстрее выкинуть клиенту по сети по сравнению с хипом если это кому-то актуальноAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-47439336362670751022012-10-22T16:16:34.575+04:002012-10-22T16:16:34.575+04:00Постеснялся мэтру так говорить. Просто написал, в ...Постеснялся мэтру так говорить. Просто написал, в чем он допустил неточность.Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-67058486553994848362012-10-22T13:56:33.504+04:002012-10-22T13:56:33.504+04:00Этот комментарий был удален автором._https://www.blogger.com/profile/08509261195886399028noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-48375115831439999862012-10-20T14:01:12.294+04:002012-10-20T14:01:12.294+04:00Да, я согласен, в целом. В общем-то, нужно просто ...Да, я согласен, в целом. В общем-то, нужно просто разделять задачи. Есть задача создания компактных структур данных в яве. Есть задача хранения больших массивов неструктурированной информации. Эти задачи сводятся к тому, что нужно что-то вроде (void*) -- нетипизированной памяти. И вот эта задача в первом приближении вполне решается через byte[]/long[]. <br /><br />Есть уже следующий уровень, Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-626890179281632912012-10-19T11:19:51.165+04:002012-10-19T11:19:51.165+04:00Я видел использование off-heap в разных модулях и ...Я видел использование off-heap в разных модулях и там use case'ы совершенно разные. Есть такой где хранятся блобы, есть такой где храняться много мелких объектов с разными полями (причем этот кейс более часто у меня встечался). А в одном из модулей, где надо было хранить массивы байтов как раз, при попытки использовать offheap GC начало жутко колбасить, так как паттерн работы был такой, что Anonymoushttps://www.blogger.com/profile/06908778694732339503noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-78643887169912836172012-10-19T11:00:11.266+04:002012-10-19T11:00:11.266+04:00Так как раз у вас особо не было резона спрашивать ...Так как раз у вас особо не было резона спрашивать -- насколько я понимаю, у вас вне кучи хранится большой объем преимущественно бинарных данных. И вы с ним особой обработки не делаете -- просто кладете туда блобы, и берете оттуда блобы чтобы отправлять клиенту. Здесь off-heap вполне логично выглядит, хотя мне и было бы интересно, насколько ему проиграет аккуратно написанное in-heap хранилище с Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-15446806749961509622012-10-19T01:02:11.505+04:002012-10-19T01:02:11.505+04:00>> Кроме того, хотелось потестить еще одну, ...>> Кроме того, хотелось потестить еще одну, свою реализацию хранилища: на базе long[]. Она давно напрашивалась — фактически, каждый раз, когда я слышу про off heap мне хочется спросить, пробовали ли авторы реализовать все то же самое, только не над off heap memory, а сначала над обычным byte[]/int[]/long[]?<br /><br />Ну что ж не спросил-то :) <br />Как ты заметил в начале своего Anonymoushttps://www.blogger.com/profile/06908778694732339503noreply@blogger.com