Template Metaprogramming Made Easy (Huh?)

#ponce aliloko at gmail.com
Fri Sep 11 08:18:17 PDT 2009


> Nowadays when everyone soon has 12-core CPUs in front of them, especially 
> x86-64 ones, managing each register and memory module (cache or main 
> memory) manually is a major pain in the ass. Why do you want to do that 
> in the first place? For greater speed? 

Yes. I don't speak about "managing each register and memory module" manually, i speak about the compiler making the most efficient code. VM language simply do more stuff. The best JIT comes with Java server and has approx. 90% of C++ speed, but it's not the one bundled with most JRE.


I worked a year for a software synthesizer company. It's an extremely CPU-bound domain : imagine you have to generate dozens of voices with 2% CPU usage, at 44100hz. Really NO overhead is acceptable. 

It is not a matter of an algorithm being faster than others or shit. You have one algorithm, there is no other way to do it and you have to do it fast.

Also audio plugins are threaded by the plugin host so the core usage is not your problem. Your main issue is to use the best of one core.

Race conditions are not such a problem either for these apps, you usually have an audio thread and an UI thread, and you synchronize through spinlocks.

What I mean is that in the domain we are really _stuck_ with C++. 
And you have to write the C++ of the most horrible kind : portable and efficient C++. At some point, the amount of ugly things you have to do even explode combinatorially (think about portable memory alignment, portable assembly code...). 

Also, C++ is consistently destroyed by some vendors, encouraging compiler-specific extensions over standard.

> The problem is, your program 
> usually has tons of memory leaks, potential race conditions and 
> deadlocks, and states where is segfaults. Even if you develop for free, I 
> do not want to use your buggy pos. YMMV

Fortunately, you can't use it now.
I use D mainly for pet projects but have used it for tooling at my job (and the speed, productivity and C-style syntax was a major selling point). 

I think one could make audio plugins with D, with far less pain. It could even be the best language for the job. You won't see soon a commercially available audio plugin made in a VM language, because VM language are not pragmatic enough (yes, some have tried with Java and ended up calling native code).

> So you are part of the efficiency is priority #1 subgroup, after all. 
> There is nothing wrong with that, I just happened to guess that.

Yes, I came to D especially for the efficiency. What's the problem ?




More information about the Digitalmars-d mailing list