Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

bitbucket.org

Post reply on HN
Print view View original

111–120 of 130 posts

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#111

Post by ncmncm »

CoolGuySteve wrote: post #74
ncmncm wrote: post #67

Earlier quoted context omitted.

If you are doing high-throughput, and you ever allocate anything after startup, you are Doing It Wrong. Any brand of FIFO loses. What you need is a big-ass ring buffer, mmapped on a hugetlbfs, fed by a process on a NOHZ isolcpu core. Readers are separate processes.

No. Thread local/core-specific FIFO is more cache efficient than a ring buffer because the address about to be allocated is significantly more likely to be in a high level cache. With a ring buffer, you're constantly cycling out to L3 or worse and hoping the prefetcher figures out what you intend. It's basically a LIFO allocator. Even if you want to use a separate processing core, you get better latency using a FIFO…

Ring buffers have a strictly sequential access pattern, which prefetchers are specifically optimized for.

Anybody using a "message protocol" with ring buffers, or doing copies out of them, is Doing It Wrong. I routinely get 10x performance by doing away with FIFOs and buffer allocation and freeing.

Process separation means you can start and stop readers independently of any other activity.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#112

Post by pjmlp »

kurtisc wrote: post #44
OskarS wrote: post #30

At this point, when I see libraries like this all I can think is ”oh good, my compile times aren’t long enough, lets make EVERY INTEGER a template”. Also, while I can reasonably beliveve that most of the overhead goes away at -O2 or -O3, this has to just trash performance for debug builds, which is not unimportant.

High level languages are sold on the concept that customers' machines are powerful enough that the reduction in performance is worth it for the reduction in development time. For the same reason, it should be worthwhile to give developers powerful machines so they spend less time fixing runtime bugs.

Given that many of the security features did run perfectly fine in 60's hardware, I think they can manage in 21st century machines.

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- Tony Hoare, "The 1980 ACM Turing Award Lecture"

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#114

Post by tom_mellior »

> you don't pay for what you don't use

> throwing an exception on overflow or clamping the value to the minimum or maximum are also possible by use of template policies (and those particular use cases are already built in to the library)

> Never perform a run-time check when a static check would work instead

... but sometimes do run-time checks?

> Have no space or time overhead

This is a very confusing set of claims. You can't have all of these at the same time. Dynamic checks will be needed more often than you'd think, even in cases that "we" can tell won't overflow, so you'll definitely pay for stuff that you use even though with a stronger system you wouldn't need to use it.

