• Register
  • Help
Results 1 to 8 of 8

Topic: Geek question........

  1. #1

    Geek question........

    OK, all you programming types. I mean folks who are INTO IT. (Tom?), you know RING-0 Kernel-mode stuff.

    One thing that I've found in common with a lot of the low-level streaming software like GigaStudio (using the Conexant stuff), Kontakt, and even GPO, is that the developers of these products all say NO multi-processing, no Hyper-Threading CPUs and the like.

    While parallel-processing on systems so-equipped doesn't offer truly twice the throughput, it does improve performance. What's the beef that you as developers have with MP?

    Folks, please don't hijack the thread - see if we can keep it on this topic.


  2. #2

    Re: Geek question........

    One word "Timing".
    Aaron Clark, C/C++, J2EE, Flash, Perl and PHP programming.
    Logic Pro 7.0.1, G5 1800x2, 3 Gig ram, GPO and GOS lite.
    My site: http://www.clarkaudio.com
    Where I work now: http://www.blinex.com/

  3. #3

    Re: Geek question........

    Another word: race conditions. Oops. Sorry. That was two words.

    I spent the final 5 years of my programming career writing NT services for air traffic control, basically some heavily multi threaded TCP/IP stuff. In a single processor environment, no hyper threading, or anything else of the kind, debugging seriously multi threaded stuff can be, well, an adventure. Especially when it's a performance oriented application. Landing airplanes and processing audio actually do have some things in common in that regard - performance is everything.

    It's not only possible, but common, to write a multi threaded app, test it heavily, stamp it okay and ship it out the door, only to have a bug surface later because one particular machine has something going on that changes the timing of things just enough to flush out a race condition, deadlock, or other such critter.

    Conventional wisdom among programmers is that you've never really done serious multi threaded debugging until you're working on multiple processors, which takes the complexities and chances for race, deadlock and other coincidental timing adventures to a whole new level. I'm not terribly current on the hyper threading technology, but my (oversimplified) understanding is that it emulates a multi processor environment, which would explain all the warnings.

    Basically, my take on all of it is this. It's enough of a nightmare in the typical software development shop to get an app out the door that's on time, on budget, and that doesn't turn 10% of your customer's screens very interesting shades of the color blue. I'm guessing that all the audio guys say "no multi processors / hyper threading / etc." because their apps were fundamentally single threaded or only moderatly multi threaded, and they don't want to expose themselves to a potentially huge rewrite of their code to be well behaved in a multi processor environment (it really does reqiure a significantly different approach to how you design and code).

    In other words, yes, you're right. All this technology could give us much better performance. But to take advantage of it, most shops would have to rewrite their stuff from the ground up, and from a business point of view, there's no real advantage to that. It's much easier to just tell your customers what the limitations are and keep shipping incremental improvements to your existing code base. Remember, companies are in business not to produce Cool Techie Things, but to make a profit. A complete rewrite of your codebase is a profitability nightmare waiting to happen.

    On topic enough for you?

    And remember, of the 7 levels of hell, ring 0 was the worst...
    Christopher Duncan
    Author of
    Unite the Tribes and The Career Programmer

  4. #4

    Re: Geek question........

    OK My GPO Friends and Geniuses - I drudged this one up again, 'cause it's going to REALLY become an issue.

    With Duo-procs prevalent today and Quads to do the same on the horizon, what we gonna do???

    With GPO's of the future be taught to IGNORE the 2nd, or 2nd, 3rd, and 4th processors in the mix?

    I've laid low for many moons until GPO General MIDI comes out (stuff just got too complicated), however I now have a Quad-processor, and I'm worried if GPO-GM will even run on my system?


  5. #5
    Senior Member Leaf's Avatar
    Join Date
    Apr 2006
    Dallas, TX

    Re: Geek question........

    Don't mean to hijack thread, but i wonder where Chris is (Christopher Duncan). Kinda miss him. I'll see if i can find his site and check in on him, see how he is doing, well i hope.

  6. #6

    Re: Geek question........

    My very first programming job in the 80s was writing graphics device drivers for CAD accelerator boards that used the T400 and T800 transputer chips to multi-thread progs written in (god help us) Occam. To take full advantage of multi-core CPUs, the DAW folks will have to essentially start with a blank page and rewrite the core of the app from the ground up.

    I'm betting that the Cakewalk people will be the first to really pull it off, they've been pretty agressive in their 64-bit support.


  7. #7

    Re: Geek question.......Multiprocs and Garritan Products

    Hello?? I'm surprised and a little disappointed that more of the "techie" types haven't responded to this thread.

    Gary? Chris? Tom? I want to spend more $$$$ on wonderful Garritan products, especially the General Midi when it comes out.

    But I'm hesitant 'cause I'm concerned about whether or not this new product will even run on my quad-proc system. Can the GM product be instructed to IGNORE the additional processors? ...maybe even use them? .....or will I have to disable them in the BIOS? I don't mind that option terribly, I just want to know.



  8. #8
    Join Date
    Jun 2000
    Chandler, Arizona

    Re: Geek question........

    I have a Core 2 Duo running Sonar 6.2.1 and have noticed that Kontakt 2 and the Kontakt 2 Player work fine with multiprocessing enabled. I'm not having the issues I had with Kontakt 1.53. Sonar spreads the different VSTi and VST's between the 2 cores of the processors. This distributes the load quite well. My CPU usage rarely goes above 30% and this is with 6 instances of Arturia MiniMoog V and CS-80v, a few Kontakt 2 (including players), Drumkit from Hell Superior, Mellotron and quite a boatload of compressors, reverbs, delays, etc.

    x64 is not quite primetime yet so I'm still running the 32 bit version without problems. I have been doing testing with Windows x64 Pro and Sonar x64 version and it works but there are issues with some of the VSTi's.


Go Back to forum


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts