41–50 of 130 posts
Earlier quoted context omitted.
Or Lisp’s approach of just using ”big” ints by default (which is practically the same but with an implicit default of “infinity”). And trust the compiler to use fixints internally when the programmer has declared it safe to do so.
But that performs very poorly on all architectures.
Maybe Ada's approach of every number type requiring explicit bounds is a good one.
Or Lisp’s approach of just using ”big” ints by default (which is practically the same but with an implicit default of “infinity”). And trust the compiler to use fixints internally when the programmer has declared it safe to do so.
Performance improved by 100x - 1000x. And it was already blazingly fast before, if measured against performance standards we’ve become accustomed to from JavaScript and other GC languages.
In high performance systems (where the benefits of C/C++/etc. outweigh the downsides), dynamic allocations always come back to bite you.
If you rely on them too heavily from the start (and don’t plan for custom allocation schemes in the future), you can even get into bad situations where it’s infeasible to refactor to custom memory management (without a total rewrite), when you later need the performance gain.
Incorporating even the possibility of heap allocations into a language’s most fundamental data types will doom that language to being relegated to performance-insensitive and latency-insensitive tasks, if only because it requires that a heap exist (whereas C, Rust, etc can run on embedded real-time systems with no heap).
And that’s okay! It’s good that we have languages for that. But C/C++/Rust/etc. are definitely not where you can tolerate such a thing in the core language.
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.
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.
Have you measured? Also, what do you mean by "this has to just trash performance for debug builds". Do you mean runtime performance?
> The built-in integer types in C++ (int, unsigned, long long, etc.) are mostly unusable because of the lax requirements on bounds. This must be some new definition of the word 'unusable.'
On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to overflow. They are only "usable" if you restrict yourself on one version, of one compiler, on one hardware platform.
Earlier quoted context omitted.
Have you measured? Also, what do you mean by "this has to just trash performance for debug builds". Do you mean runtime performance?
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.
> The built-in integer types in C++ (int, unsigned, long long, etc.) are mostly unusable because of the lax requirements on bounds. This must be some new definition of the word 'unusable.'
I agree with that statement. How can you use type when you don't know range of values. I want to store year. From 1850 to 2050. What type should I choose? I want to store colour value: from 0 to 2^24-1. What type should I choose?
That might be a question for developers of the billons of lines of C++ in production. Asking them, you'd discover how they they actually use the builtin types.
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.
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.