No doubt you're far too busy wasting it on maintaining your inline assembly codeHrastProgrammer wrote:I just wrote some facts about inline assembler in Delphi / Free Pascal / VS. Didn't wrote my opinion and certainly didn't ask for your opinion, nor intend to spend a single second of my precious time arguing about it.
"Does C++ Have a Future?"
- KVRAF
- 12583 posts since 7 Dec, 2004
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- KVRAF
- 12583 posts since 7 Dec, 2004
The purpose should be to make code simple, not complex!PurpleSunray wrote:I have never understood this.. why does one think he is a good programmer if he writes complex code?quikquak wrote:The worse thing about C++ is that some crazy coders love to abstract the f**k out of it, as if programming is some kind of 'cleverness' test.
It isn't, and try debugging that obfuscated mess!
The issue is having to write the same identical code over, and over, and over, and over, and over and over and over again and again and again and again and again and eventually there is a huge f**k-up that happens somewhere.
(I don't recommend usage of the following code, it's more or less useless and only intended as a quick example. Use a proper implementation instead.)
Code: Select all
template <int channels = 2>
struct process_t
{
template <typename processor_t, typename parameter_filter_t>
void operator()(process_io_t &io, processor_t &processor, parameter_filter_t &pf)
{
pf.push();
for (unsigned int i = 0; i < channels; i++) {
const T *in = io.ins[i];
T *out = io.outs[i];
pf.pop();
for (unsigned int j = 0; j < io.samples; j++) {
*out++ = processor(i, *in++);
pf();
}
}
}
};
STL/boost now include these templates and you don't really need to write your own. This means even better stability as the design is tested by thousands or hundreds of thousands of other programmers.
The real fun starts when you need to do something a little differently. For example you might want to process multiple channels at once in a distinct way. Then you may also want to process multiple channels or sets of channels in the same way. Blocks upon blocks upon blocks. You can create an abstract SSE implementation of this utilizing compiler intrinsics encapsulated in an object as the type for io_t or processor_t.
Suddenly the same single SSE optimized interpolator works on single channels, multiple channels, images, geometry, 2d, 3d, 9d and complex derivatives.
In C you'd have 900 different hand-written implementations. Each individual implementation might "seem" simple but the combination of them is not.
The slight complexity of template meta-programming dramatically increases the leverage available and allows you to have code that is worth maybe 2x the complexity accomplish over 9000 times as much.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
-
- KVRAF
- 2256 posts since 29 May, 2012
Did anybody look at boost's graph traversal algorithms? It's a mess. When some "expert" writes hard to understand code, it's our fault, we are not clever enough to understand without needing examples that show how it is supposed to be used. When somebody else writes something similar he's trying to be clever, unnecessarily. Double standards:)
~stratum~
- KVRAF
- 12583 posts since 7 Dec, 2004
The issue is it was required to be highly dynamic and usable in a multitude of tasks so huge that your imagination is simply incapable of even comprehending how absolutely massive it is.
So write your own, that's why I write my own stuff for very simple tasks. I prefer a clean interface and add to it as required by myself rather than having to cooperate with codebases a million times the size. (AKA all existing C++ code on Earth, the Moon, Mars, Venus, Jupiter, ...)
So write your own, that's why I write my own stuff for very simple tasks. I prefer a clean interface and add to it as required by myself rather than having to cooperate with codebases a million times the size. (AKA all existing C++ code on Earth, the Moon, Mars, Venus, Jupiter, ...)
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
-
- KVRAF
- 2256 posts since 29 May, 2012
That wasn't necessary because it was documented, after all. The style of the code is such that it makes examples absolutely necessary. Therefore the examples are the documentation. I'm not seriously arguing actually, it's just that pointing such double standards is fun.So write your own, that's why I write my own stuff for very simple tasks.
~stratum~
- KVRAF
- 12583 posts since 7 Dec, 2004
Well the STL/boost are absolute hell and their overuse by C++ programmers frightens me. There are often times inexplicable differences in behavior between distinct implementations and many unwritten rules, I agree.
Yet somehow these enormous codebases manage to utilize these templates by having dedicated specialists paid salaries like 200k yearly. That sort of answers the "somehow" bit.
I don't know about you but I'm not a corporation with tens of thousands of employees or billions in yearly revenue. So it isn't really a double standard at all. Nobody ever told me I should use STL or that it would be a practical solution or "easy". Far from it.
The only people who would ever make such a claim are fools.
Yet somehow these enormous codebases manage to utilize these templates by having dedicated specialists paid salaries like 200k yearly. That sort of answers the "somehow" bit.
I don't know about you but I'm not a corporation with tens of thousands of employees or billions in yearly revenue. So it isn't really a double standard at all. Nobody ever told me I should use STL or that it would be a practical solution or "easy". Far from it.
The only people who would ever make such a claim are fools.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
-
- KVRian
- 574 posts since 1 Jan, 2013 from Denmark
Of course, I do respect your work - was merely interested in your research. I believe it's in everyone's interest to explore, research and get GCs working in more contexts.Guillaume Piolat wrote:Thanks Mayae for a reasonable discussion.
So this is for the non-GC version?For me at this point the cost was very precisely:
- 2x increased memory usage (would be a problem for < 100 instances in 32-bit). This is probably because of false pointers, memory allocated by PNG decoder did not get reclaimed.
- about 120 mutex locks per second (graphics timer threads attached then detached on exit).
Well the average speed and flat penalties don't matter (obviously a simplification), but here's the current situation as I know it:There is no other costs AFAIK for the D GC, it doesn't create threads, it doesn't run without allocation. Of course I prefer when it's not there
...
Well I won't teach you anything if I say that not all GCs are the same. It's the same word "GC" that covers multiple characteristics. The one I've talked about is not pay-as-you-go but rather "stop-paying-as-you-remove".
1. Even if you try your hardest, there's always situations in garbage-collected languages where you cannot avoid allocating memory (through the managed heap)
2. No concurrent GC tech available guarantees it doesn't stop the world every once in a while.
For #1, it seems it is actually possible in D, however as I said, at that point you're writing in a crippled and (most probably) incompatible dialect of your language, at which point I ask whether you actually have gained anything, compared to writing in an unmanaged language such as C++.
So resuming: Assuming these previous points, the nature of our problem reduces to whether the GC can make it in time. Let's take an example (these would be typical of my setup): Running at 50% load with a block size of 32 samples in 44.1 kHz says there is a window less than 0.36 ms where the world can be stopped without causing recording/playback glitches and drops. Hitting this window efficiently is an exercise in itself.
Scaling this to a vast amount of heavy interactive plugins with a heap well beyond several gigabytes... I simply don't see how this can reliably work from a pragmatic, realistic and theoretical standpoint.
Preach.When I was making small games in Javascript, it was near impossible to avoid GC pauses (as of 2011). Another time I was dispatched to a UK TV headquarters to fix stutters in video playback. The client was blaming the video output of our appliance (problems in video are usually timestamps), when in reality the C# player they were developping had GC pauses.
So I'm well aware how much pain they can inflict.
-
- KVRAF
- 2256 posts since 29 May, 2012
Depends on how much you use it really. Is 5% of stl or boost in use on the average? Maybe. Some portion of that %5 probably changes according to the developer/company/project, etc.I don't know about you but I'm not a corporation with tens of thousands of employees or billions in yearly revenue. So it isn't really a double standard at all. Nobody ever told me I should use STL or that it would be a practical solution or "easy". Far from it.
~stratum~
-
Guillaume Piolat Guillaume Piolat https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=366815
- KVRist
- 279 posts since 21 Sep, 2015 from Grenoble
This is with the GC "enabled" but not used, the remaining fixed costs.Mayae wrote:So this is for the non-GC version?
#1 is of course possible. The blog post was written specifically to describe how to recover language features. It is indeed a sub-dialect of D once you remove the runtime.For #1, it seems it is actually possible in D, however as I said, at that point you're writing in a crippled and (most probably) incompatible dialect of your language, at which point I ask whether you actually have gained anything, compared to writing in an unmanaged language such as C++.
Long story short: code written without the runtime/GC can be reused for programs with runtime/GC, but the reverse isn't true. You can still use about 50% of the stdlib and 1% of the ecosystem.
What I _could_ have done is pay the remaining (small) fixed costs and do not separate from the ecosystem.
The rest of your post is about how GC endangers plugins. What I say is it depends on the particular GC and how fully controllable it is.
Have I gained anything? Yes because this is but one aspect of developping a plugin, and the rest make up for it.
Checkout our VST3/VST2/AU/AAX/LV2:
Inner Pitch | Lens | Couture | Panagement | Graillon
Inner Pitch | Lens | Couture | Panagement | Graillon
- KVRAF
- 12583 posts since 7 Dec, 2004
I suppose D much like the many times I've looked at it over the past decades remains exactly the same D it has always been.
It's a lot of "solutions" to "problems" that are only trade-offs. You just end with a different set of problems and the choice becomes "which problem set do I prefer?"
For myself all the "advantages" of D are only D-is-advantages.
I never liked the fact that D attempts to solve bad programming by juggling a heap of trade-offs while ignoring the resulting "bad D programming".
One perfect example is lack of multiple inheritance. The argument against it is a straw-man. Yes, it can be used where it isn't needed, that is to say "improperly" used. This however ignores the required "proper" uses!
"Just use alias!" is not a proper solution. It's killing yourself twice with one stone!
The purpose of parent.child.member is to provide a hierarchical organization of elements to benefit the programmer! It makes no difference to the compiler which knows the absolute offset of the element being accessed.
So we create the straw-man that multiple inheritance can be misused for this purpose, demonstrate misuse of alias as a replacement for the straw-man and then dust our hands free whilst remaining ignorant of all the solutions we've thrown out and made impossible in D?
I guess so.
It's a lot of "solutions" to "problems" that are only trade-offs. You just end with a different set of problems and the choice becomes "which problem set do I prefer?"
For myself all the "advantages" of D are only D-is-advantages.
I never liked the fact that D attempts to solve bad programming by juggling a heap of trade-offs while ignoring the resulting "bad D programming".
One perfect example is lack of multiple inheritance. The argument against it is a straw-man. Yes, it can be used where it isn't needed, that is to say "improperly" used. This however ignores the required "proper" uses!
"Just use alias!" is not a proper solution. It's killing yourself twice with one stone!
The purpose of parent.child.member is to provide a hierarchical organization of elements to benefit the programmer! It makes no difference to the compiler which knows the absolute offset of the element being accessed.
So we create the straw-man that multiple inheritance can be misused for this purpose, demonstrate misuse of alias as a replacement for the straw-man and then dust our hands free whilst remaining ignorant of all the solutions we've thrown out and made impossible in D?
I guess so.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
And yet, they are so powerful...aciddose wrote:Well the STL/boost are absolute hell and their overuse by C++ programmers frightens me. There are often times inexplicable differences in behavior between distinct implementations and many unwritten rules, I agree.
-
HrastProgrammer HrastProgrammer https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=159519
- KVRist
- 50 posts since 10 Sep, 2007 from CPU
Actually, I am too busy on my regular job these days = game development with C++ and Unreal Engine 4, not a single assembly line hereaciddose wrote:No doubt you're far too busy wasting it on maintaining your inline assembly code
And when I find some time to work on my Pascal and assembly code, be it inlined or not, DSP or something else, it is a pure relief to me. We are not all created equal, we don't enjoy the same things, we don't hate the same things, each to their own, etc.
Back to the original topic ... Yes, C++ has a future and it won't be going anywhere soon, especially not in areas like game development, IMHO.
-
Guillaume Piolat Guillaume Piolat https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=366815
- KVRist
- 279 posts since 21 Sep, 2015 from Grenoble
@aciddose: I simply lack the time to answer your post in detail.aciddose wrote:I suppose D much like the many times I've looked at it over the past decades remains exactly the same D it has always been.
Checkout our VST3/VST2/AU/AAX/LV2:
Inner Pitch | Lens | Couture | Panagement | Graillon
Inner Pitch | Lens | Couture | Panagement | Graillon
- KVRian
- 872 posts since 6 Aug, 2005 from England
I've always hated header files, but I've learned to live with them.
C# is quite popular these days, mainly because of the Unity crowd and teaching. I quite like it.
C++ is still 10 times faster than C# despite the evangelists going on an on about how amazing it all is.
I've been told that Java 'hotspot' is as fast as native code, but I've yet to be shown something that actually is.
C# is quite popular these days, mainly because of the Unity crowd and teaching. I quite like it.
C++ is still 10 times faster than C# despite the evangelists going on an on about how amazing it all is.
I've been told that Java 'hotspot' is as fast as native code, but I've yet to be shown something that actually is.
Dave Hoskins. http://www.quikquak.com
- KVRian
- 872 posts since 6 Aug, 2005 from England
I've always hated header files, but I've learned to live with them.
C# is quite popular these days, mainly because of the Unity crowd and teaching. I quite like it.
C++ is still 10 times faster than C# despite the evangelists going on an on about how amazing it all is.
I've been told that Java 'hotspot' is as fast as native code, but I've yet to be shown something that actually is.
C# is quite popular these days, mainly because of the Unity crowd and teaching. I quite like it.
C++ is still 10 times faster than C# despite the evangelists going on an on about how amazing it all is.
I've been told that Java 'hotspot' is as fast as native code, but I've yet to be shown something that actually is.
Dave Hoskins. http://www.quikquak.com