141–150 of 245 posts
4Tb ought to be enough for anybody.
(I'm guessing you were think of the same [Which apparently is just apocryphal])
We use Shenandoah everywhere. It’s amazingly great.
Earlier quoted context omitted.
It's just an object that lives on the stack, not the heap. In lots of languages when you create an object, it's pretty explicit where you're putting it. When Java was created, they wanted to get rid of that complexity, so primitives always go on the stack and objects always* go on the heap. * I think Java has escape analysis, which means that if it can determine that an object you created doesn't leave its context, i…
> It's just an object that lives on the stack, not the heap. That's not quite correct. A reference type might contain a value type field, in which case the value type will still live on the heap. Conversely, a local variable's type might be a value type, and _still_ involve a heap allocation. For example, std::vector in C++ is a value type but the array storage is heap-allocated. So it's really about semantics, and n…
This isn't correct. Firstly, C++ doesn't have value or reference types. Where any object is stored depends purely on how it is allocated. Either in the free store (dynamic) or automatic storage (the stack).
std::vector has a constant object size - typically the size of 3 pointers (but that depends on the implementation - the standard doesn't specify): the start of the memory (dynamically allocated for storage), end/capacity (typically either another pointer or a size_t of the current capacity), and back (typically either a pointer just past the last element used or a size_t + 1 of current size). It's storage is dynamically allocated, though, and for a std::vector will have dynamically allocated sizeof(T) * capacity bytes (maybe more due to alignment issues).
std::array is constexpr safe and does not (directly) dynamically allocate memory - size has to be known at compile time (hence it's a template argument).
For instance, on my compiler (GCC 4.8.4), for this example program:
#include
#include
#include
int main()
{
std::vector v_ten(0, 10);
std::vector v_twenty(0, 20);
std::array a_ten{0};
std::array a_twenty{0};
std::cout sizeof(v_ten): 24
sizeof(v_twenty): 24
sizeof(a_ten): 40
sizeof(a_twenty): 80
Earlier quoted context omitted.
Java is at least somewhat responsible for the need to get to 4TB in the first place.
Sounds interesting. Could you explain how so?
Interested to know what workloads are using multi-TB heap sizes? Largest I've used has only been in the 48-64GB size and even then it seemed like a waste.
Basically, graphs are hard to shard ... what if we didn't bother? You can query an in memory graph pretty quickly out into the 2nd or 3rd degree.
Even G1 (untuned) only pauses for 250ms once every few minuets. It's not perfect but good enough to ignore.
Earlier quoted context omitted.
With generational GC, does this even matter? Generation 0 is pretty much a stack as far as performance and operation go.
Problem is memory locality, or lack thereof. Having to chase pointers around and not having things laid out in sequence doesn't play well with the CPU cache.
Earlier quoted context omitted.
With those latency requirements why did you use Java?
Plenty of people are writing low-latency trading applications in Java where the latency budget is under 100 microseconds. This has been the case for several years now. It's by no means new or even especially difficult these days. The resulting code is far more maintainable and robust than C++ solutions.
We're currently fighting a Java app that in general has decent latency (10s of usecs), but has outliers of greater than a second when GC kicks in. We don't have that issue with the C++ components of our trading system.
Earlier quoted context omitted.
Plenty of people are writing low-latency trading applications in Java where the latency budget is under 100 microseconds. This has been the case for several years now. It's by no means new or even especially difficult these days. The resulting code is far more maintainable and robust than C++ solutions.
I’ve heard a pretty effective, lazy strategy for this scenario is to oversize the heap to avoid GCs through the trading day and to simply restart the application before the next day. Unsure if it’s viable for all trading platforms, but it makes sense for some I’m sure.
And yeah, we restart everyday (we only trade US equities, so plenty of downtime for a restart).
Interested to know what workloads are using multi-TB heap sizes? Largest I've used has only been in the 48-64GB size and even then it seemed like a waste.
1.2 TB Xmx (Java heap) here, reporting in from LinkedIn not fintech. Basically, graphs are hard to shard ... what if we didn't bother? You can query an in memory graph pretty quickly out into the 2nd or 3rd degree. Even G1 (untuned) only pauses for 250ms once every few minuets. It's not perfect but good enough to ignore.