Gates' major achievements are as a businessman, not as a computer scientist. Not saying that he's stupid in that area; quite the opposite (e.g. given the speed he apparently designed MS BASIC with, he clearly has skill). However, he didn't actually invent BASIC (as a language) or even write MS-DOS originally. On the other hand, who can deny that he's a very skilled businessman? I'd say his only achievements are as a businessman. There is no proof anywhere that Billy Gates did anything other than a little bit of BASIC programming as a teen.
I only claimed synchronizing would almost make it thread-safe. I did not ever state this was a good approach. You should read the second and third paragraphs of my GP.
The only thing Creative has to offer over the integrated audio on a Vista board ia aimulated surround sound. Tell mw why I need that when I can feed real multichannel audio directly to my Yamaha receiver. I would hazard a guess that most don't have a Yamaha receiver handy.
It is always possible, but I am a rare one - I cycle through music. I listen to something for a while, then it gets dumped on the pile of "no longer really interested in it". New music replaces it, usually. However, that replacing part has been rapidly shrinking, meaning the total amount of music I listen to has shrunken. That heavily coincided with the ClearChannel take over of all the stations I used to listen to locally about 3-4 years ago. At the same time, new music releases of artists I'd even be the tiniest bit interested in dropped off, and tripe like Britney and the new category, Boy Bands with Guitars, "took off". This would be that wonderful glop of crap from various "artists", most of whom slip out of your head as quickly as they fade from the radio, although Fall Out Boy, My Chemical Romance, AFI, American Rejects, and quite a few others more or less fall into. You could play a song from any of them and not know who you're listening to, as they're all more or less interchangeable vocally and instrumentally. At least Evanescence is vocally distinct, even if every song sounds vocally identically monotonous.
All righty then, I suppose I've created enough flamebait there for everyone.;)
It's funny that John Carmack stated pretty much the exact opposite about ease of use and expense to develop with. Of course, in all fairness, that was around the time of DX8. I don't know what his later take is. There were statements made recently (I forget where exactly or I'd reference them) that DX9/10 offered slightly more advanced complex features, but that OpenGL was capable of almost everything the DX clan was. OpenGL has also been moving more slowly on newer features of late, which is a shame and the reason that DX moved ahead on the feature set.
OpenGL is an example of where committee is getting trumped by dictatorship. There's no question of who decides what goes in DX10.
And apparently Vista will spur OpenAL adoption, as that's the only way to get around Vista's brain-dead DRM'd audio architecture and get hardware acceleration under Vista. That's straight from Creative's website detailing Vista's new audio architecture's effects and recommendations, btw. (Whatever you may think about Creative, you can't argue with their analysis on this one.)
I figured when I wrote that that someone would take me to task about the (g)cc compilers. I didn't recall which particular flavors I used, but I ran them several different OSes and those were the compiler executables we called. (Of course, they could have been linked/aliased to anything, but that's not the point:)
I did state that they originally operated in this fashion. This was purely in support of the argument that C++ was a syntactical overlay of C, nothing more. That changed later as did the C++ spec.
Heck, the other "golden age" of popular music was from around 75-84, when Madonna and her ilk hit the airwaves. You had the punk/heavy metal revolution followed immediately by a revolution caused by MTV. MTV was so desperate for material they'd play anything anyone sent in as long as it wouldn't get them fined. Try to imagine someone like the Talking Heads coming out in today's world if you doubt it. Then again, you'd have to have a music channel on TV that actually played music.
I'm gloating. Here's the kicker: I don't pirate music. There's only been a single CD that's come out in the last 5 months I'm remotely interested in, and I'm not interested enough to pick it up (Muse's new one, and I'm so interested that I don't even know its title:) I used to buy 20-50 CDs a year from the early 80s on through the mid-90s, when the quality of music took a huge dive. Yes, I have somewhere between 600-1000 CDs sitting on the shelf. FYI - I averaged about $7/CD. The last "great" CD I picked up was American Idiot by Green Day. The last so-so was Samstown by the Killers (so-so because it has about 3 good songs on it and the remainder being mediocre to decent.)
I am looking forward to the new NIN disk, it may be out already, but the industry's horrible customer service to date has cut most lines of communication with at least this intended customer.
I can't wait until the industry either starts catering to its clients again (that'd be us, the consumers) or dies off and let's something better in its place. Like, perhaps, the environment that existed in the 50s and 60s, where even "great" acts like Elvis or Johnny Cash were approachable and worked hard.
And therein lies one of the issues of MT and why MT programming is a more difficult topic, than say, OO. It's no longer just about how you write code and your chosen language's compiler, but about the actual target machine(s) you'll be running on. MT includes the larger picture of your computing environment. OO is relatively invariant regarding computing environment.
You can code self-tuning thread pools if you like. This is obviously more difficult than hard-coding specifics in, but it is certainly an attainable possibility.
And not taking other threads on a machine into account is at least an order of magnitude easier than accounting for other threads/programs.
Well, that's probably because most of my recent multi-threaded work has been in Java, and hence is at the top of the heap, so to speak.
Yes, Java largely copied the C/C++ architecture regarding threads, with minor tweaks. C# is of course mostly a reimplementation of Java with a strong C++ flavor. Regarding C++, it was merely an OO wrapper on top of C initially, or at least that's how it was implemented with the (g)cc compilers, as they translated C++ to C, then compiled and linked that C code IIRC. (it's been so long I wouldn't bet a beer on it, and I'm too lazy to look it up;)
To write efficient, production usable MT code currently I have only seen it done with C/C++/Java. I have yet to see MT C# production code, although I'm sure some exists somewhere, even if it's only in unsafe sections. I've already been directed to Erlang and SCOOP and will look at them soon.
I agree with you that an MC programming revolution is not around the corner. The only real consumer applications that already exist are photo and movie editing packages. Some of these effectively run across multiple CPUs. They're pretty much all written in C/C++ with some assembly from what I gather from various reviews, discussions, articles, etc. After all, does your mail program really benefit from MC? (MT yes, but MC?) I doubt it, unless you're getting thousands of emails a day and have some form of AI agent processing it. How about your word processor? Nope, can't type faster than my fingers will go. Speech recognition? Now there's a concept, but I personally believe that will be handled more effectively via an add-on DSP specialty chip. Multi-media processing including audio? Sure, I can see it there too, and I thought some already were MT. The audio compressors I've used to date are single threaded though. I've countered this by running my ripping software in MT with the ability to compress multiple tracks simultaneously in separate processes (EAC is truly a wonderful product, can't promote it enough). EAC itself only benefits from a single processor though - it's so CPU light while ripping I can barely tell it's running in the CPU monitor.
Games. Now games are an area that could have some serious MC/MT goodness. It requires a whole new paradigm, however, to run a game effectively in MT/MC. The only game I know that did this was Galactic Civilizations for OS/2. While a windows version came out, I do not know whether it was MT as well. I suppose I could run it and see...:) It certainly allowed for much improved AI, although it's still somewhat limited. At least it was the first turn based game I played that the AI didn't outright cheat.
You choose to focus purely on the Java statement. That's fine. It was thought about. The problem is that there's only so many ways to skin the cat, and Java's approach was to focus on performance. You'd argue that they should have focused on thread safety instead and made it slower?
The architecture of Java, C, C++, and C# are all such that there will always be issues with re-entrant code. I'm sure you'll have some suggestion for a language that doesn't suffer from this issue.
As for Java, the core is finished. Refinements are being done to accommodate new features, like the concurrency library and changes in the memory model to address issues brought up by that addition. It's not that the features couldn't have been accommodated with the original JVM, but it would not have been as clean or easy to implement, and certainly not as performant as what resulted from the modifications.
My last 3 companies (including current) and my wife's last 5 companies regarding secretaries. The janitorial staff is a mixed bag - night crew is contracted across the board. Day time janitors are generally employees.
In only rare cases were they vested employees similar to individual contributors.
First, last time I ran the ball test just to see how processors had improved in their capabilities to run code, I got to over 2K threads in a single JVM before significant degradation occurred and then it occurred rapidly.
Using the threadpool concept, however, you can tune the size of the threadpool via performance metrics from the threads in the threadpool for the optimum size of threadpool, after which you can place however many objects on the pool you'd like. Generally, this is based on the work the thread has to do. If there is no I/O blocking, I've found that 2-3 threads per CPU with moderate CPU time work units will load it to 100% (read moderate CPU time work units as work units that take on the order of 100-1000 ms to complete). If you start adding in any type of I/O blocking, including large amounts of memory access, then that number goes up. A DB retriever system wound up running 64 threads for my particular work load due primarily to the lag involved in the synchronous calls made to the DB. I could have tuned that further using future tasks and reducing the number of threads (a Doug Lea addition to the JDK 1.5 and also available in his previous concurrency library) but my particular case didn't have any negative effects by running 64 threads, so we left it at that. This particular DB access module ran across 64 systems (64*64 threads) serving roughly 35K concurrent customers.
I haven't run Erlang, so can't comment. I have heard nice things about it though, and I'm curious about it. One day I'll have enough time to play with it.
Well, if you're going to remove 99+% of the common trouble spots of multi-threaded coding by moving to a messaging paradigm, then yes, it probably is conceptually easier than OO. It can also be significantly slower depending upon the application's design and function and greatly increase its memory footprint. e.g., I don't think a game like Quake would work all that well under this paradigm. BTW, webservers generally work under your paradigm.
You'll also still have the potential of concurrent modifications in this scenario, but at least you won't be working on the same memory storage locations, potentially reading indeterminate/incoherent values. Instead you'll have inconsistent values displayed, depending upon which thread's data you're displaying.
I'll still make the argument that good multi-threaded coding is harder than good OO coding.
I assumed it was a bad idea based on the little we could glean from the submission. I'm guessing he has one set of spindles divided up into multiple partitions. In that case, it's not a good idea.
I think you're mistaken. Most of the people I know have tuned out of that commercial slop radio and now listen exclusively to what's on their iPods (90% not bought digitally according some survey about the iTunes Store performance and iPods) or NPR.
Radio stations are changing formats to Spanish language because no one's listening to the crap anymore resulting in falling numbers, so they figure hey - there's a 10-15% population that's underserved in the spanish language market, let's get them!!!. It's sad that Spanish language radio appears to have more selection than "regular" radio in my area of the US from the limited listening I did.
I actually decided to check for updates this morning. I hadn't updated the Airport to 2007-002 yet, so I didn't update it. I still have some issues with that, and my wireless is using 5 or 6 right now. I'll probably go check it again, but some numb-nut probably installed one of those multi-band bandwidth hogging "fast" routers somewhere, and is using all the channels he can get. Selfish pigs.:)
Slashdot Mirror
If you're really offended by those, call them Belgian frites (fries). The French apparently do.
Go read up on threadpools.
I suppose I can expect a genuflecting apology when hell freezes over, but it makes you no less arrogantly wrong.
I tried it, the audigy 2 just plain sounds better than the Realtek chip on my MSI and other boards.
I only claimed synchronizing would almost make it thread-safe. I did not ever state this was a good approach. You should read the second and third paragraphs of my GP.
It is always possible, but I am a rare one - I cycle through music. I listen to something for a while, then it gets dumped on the pile of "no longer really interested in it". New music replaces it, usually. However, that replacing part has been rapidly shrinking, meaning the total amount of music I listen to has shrunken. That heavily coincided with the ClearChannel take over of all the stations I used to listen to locally about 3-4 years ago. At the same time, new music releases of artists I'd even be the tiniest bit interested in dropped off, and tripe like Britney and the new category, Boy Bands with Guitars, "took off". This would be that wonderful glop of crap from various "artists", most of whom slip out of your head as quickly as they fade from the radio, although Fall Out Boy, My Chemical Romance, AFI, American Rejects, and quite a few others more or less fall into. You could play a song from any of them and not know who you're listening to, as they're all more or less interchangeable vocally and instrumentally. At least Evanescence is vocally distinct, even if every song sounds vocally identically monotonous.
;)
All righty then, I suppose I've created enough flamebait there for everyone.
They will be using OpenAL instead of DirectSound under Vista if they want any hardware acceleration.
It's funny that John Carmack stated pretty much the exact opposite about ease of use and expense to develop with. Of course, in all fairness, that was around the time of DX8. I don't know what his later take is. There were statements made recently (I forget where exactly or I'd reference them) that DX9/10 offered slightly more advanced complex features, but that OpenGL was capable of almost everything the DX clan was. OpenGL has also been moving more slowly on newer features of late, which is a shame and the reason that DX moved ahead on the feature set.
OpenGL is an example of where committee is getting trumped by dictatorship. There's no question of who decides what goes in DX10.
And apparently Vista will spur OpenAL adoption, as that's the only way to get around Vista's brain-dead DRM'd audio architecture and get hardware acceleration under Vista. That's straight from Creative's website detailing Vista's new audio architecture's effects and recommendations, btw. (Whatever you may think about Creative, you can't argue with their analysis on this one.)
I figured when I wrote that that someone would take me to task about the (g)cc compilers. I didn't recall which particular flavors I used, but I ran them several different OSes and those were the compiler executables we called. (Of course, they could have been linked/aliased to anything, but that's not the point:)
I did state that they originally operated in this fashion. This was purely in support of the argument that C++ was a syntactical overlay of C, nothing more. That changed later as did the C++ spec.
Heck, the other "golden age" of popular music was from around 75-84, when Madonna and her ilk hit the airwaves. You had the punk/heavy metal revolution followed immediately by a revolution caused by MTV. MTV was so desperate for material they'd play anything anyone sent in as long as it wouldn't get them fined. Try to imagine someone like the Talking Heads coming out in today's world if you doubt it. Then again, you'd have to have a music channel on TV that actually played music.
I'm gloating. Here's the kicker: I don't pirate music. There's only been a single CD that's come out in the last 5 months I'm remotely interested in, and I'm not interested enough to pick it up (Muse's new one, and I'm so interested that I don't even know its title:) I used to buy 20-50 CDs a year from the early 80s on through the mid-90s, when the quality of music took a huge dive. Yes, I have somewhere between 600-1000 CDs sitting on the shelf. FYI - I averaged about $7/CD. The last "great" CD I picked up was American Idiot by Green Day. The last so-so was Samstown by the Killers (so-so because it has about 3 good songs on it and the remainder being mediocre to decent.)
I am looking forward to the new NIN disk, it may be out already, but the industry's horrible customer service to date has cut most lines of communication with at least this intended customer.
I can't wait until the industry either starts catering to its clients again (that'd be us, the consumers) or dies off and let's something better in its place. Like, perhaps, the environment that existed in the 50s and 60s, where even "great" acts like Elvis or Johnny Cash were approachable and worked hard.
And therein lies one of the issues of MT and why MT programming is a more difficult topic, than say, OO. It's no longer just about how you write code and your chosen language's compiler, but about the actual target machine(s) you'll be running on. MT includes the larger picture of your computing environment. OO is relatively invariant regarding computing environment.
You can code self-tuning thread pools if you like. This is obviously more difficult than hard-coding specifics in, but it is certainly an attainable possibility.
And not taking other threads on a machine into account is at least an order of magnitude easier than accounting for other threads/programs.
Well, that's probably because most of my recent multi-threaded work has been in Java, and hence is at the top of the heap, so to speak.
:) It certainly allowed for much improved AI, although it's still somewhat limited. At least it was the first turn based game I played that the AI didn't outright cheat.
Yes, Java largely copied the C/C++ architecture regarding threads, with minor tweaks. C# is of course mostly a reimplementation of Java with a strong C++ flavor. Regarding C++, it was merely an OO wrapper on top of C initially, or at least that's how it was implemented with the (g)cc compilers, as they translated C++ to C, then compiled and linked that C code IIRC. (it's been so long I wouldn't bet a beer on it, and I'm too lazy to look it up;)
To write efficient, production usable MT code currently I have only seen it done with C/C++/Java. I have yet to see MT C# production code, although I'm sure some exists somewhere, even if it's only in unsafe sections. I've already been directed to Erlang and SCOOP and will look at them soon.
I agree with you that an MC programming revolution is not around the corner. The only real consumer applications that already exist are photo and movie editing packages. Some of these effectively run across multiple CPUs. They're pretty much all written in C/C++ with some assembly from what I gather from various reviews, discussions, articles, etc. After all, does your mail program really benefit from MC? (MT yes, but MC?) I doubt it, unless you're getting thousands of emails a day and have some form of AI agent processing it. How about your word processor? Nope, can't type faster than my fingers will go. Speech recognition? Now there's a concept, but I personally believe that will be handled more effectively via an add-on DSP specialty chip. Multi-media processing including audio? Sure, I can see it there too, and I thought some already were MT. The audio compressors I've used to date are single threaded though. I've countered this by running my ripping software in MT with the ability to compress multiple tracks simultaneously in separate processes (EAC is truly a wonderful product, can't promote it enough). EAC itself only benefits from a single processor though - it's so CPU light while ripping I can barely tell it's running in the CPU monitor.
Games. Now games are an area that could have some serious MC/MT goodness. It requires a whole new paradigm, however, to run a game effectively in MT/MC. The only game I know that did this was Galactic Civilizations for OS/2. While a windows version came out, I do not know whether it was MT as well. I suppose I could run it and see...
This library is for C++. I've had Erlang on my list to check out for a while now.
You choose to focus purely on the Java statement. That's fine. It was thought about. The problem is that there's only so many ways to skin the cat, and Java's approach was to focus on performance. You'd argue that they should have focused on thread safety instead and made it slower?
The architecture of Java, C, C++, and C# are all such that there will always be issues with re-entrant code. I'm sure you'll have some suggestion for a language that doesn't suffer from this issue.
As for Java, the core is finished. Refinements are being done to accommodate new features, like the concurrency library and changes in the memory model to address issues brought up by that addition. It's not that the features couldn't have been accommodated with the original JVM, but it would not have been as clean or easy to implement, and certainly not as performant as what resulted from the modifications.
My last 3 companies (including current) and my wife's last 5 companies regarding secretaries. The janitorial staff is a mixed bag - night crew is contracted across the board. Day time janitors are generally employees.
In only rare cases were they vested employees similar to individual contributors.
Please turn in your geek card on your way out. Real geeks don't see ads.
First, last time I ran the ball test just to see how processors had improved in their capabilities to run code, I got to over 2K threads in a single JVM before significant degradation occurred and then it occurred rapidly.
Using the threadpool concept, however, you can tune the size of the threadpool via performance metrics from the threads in the threadpool for the optimum size of threadpool, after which you can place however many objects on the pool you'd like. Generally, this is based on the work the thread has to do. If there is no I/O blocking, I've found that 2-3 threads per CPU with moderate CPU time work units will load it to 100% (read moderate CPU time work units as work units that take on the order of 100-1000 ms to complete). If you start adding in any type of I/O blocking, including large amounts of memory access, then that number goes up. A DB retriever system wound up running 64 threads for my particular work load due primarily to the lag involved in the synchronous calls made to the DB. I could have tuned that further using future tasks and reducing the number of threads (a Doug Lea addition to the JDK 1.5 and also available in his previous concurrency library) but my particular case didn't have any negative effects by running 64 threads, so we left it at that. This particular DB access module ran across 64 systems (64*64 threads) serving roughly 35K concurrent customers.
I haven't run Erlang, so can't comment. I have heard nice things about it though, and I'm curious about it. One day I'll have enough time to play with it.
Well, if you're going to remove 99+% of the common trouble spots of multi-threaded coding by moving to a messaging paradigm, then yes, it probably is conceptually easier than OO. It can also be significantly slower depending upon the application's design and function and greatly increase its memory footprint. e.g., I don't think a game like Quake would work all that well under this paradigm. BTW, webservers generally work under your paradigm.
You'll also still have the potential of concurrent modifications in this scenario, but at least you won't be working on the same memory storage locations, potentially reading indeterminate/incoherent values. Instead you'll have inconsistent values displayed, depending upon which thread's data you're displaying.
I'll still make the argument that good multi-threaded coding is harder than good OO coding.
I assumed it was a bad idea based on the little we could glean from the submission. I'm guessing he has one set of spindles divided up into multiple partitions. In that case, it's not a good idea.
I think you're mistaken. Most of the people I know have tuned out of that commercial slop radio and now listen exclusively to what's on their iPods (90% not bought digitally according some survey about the iTunes Store performance and iPods) or NPR.
Radio stations are changing formats to Spanish language because no one's listening to the crap anymore resulting in falling numbers, so they figure hey - there's a 10-15% population that's underserved in the spanish language market, let's get them!!!. It's sad that Spanish language radio appears to have more selection than "regular" radio in my area of the US from the limited listening I did.
I actually decided to check for updates this morning. I hadn't updated the Airport to 2007-002 yet, so I didn't update it. I still have some issues with that, and my wireless is using 5 or 6 right now. I'll probably go check it again, but some numb-nut probably installed one of those multi-band bandwidth hogging "fast" routers somewhere, and is using all the channels he can get. Selfish pigs. :)