exceptions are a great way to structure your error handling. they're an in-language mechanism similar to signals, only that they don't have the brain-deadedness of them.
Hell, just having smart pointers whose destructors are properly called on the stack unwind is enough.
The iSight sends uncompressed video across the system bus. the G3 iBook can't push that much data. Others have hacked around the restrictions and made it work, only to be disappointed with uselessly low frame rates.
And remember that 'iSight' and 'iChatAV' are different products. iSight == hardware, so getting USB cameras to work for the iSight would require soldering new ports into the back of your $130 video camera.
But the product's got a big problem: those that'd shell out $700-900 for a unit like this have had a PS2 for a long while now. Unless there are a lot of PS2-playing couples with their own preferences, there isn't much need for two PS/2s.
The context switch overhead this article speaks of isn't a problem on X. When you call XLib functions, it buffers them until you either flush it or if you've got a synchronous call (it's been a while, so excuse any small discrepencies). So the context switches spoken of are mostly nil. Only when you need the X server to do work do you typically flush this buffer and cause the context switch; which you need b/c the X server's process needs to run at that point.
The stylishly-named Hyperqueues are implemented in shared memory with userland synchronization, which is nice, but doesn't do too much for the X protocol, which runs on kernel-supported shared memory (zero-copy sockets), plus whatever tweaks the old MIT-SHAREDMEM extension gives on top of that.
X has been developed, actively, for over a decade. Maybe it's OK to trust the developer's opinions of where the speed bottlenecks are.
Sorry dude, but you're going to get many of these:
Solutions pulled from the ass
Solutions that sound real good, but were pulled from the ass
Crap
For your case, I hope I'm wrong. Just out of curiousity, have you considered, I donno, profiling your application, to see where the time's being spent. Also, how about switching to a more cost-effecitve Java platform? I've heard good things about this little thing called Linux.
Note:My few comments certainly fall into Category 1 from above.
But, your current solution does work, right? How much exploration have you done in optimizing the application? Oracle can certainly scale, and you're already willing to strip down the site to mostly static pages. Why throw out all that proven and thoroughly tested code? And if you're outsourcer can't do that, maybe its time to switch partners, not platforms. You have a large investment here, there's a good chance you can save most of it.
CFM & Mach-O are the OS 9 & OS X binary executable formats. They can be as different as they want internally, but they're serving the same purpose. I think we're in agreement here.
My point was that the C ABI is standard atop of these, and that that's the ABI that's most important. I'll post when I get the right info on the C++ ABI compatibility...
Dude, are you just flaming for its own sake? Or is there really a _large_ semantic gap here?
You did say optimizations. You were talking about a hardware-accellerated X server. I'm talking about communication optimizations between a proprietary Xlib and the X server it came with. The optimizations I talked about would provide reason for linking against the vendor's Xlib (versus another), and the optimizations you talked about wouldn't.
1. I said you only need to change X libraries if you need to use proprietary optimizations that your X server has available. 2. Yeah, that's right. I did say that. If I have an X executable on a solaris box, and I only have a monitor on my linux box, I can run the executable on the solaris box & have it show on the linux machine, proving that the protocol is standard. Unless you happen to be running XFree on both machines, you're going to have Xlib from a different vendor than your X server.
Also, are you confusing the term server & client? In X terminology, the term 'X client' is the application you're running and 'X server' is the program that handles the display, keyboard and mouse.
3. Again, no logic, no argument, just personal insults. Go ahead, assume that's all I've written.
Now, _do_you_have_a_point_, or is this your form of mental masturbation? The lack of any logical argument, the misquoting, the personal attacks, the "oh I'm smarter than you" attitude, all say one thing: You're a fool looking for a fight. Dude, grow up. Respond, don't respond. I don't care. I'm not wasting my time with this crap anymore.
Objective-C's got a builtin reference-counting mechanism in NSObject, but you've gotta call [obj retain] and [obj release] yourself. The RCSP will do all of the work itself. You just assign it and use it. It'll even work properly through an exception.
The ABI is Mach-O or CFM. They both work on OS X. GCC uses it, Codewarrior uses it, the IBM XL compilers use it. Codewarrior also beats gcc in speed & quality of code like an abusive sibling*. Donno about the IBM compilers, but I assume they provide an even more severe beating.
* That was going to be a much more offensive analogy...
So how does the possibility of co-residence require new libraries? Does the on-the-wire protocol suddenly break in the most common case of usage? Like I said before, the only advantage to using the libraries from the same vendor as the X server is for extensions & optimizations. The MIT Shared Memory extension is probably the most important, but it's implemented everywhere and the protocol is also standard.
Other than vendor independence, how could you explain how statically-linked Motif programs on linux (back in the day when that was the only way to distribute them without requiring a $99 royalty on the client side (think Netscape4)) could work on XFree & Metrolink X servers with the same binary?
And explaining your position by saying "You don't understand. You obviously know nothing" isn't the best argument. Especially when you're talking to an X11 and Motif programmer:-P
Garbage collection has costs: - The obvious: CPU & memory overhead for the checking and tracking. I can't comment on the amount here, but it is a generalized solution, so you forego the optimization opportunities that you'd otherwise have. - The subtle: Memory allocation can become a major bottleneck in multithreaded systems. Garbage collection has similar issues. - The irritating: you don't know when your destructors are called.
Another way: Smart Pointers. They're simple wrappers around the types that act like pointers, but they can make sure your objects live as long as you need and no longer. The big trick is knowing which kind of smart pointer you want. - Reference Counting Smart Pointer (RCSP for short): this type of smart pointer will keep of how many RCSPs are pointing to the same object. It'll delete the object when the last RCSP is destroyed. A good one is the boost shared_ptr. Available for free from www.boost.org. This type is great for general use.
- Owning Smart Pointer (OSP): this type is specialized for those cases when the refcnt is never more than 1. When you assign one OSP (a) to another (b), the new OSP (a) gets ownership of the referred object, and the old one (b) is automatically set to null. When an OSP that isn't set to null is destroyed, it deletes the object it owns. It's great for parameter passing, return values, and objects you want dead at the end of the current scope, even if there's an exception. The STL comes with auto_ptr, which works this way.
You can use an RCSP wherever you can use an OSP, but not the other way around. The STL containers are a great example.
Sure it's not as easy as 'allocate and forget,' but you won't have the (sometimes very costly) expense of full-blown garbage collection.
Also, you can optimize your smart pointers for individual types (through template specialization). A great example is to give the no-longer-needed object back to a pool for later reuse.
This is really a quick, quick overview. For the meat & potatoes, go read Effective STL by Scott Meyers.
I've tried really hard to be fair & polite. There's probably still a bias, but I'm really trying!!
As the protocol between the client and the X server is standard, you don't need new X libraries. The only reason to change them is for any proprietary extensions.
Think about it. If you required new X libraries for every X server, how could you do X11 between a linux-based X server and a solaris-based X client?
Slashdot Mirror
exceptions are a great way to structure your error handling.
they're an in-language mechanism similar to signals, only that they don't have the brain-deadedness of them.
Hell, just having smart pointers whose destructors are properly called on the stack unwind is enough.
Hmm, so, was there ever an explanation to these?
the first arg has no explanation.
the second -- what hidden memory allocations??
third: you can write in ASM too, but that doesn't mean you should.
The soldiers aren't the ones making the agenda. It's the politicians above them; who happen to be Christian, with a blatant agenda.
The original Crusades were for profit first, religion second. The first one's so blatant this time that only the ones being attacked see the second.
You do realize that the one who'd have to build spyware protection into the computer would be microsoft, right?
I believe that since those came in separate boxes, you don't need to worry.
The iSight sends uncompressed video across the system bus. the G3 iBook can't push that much data. Others have hacked around the restrictions and made it work, only to be disappointed with uselessly low frame rates.
And remember that 'iSight' and 'iChatAV' are different products. iSight == hardware, so getting USB cameras to work for the iSight would require soldering new ports into the back of your $130 video camera.
Actually, PPC is slow with GCC as well. Codewarrior and IBM's xlC blow it out of the water.
:-P
So it's fair
I like the unit.
But the product's got a big problem: those that'd shell out $700-900 for a unit like this have had a PS2 for a long while now. Unless there are a lot of PS2-playing couples with their own preferences, there isn't much need for two PS/2s.
The context switch overhead this article speaks of isn't a problem on X. When you call XLib functions, it buffers them until you either flush it or if you've got a synchronous call (it's been a while, so excuse any small discrepencies). So the context switches spoken of are mostly nil. Only when you need the X server to do work do you typically flush this buffer and cause the context switch; which you need b/c the X server's process needs to run at that point.
The stylishly-named Hyperqueues are implemented in shared memory with userland synchronization, which is nice, but doesn't do too much for the X protocol, which runs on kernel-supported shared memory (zero-copy sockets), plus whatever tweaks the old MIT-SHAREDMEM extension gives on top of that.
X has been developed, actively, for over a decade. Maybe it's OK to trust the developer's opinions of where the speed bottlenecks are.
I'll assume it's a puzzle of some sort, but I'm too lazy to work for it.
When you click on Elvis's right lens on the home page, you get a window with the following string:
31 02283 665
If you're not up to spec on SVG, and have no desire to be, you could always buy it at amazon for $150 and get a 100% rebate. It worked great for me :-)
Sorry dude, but you're going to get many of these:
For your case, I hope I'm wrong. Just out of curiousity, have you considered, I donno, profiling your application, to see where the time's being spent. Also, how about switching to a more cost-effecitve Java platform? I've heard good things about this little thing called Linux.
But, your current solution does work, right? How much exploration have you done in optimizing the application? Oracle can certainly scale, and you're already willing to strip down the site to mostly static pages. Why throw out all that proven and thoroughly tested code? And if you're outsourcer can't do that, maybe its time to switch partners, not platforms. You have a large investment here, there's a good chance you can save most of it.
The auto_ptr doesn't. The reference-counting boost::shared_ptr does.
CFM & Mach-O are the OS 9 & OS X binary executable formats. They can be as different as they want internally, but they're serving the same purpose. I think we're in agreement here.
My point was that the C ABI is standard atop of these, and that that's the ABI that's most important. I'll post when I get the right info on the C++ ABI compatibility...
It's not complete nonsense :-P
:-) bbl.
The ABI that matters is for C on OS X. Carbon uses it. Even Objective-C & Cocoa use it (the calls are mapped to a C call).
As for C++ ABI... I'm asking someone who knows
Dude, are you just flaming for its own sake? Or is there really a _large_ semantic gap here?
You did say optimizations. You were talking about a hardware-accellerated X server. I'm talking about communication optimizations between a proprietary Xlib and the X server it came with. The optimizations I talked about would provide reason for linking against the vendor's Xlib (versus another), and the optimizations you talked about wouldn't.
1. I said you only need to change X libraries if you need to use proprietary optimizations that your X server has available.
2. Yeah, that's right. I did say that. If I have an X executable on a solaris box, and I only have a monitor on my linux box, I can run the executable on the solaris box & have it show on the linux machine, proving that the protocol is standard. Unless you happen to be running XFree on both machines, you're going to have Xlib from a different vendor than your X server.
Also, are you confusing the term server & client? In X terminology, the term 'X client' is the application you're running and 'X server' is the program that handles the display, keyboard and mouse.
3. Again, no logic, no argument, just personal insults. Go ahead, assume that's all I've written.
Now, _do_you_have_a_point_, or is this your form of mental masturbation? The lack of any logical argument, the misquoting, the personal attacks, the "oh I'm smarter than you" attitude, all say one thing: You're a fool looking for a fight. Dude, grow up. Respond, don't respond. I don't care. I'm not wasting my time with this crap anymore.
Objective-C's got a builtin reference-counting mechanism in NSObject, but you've gotta call [obj retain] and [obj release] yourself. The RCSP will do all of the work itself. You just assign it and use it. It'll even work properly through an exception.
Trust me, Panther's GUI is ***FAST***. So fast I'm no longer saving to upgrade my Powerbook G4/500.
The ABI is Mach-O or CFM. They both work on OS X. GCC uses it, Codewarrior uses it, the IBM XL compilers use it. Codewarrior also beats gcc in speed & quality of code like an abusive sibling*. Donno about the IBM compilers, but I assume they provide an even more severe beating.
* That was going to be a much more offensive analogy...
So how does the possibility of co-residence require new libraries? Does the on-the-wire protocol suddenly break in the most common case of usage? Like I said before, the only advantage to using the libraries from the same vendor as the X server is for extensions & optimizations. The MIT Shared Memory extension is probably the most important, but it's implemented everywhere and the protocol is also standard.
:-P
Other than vendor independence, how could you explain how statically-linked Motif programs on linux (back in the day when that was the only way to distribute them without requiring a $99 royalty on the client side (think Netscape4)) could work on XFree & Metrolink X servers with the same binary?
And explaining your position by saying "You don't understand. You obviously know nothing" isn't the best argument. Especially when you're talking to an X11 and Motif programmer
Garbage collection has costs:
- The obvious: CPU & memory overhead for the checking and tracking. I can't comment on the amount here, but it is a generalized solution, so you forego the optimization opportunities that you'd otherwise have.
- The subtle: Memory allocation can become a major bottleneck in multithreaded systems. Garbage collection has similar issues.
- The irritating: you don't know when your destructors are called.
Another way: Smart Pointers. They're simple wrappers around the types that act like pointers, but they can make sure your objects live as long as you need and no longer. The big trick is knowing which kind of smart pointer you want.
- Reference Counting Smart Pointer (RCSP for short): this type of smart pointer will keep of how many RCSPs are pointing to the same object. It'll delete the object when the last RCSP is destroyed. A good one is the boost shared_ptr. Available for free from www.boost.org. This type is great for general use.
- Owning Smart Pointer (OSP): this type is specialized for those cases when the refcnt is never more than 1. When you assign one OSP (a) to another (b), the new OSP (a) gets ownership of the referred object, and the old one (b) is automatically set to null. When an OSP that isn't set to null is destroyed, it deletes the object it owns. It's great for parameter passing, return values, and objects you want dead at the end of the current scope, even if there's an exception. The STL comes with auto_ptr, which works this way.
You can use an RCSP wherever you can use an OSP, but not the other way around. The STL containers are a great example.
Sure it's not as easy as 'allocate and forget,' but you won't have the (sometimes very costly) expense of full-blown garbage collection.
Also, you can optimize your smart pointers for individual types (through template specialization). A great example is to give the no-longer-needed object back to a pool for later reuse.
This is really a quick, quick overview. For the meat & potatoes, go read Effective STL by Scott Meyers.
I've tried really hard to be fair & polite. There's probably still a bias, but I'm really trying!!
So your saying that optimizations in the server will necessitate new client-side libraries? Tell me we're miscommunicating here.
As the protocol between the client and the X server is standard, you don't need new X libraries. The only reason to change them is for any proprietary extensions.
Think about it. If you required new X libraries for every X server, how could you do X11 between a linux-based X server and a solaris-based X client?
For the PowerBook G4: Logitech MX500.
For the PowerMac G4: Logitech MX700.
I bought the 500 first, loved it so much, that I had to pick up a 700 for home. Now I await:
- A bluetooth 15" Powerbook
- A bluetooth Logitech MXx00 mouse
- Income to pay for it.
kdebase & kdelibs.