"Does C++ Have a Future?"

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

HrastProgrammer 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.
No doubt you're far too busy wasting it on maintaining your inline assembly code :)
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.

Post

PurpleSunray wrote:
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!
I have never understood this.. why does one think he is a good programmer if he writes complex code?
The purpose should be to make code simple, not complex!

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();
			}
		}
	}
};
A template like this is great because it moves the implementation out of your interface entirely. You can specify the objects used within that interface and write the code only once to be reused indefinitely. Since it was only written once there is only a single place for mistakes to be made.

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.

Post

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~

Post

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, ...)
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.

Post

So write your own, that's why I write my own stuff for very simple tasks.
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.
~stratum~

Post

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.
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.

Post

Guillaume Piolat wrote:Thanks Mayae for a reasonable discussion.
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. :)
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).
So this is for the non-GC version?
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 :wink:

...

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".
Well the average speed and flat penalties don't matter (obviously a simplification), but here's the current situation as I know it:
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.
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.
Preach.

Post

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.
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.
~stratum~

Post

Mayae wrote:So this is for the non-GC version?
This is with the GC "enabled" but not used, the remaining fixed costs.

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++.
#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.

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

Post

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. :hyper:
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.

Post

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.
And yet, they are so powerful...

Post

aciddose wrote:No doubt you're far too busy wasting it on maintaining your inline assembly code :)
Actually, I am too busy on my regular job these days = game development with C++ and Unreal Engine 4, not a single assembly line here ;)

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.

Post

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.
@aciddose: I simply lack the time to answer your post in detail.
Checkout our VST3/VST2/AU/AAX/LV2:
Inner Pitch | Lens | Couture | Panagement | Graillon

Post

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.

Post

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.

Post Reply

Return to “DSP and Plugin Development”