Do you ever think of developing in other languages than C++?

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

Post

If you already know what you will be programming, have a decent flowchart, and don't expect to be fiddling with modularity, just use C. It's incredibly straightforward.

Languages like Java and C++ and Python and etc etc allow the programmer to be expressive, and easily take a programmatic concept and copy it. But C will really make you think about computers in the context of your program, and push you to do better.
Last edited by camsr on Tue Apr 19, 2016 9:11 pm, edited 1 time in total.

Post

Zaphod (giancarlo) wrote:I programmed almost the same number of hours in java and in c++ (using all standard libraries, boost or whatever). 10 years each. Even today I switch continuously between them.
Ok, then you already get the point the author should get as well.
Use the language that fits best to solve your task. There are VSTs out there in C#, Java, ect. just no single (successful) commercial one... for a reason.
So if you are not after writing professional code, there is no point on forcing yourself to use a language you don't like.

Post

Absolutely.
You cannot create audio plugins in java... yet. First of all there is the memory footprint, than java is at least twice slower than c++. Anyway computers today are running java faster than c++ 10 years ago. So for old techniques java is "usable" but still not perfect. You could experience dropouts even on very fast computers for simple tasks. It is a pity, because it is sooooo relaxing

Post

Zaphod (giancarlo) wrote:Absolutely.
You cannot create audio plugins in java... yet. First of all there is the memory footprint, than java is at least twice slower than c++. Anyway computers today are running java faster than c++ 10 years ago. So for old techniques java is "usable" but still not perfect. You could experience dropouts even on very fast computers for simple tasks. It is a pity, because it is sooooo relaxing
If you want to have drop outs, current Java JVM are indeed the best.
I don't agree with you when you say that you can write Java code faster than C++. Python code, OK; Java, there is no way you get the same order of magnitude.
I agree that some of the constructs are more complex, but that's exactly why you can do real time audio in C++ and not in Java: you have to handle memory explicitly so that you can ensure real time properties on your code (so Java is out by definition of the current JVM, even with JIT).

camsr> you do know that C++ compilers generate faster code than C ones, right?

Post

Miles1981 wrote:you do know that C++ compilers generate faster code than C ones, right?
Cite an example?

Post

I don't agree with you when you say that you can write Java code faster than C++. Python code, OK; Java, there is no way you get the same order of magnitude.
Compile your int-crunch c++ code for plain x86 and run it against the java one, on a recent vm and an i7 cpu
pretty sure java wins

Post

Sure, there will always be benchmarks where Java is faster (even if it is not generally faster). In general C++ still wins.

http://benchmarksgame.alioth.debian.org/u64q/java.html

It will take the JVM being able to know when to eliminate array bounds and type checking for it to be generally faster, which isn't going to happen anytime soon, if ever.

Java is close enough, but we need low-latency real-time performance.

But back to the OP, I'd recommend sticking with the C subset for now.

Post

Zaphod (giancarlo) wrote:Absolutely.
You cannot create audio plugins in java... yet. First of all there is the memory footprint, than java is at least twice slower than c++. Anyway computers today are running java faster than c++ 10 years ago. So for old techniques java is "usable" but still not perfect. You could experience dropouts even on very fast computers for simple tasks. It is a pity, because it is sooooo relaxing
As far as I can tell, the #1 culprit is the garbage collector, which I'm sure is great for what Java typically used for, but it rules out stuff like VSTs. Here's a video of a 1h talk about this (in the context of video games but the same arguments apply to VSTs).

Post

Miles1981 wrote:
Zaphod (giancarlo) wrote:Absolutely.
You cannot create audio plugins in java... yet. First of all there is the memory footprint, than java is at least twice slower than c++. Anyway computers today are running java faster than c++ 10 years ago. So for old techniques java is "usable" but still not perfect. You could experience dropouts even on very fast computers for simple tasks. It is a pity, because it is sooooo relaxing
If you want to have drop outs, current Java JVM are indeed the best.
I don't agree with you when you say that you can write Java code faster than C++. Python code, OK; Java, there is no way you get the same order of magnitude.
I agree that some of the constructs are more complex, but that's exactly why you can do real time audio in C++ and not in Java: you have to handle memory explicitly so that you can ensure real time properties on your code (so Java is out by definition of the current JVM, even with JIT).

