пятница, 22 июля 2016 г.

Exactly

Quote of the day:
A single Nehalem chip today could easily generate four gigabytes per second of new garbage when running a classic enterprise workload.
The text pointed by the link is very informative, though. It's about the Azul JVM and how they exploit virtual memory to create a "Pause less" concurrent garbage collector (truly pauseless in the normal operation mode but with some <1ms pauses for stuff like unloading of classes). What's even more interesting is their attitude:We didn't take the typical approach where you try and optimize for the common fast case, but remain stuck with some things that are really hard to do, which you push into the future. Then you tune and tune to make those events rare, maybe once every ten minutes or every hour—but they are going to happen. We took the opposite approach. We figured that to have a smooth, wide operating range and high scalability we pretty much have to solve the hardest problem all the time. If we do that well, then the rest doesn't matter. Our collector really does the only hard thing in garbage collection, but it does it all the time. It compacts the heap all the time and moves objects all the time, but it does it concurrently without stopping the application.
On an unrelated note: прикольная программистская задачка: есть мутабельное бинарное дерево, с указателями на детей, но без указателей на родителя. Обойти его за О(1) памяти, ну, там, чтобы распечатать все вершины в каком-то порядке. EDIT: ну и после этого дерево должно оказаться в начальном состоянии опять.
Я знаю два существенно различных решения, одно есть в TAOCP (кажется) и дико красивое, но довольно нетривиальное, ещё одно придумал Влад Щербина (который и задачку мне показал), оно дичайше простое, но требует допиливания до полноценного решения и после допиливания кстановится дико тормозным вдобавок.

Комментариев нет:

Отправить комментарий