For example, I'm wondering if this system can eliminate dynamic checks in cases like these:

    int sum = 0;
    for (int i = 0; i
After this loop sum's type should be integer, but I'd bet (without having tried) that with this actual system it's inferred to integer and you'd get dynamic checks. Unless you use the "null policy", in which case you don't need this library at all.

There is definitely a case to be made for a system that tries to trap overflows but also tries to use static analysis to be smart about where to put the dynamic checks. But I don't think this system is that.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#115

Post by Gibbon1 »

msbarnett wrote: post #93
Gibbon1 wrote: post #92

Earlier quoted context omitted.

go away

By all means be as imprecise and incorrect as you want, but you can hardly complain when people on a technical forum correct your imprecision ¯\_(ツ)_/¯

You were rude I would like you not to interact with me any more, it's that simple.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#116

Post by PirateAvogadro »

CoolGuySteve wrote: post #68
OskarS wrote: post #45

Earlier quoted context omitted.

Yes, that’s what I mean. And before you say ”debug performance doesn’t matter”: yes it does. I work in gamedev and it’s a huge problem that C++ has such awful debug performance, because it’s hard to debug a game if it’s running in single-digit framerates. It’s a large part of the reason why EASTL is so popular in gamedev.

I feel like that's mostly Microsoft's fault, their STL implementation is super aggressive about checks in debug builds to the point that it becomes sort of useless in heavy use/high performance scenarios. Between that and the lack of valgrind, I'm pretty glad I left that world. Over in Linux/g++ land, it's not nearly so bad. Bounds errors are mostly handled by address sanitizer such that -O0 performance is decent. An…

You could use ITERATOR_DEBUG_LEVEL=1 or 0 in debug mode; I made a "FastDebug" profile for this, although you will have to recompile dependencies

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#117

Post by SomeOldThrow »

asveikau wrote: post #109
SomeOldThrow wrote: post #103

Earlier quoted context omitted.

Why did you arrive at this confusion? Why would you assume your observations are relevant to the use case?

Did you read this part: > bounded::integer uses built-in integers as the template parameter to determine its bounds. This means that it cannot store an integer larger than ... They say the limitation arises from using "built-in integers" as template parameters. It is reasonable to assume "built-in integer" means "int". It is more a stretch to assume "built-in integer" means any number of types depending on the evalua…

> It is reasonable to assume "built-in integer" means "int".

This strikes me as a little nuts for C but it definitely explains this thread. I just assumed people had already switched over to e.g. sint32/size_t to avoid this problem a long time ago. I couldn’t tell if this was a legitimate complaint or someone’s language lawyering tendencies gone too far.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#118

Post by msbarnett »

Gibbon1 wrote: post #115
msbarnett wrote: post #93

Earlier quoted context omitted.

By all means be as imprecise and incorrect as you want, but you can hardly complain when people on a technical forum correct your imprecision ¯\_(ツ)_/¯

You were rude I would like you not to interact with me any more, it's that simple.

What, precisely, did you find rude about “ Ada. It’s not an acronym. ADA is the Americans with Disabilities Act.”?

Sincere question. Rudeness was not my intention, and those three sentences appear to be three simple facts completely neutral in nature. I’m not understanding how they could possibly be perceived as rude.

“go away” on the other hand, seemed an unnecessarily hostile and rude response to such a neutral correction, and I think the voting well reflects that. On the whole I get the feeling I’d prefer not interacting with someone so hostile about nothing, too, but I’m hardly inclined to let the assertion that I was rude go unchallenged.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#119

Post by electrograv »

ncmncm wrote: post #67
electrograv wrote: post #43

Earlier quoted context omitted.

I just finished writing a custom FIFO allocator for an extremely high bandwidth and low latency data processing (and UI) system written in C/C++ (even std::deque was doing WAY too many heap allocations, not to mention the allocations within each object passing through the system, despite use of move semantics to minimize redundancy). Performance improved by 100x - 1000x . And it was already blazingly fast before, if…

If you are doing high-throughput, and you ever allocate anything after startup, you are Doing It Wrong. Any brand of FIFO loses. What you need is a big-ass ring buffer, mmapped on a hugetlbfs, fed by a process on a NOHZ isolcpu core. Readers are separate processes.

When I see you say “any brand of FIFO loses” in the same post as “what you need is a ring buffer”, it shows that there’s a terminology disconnect here: A “ring buffer” used for streaming data is a brand of ”FIFO” :)

Therefore, the implementation you’re suggesting is actually not all that different from my current solution, except for a few important details related to the particular problem I’m solving — e.g. handling many parallel streams which may momentarily drift out of sync (where those that are not delayed must still be processed without the state of other streams interfering to add latency), among other important details.

Ultimately though, aside from this discussion on high performance designs (which though fun, would not work without you actually knowing the requirements of what I’m working on — e.g. it’s not HFT), I’m just glad we’re in agreement that there are applications where avoiding dynamic allocations is absolutely essential, and that it would be a huge mistake to add them to a high-performance language’s most fundamental integer types.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#120

Post by nybble41 »

byuu wrote: post #107
OskarS wrote: post #30

At this point, when I see libraries like this all I can think is ”oh good, my compile times aren’t long enough, lets make EVERY INTEGER a template”. Also, while I can reasonably beliveve that most of the overhead goes away at -O2 or -O3, this has to just trash performance for debug builds, which is not unimportant.

In my line of software work, I needed variable-precision integers (think uint5_t, uint13_t, etc) to express details of the architecture cleanly and avoid lots of manual bit-masking, which naturally meant having to use templates. I found that it didn't really hurt compile times much (500KLOC compiles in about 40 seconds with make -j on a 16-core box), and performance is just barely impacted at -O2, but it definitely d…

> You cannot make them work with printf("%d", x) directly (it compiles fine and then you run into problems), etc.

To be fair that's also true for standard intN_t or uintN_t types. "%d" expects an int argument, and while several of the intN_t types may be converted to int by the default argument type promotion rules, that isn't guaranteed. For example, while plain "%d" works for int64_t on ILP64 platforms with 64-bit int values, LP64 (32-bit int, 64-bit long) requires "%ld" and 32-bit platforms require "%lld". That's why you have e.g. the PRId64 macro from to select the correct format code for printing int64_t values. You could provide something similar to abstract away the required format code. If you're using the GNU C library you can even define custom format codes with register_printf_function(), which might be your only option if the calling convention for your template doesn't match any of the standard integer types.

Post reply on HN