camsr> you do know that C++ compilers generate faster code than C ones, right?

Maybe I expressed myself in a bad way but on a modern cpu java is faster than a c++ application running in 2006, so 10 years ago.
I'm quite sure about it.
There are a lot of misconceptions about java but really java IS fast today, because the hot spot vm.
Normally java is "just" 2-3 times slower than c++ but uses till 100 times more memory. Yes you can manipulate the gc but at the end of the day you waste a lot of ram in any case.
Said that, the language is not very suitable for real time calculations like audio ones, because it is like running a not optimized one.

About writing code faster, this is what happens TO ME.
I can create a thing in java and in c++ and for even simple "business logic things" I need 5 times more efforts in c++. Let's say I need one day for java and 5 days for c++, even using all the tools I created during years.

In java you can rely on impressive libraries, they are standard, well documented and used by millions of people, while in c++ you have a sort of fragmented environment. But even for simple things like a semaphore barrier. I'm not surprised everybody creates the wheel again, the same wheel from the scratch every time. If you look at juce library, Jules created again the same damn things from the scratch. I did the same. Google did the same. Boost did the same. Yes you can use boost, but it changes, several things were not quite ready few years ago. Than you have compiling issues on old compilers. Than things are less optimized than expected. And so on.

The stupidest thing on the planet, Google did it again and again in EACH library created. How many different debug printf around? They are even if conflict between themselves when you link different Google libraries at once.
There will be several hundreds smart pointers implementations around. Or black trees.
In java you have your standard bone, and it is highly optimized, and there is no wheel to create each time. It just works.
That hashset or the arraylist implementation ARE good and they have been ALWAYS good. You go on c++ and you never know what to do because the standard came late, you should adapt your old code again and again, syntax of things changed so many times and everything is a big mess.

Too fun digging in facebook thrift code and discover they created the same things created by Google again and again and again

Post

Duplicate

Post

camsr wrote:
Miles1981 wrote:you do know that C++ compilers generate faster code than C ones, right?
Cite an example?
Simple: qsort vs std::sort. The C++ version is faster.

Post

Zaphod (giancarlo) wrote:The stupidest thing on the planet, Google did it again and again in EACH library created. How many different debug printf around? They are even if conflict between themselves when you link different Google libraries at once.
There will be several hundreds smart pointers implementations around. Or black trees.
In java you have your standard bone, and it is highly optimized, and there is no wheel to create each time. It just works.
That hashset or the arraylist implementation ARE good and they have been ALWAYS good. You go on c++ and you never know what to do because the standard came late, you should adapt your old code again and again, syntax of things changed so many times and everything is a big mess.
It's getting there. You already have smart pointers int he standard, no need for new ones, threads are getting there (I hope C++14 will have more of these). ArrayList, I don't understand the issue with vector?
Syntax is constant, it doesn't change.

Post

Miles1981 wrote: It's getting there. You already have smart pointers int he standard, no need for new ones, threads are getting there (I hope C++14 will have more of these). ArrayList, I don't understand the issue with vector?
Syntax is constant, it doesn't change.
Vector is thread safe and thus slower because of the synchronisation cost.

Post

In that case, I can't understand the rant. OK, unordered_map came late, but they are already quite proust (because they were part of extensions to the standard for ages in lots of implementations) and vector/arraylist has been there from the start.

Post

avasopht wrote: Vector is thread safe and thus slower because of the synchronisation cost.
You are talking about a different C++.. the one we talk about says:

Code: Select all

The behavior of a program is undefined if calls to standard library functions from different threads may
introduce a data race. The conditions under which this may occur are specified in 17.6.5.9. [
Note:
Modifying an object of a standard library type that is shared between threads risks undefined behavior unless objects of that type are explicitly specified as being sharable without data races or the user supplies a locking mechanism.
— end note
http://www.open-std.org/jtc1/sc22/wg21/ ... /n4296.pdf -section 17.6.4.1

Post Reply

Return to “DSP and Plugin Development”