Actually, mmap() is also used to allocate the memory to back the heap. So if a given mmap()'ed chunk of the heap is empty, that memory can just be returned to the OS.
BeOS --- Known for being blazingly fast, if anything. It was pretty much a microkernel for god's sake. Used IPC for everything, including sending data to the app_server (the equivilent of X in its architecture).
Windows --- All the NT kernel-based OSs use an IPC mechanism called LPC to communicate with the Win32 server and the GDI.
OS X --- Not known for having a fast GUI, but the fact that it runs the GUI in a server (lightweight window process in OSX-speak) isn't the reason.
The big thing is that IPC isn't that much of a performance hit. Graphics are easily batchable, so sending a whole bunch of drawing commands doesn't hurt anything. And you know what? You're going to be batching them anyway, since sending individual commands to the graphics card over the AGP bus is not exactly the way to get optimal performance. Now, there *are* some defficiencies in all existing architectures. The ideal method, for current hardware, is what is used by OpenGL ICD's on Linux and Windows. The actual graphics library is a hardware-specific module dynamically loaded into each application. The application calls the library to do drawing commands, and the library creates a hardware-digestible command buffer right in memory. Periodically, this buffer is DMA'ed to the hardware. Now in all current systems, there is an extra step --- the graphics server is the one that creates the command buffer, so you have one extra step converting a high-level window system command buffer to a low-level graphic's driver command buffer. To tell the truth, for 2D work, this really doesn't matter much. The *core* X protocol (no shared memory or anything) is fast enough on my machine to do x11perf -putimage500 at 80fps. That means copying about 80MB of images to the screen every second. Let's just say that no desktop application has graphics complex enough to need this kind of bandwidth. The bottleneck is clearly somewhere else.
I realize that boxes with NO WINDOWS on them are a shocking design decision these days, but you need to consider it. >>>>>>>> I second that. Boxes with now Windows on them are just great. More people should try it:)
I believe that OS 10.2 uses OpenGL for the entire interface? >>>>>>>>> This is probably the millionth time I've said this. I feel like "Celebrity Jeopardy" skit where Keanu Reeves keeps saying "whoa, I know kung-fu" and Alex Trebek keeps saying "for the last time Mr. Reeves, no you don't!"
Quartz "Extreme" does not use OpenGL for "the entire interface." It's right in Apple's Siggraph paper, with pretty pictures and everything. Quartz still uses the CPU to render graphics into memory buffers. The only time OpenGL gets used is when those buffers are composited together to get the final picture. This is a step up from the previous software compositor, but other windowing systems don't even have the extra compositing step, which exists only to support the transparency and genie effects.
The main problem is that 3D is a whole different kettle of fish than 2D. The 'nv' 2D driver is 80kb compiled. The NVIDIA 3D driver is about 6MB of code, split up over a 400K X driver, a 5MB OpenGL library (libGL is vendor specific in the ICD architecture) and a 400K GLX driver. It's a whole lot more code, it's very hardware-specific, and it's a rather specialized field. The field of kernels is something else entirely. Kernel coding is a well understood field of computer science, and there are lots of OSS kernel developers who have a lot of experience in academia and the commercial industry. There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two.
Try resizing your window, does the toolkit follow instantly? or does it lag? >>>>>>>> It follows instantly. I'm running KDE 3.1.1 on Gentoo 1.4 using a 2GHz P4 and a GeForce4 MX with the NVIDIA drivers. The only tweeks I've done: 1) Using kernel 2.5.66. There are some interactivity updates in this one, though Gentoo's stock 2.4 is probably better overall (I/O scheduler in 2.5.66 is a bit weird). 2) dotNET theme. Keramik is quite fast, but there is a synchronization issue that makes the gradient menubar seem to "crawl" across the screen when resizing. 3) "RenderAccel" turned on in the NVIDIA drivers (its off by default).
Pretty much everything resizes instantly, even JuK, which has a listview with over 1000 elements in it. The scrollbars seem a little uneasy at times, but they never tear or rubber-band noticibly, so it could just be the update rate on my LCD. The only thing I've seen that actually rubber-bands is konqueror browsing Slashdot. If anybody is using Konq, this is a great way to understand exactly where the bottlenecks are. Open up the Slashdot front page. Resize the window quite small. At this size Konqueror won't bother anymore to layout the text to fit the window. It'll let it spill off the window (which IE does at a significantly larger size, btw). Now, if you resize the window through a limited range of motion at this size, you'll see no rubber banding. Now try the same thing at nearly full size. The HTML and CSS requirements necessitate that Konq now goes through every element on the page and lays it out for the new window size. This happens for each frame. This is where a lot of the rubber-banding comes from.
That's just the tip of the iceburg. Some drivers map the memory more than once. With my 64MB GeForce 4MX, X has a VM footprint of ~300MB. The actual memory footprint, though, is only about 30MB. These figures should be rather accurate, because I think they fixed some memory reporting issues in 2.5 (which I'm running).
I second that. I have also done benchmarks. X is comparable to DirectDraw in terms of speed in blitting, and a good deal faster in primitive drawing (since DirectDraw doesn't accelerate that:). Now that finals are over, maybe it's time to properly write up some of these and post them.
Any frame rate that exceeds the refresh rate of your display is effectively wasted. You just won't see the extra frames. A 23% improvement just means that many more frames you won't see. >>>>>> This is a stupid arguement. If you're frame rate is exceeding your refresh rate then why not just turn the detail up? Or are you somehow running Unreal II at 1600x1200 with full detail on a 2GHz Celeron?
Not on my code. I'm using 3.2.2, and there is still a lot of C++ code where Intel C++ will easily be over 20% faster. A lot of it has to do with high-level optimizations. You throw complex/abstracted code at GCC, and you lose a significant amount of performance compared to low level C type code. Meanwhile, ICC will compile away most of that abstraction, and you'll get code that's as fast as the equivilent C code. Now both compilers optimize very well, and a performance diff of 20% in certain cases really isn't that important, but the performance difference is there, and there are several cases where ICC will do obvious optimizations and GCC won't.
Um, there are two reasons for the performance diff. First, current code barely uses GeForce4-level features, much less FX level features. Second, the newer architecture is much more generalized (and higher-precision) than the old one, and the new drivers aren't fully optimized. We saw the same thing when the PPro came out. It was a much faster architeture, but it didn't show because code wasn't out there to take advantage of it. The "P4" comment makes no sense, because the clock-speed of the card isn't generally used in advertisements, so there is no reason to inflate it. Anybody whose smart enough to check out Toms Hardware or SharkyExtreme to find out the real clock speed will know enough to check out actual benchmarks.
PS> The "P4" isn't a trick. The clock-speed vs IPC is a design trade off, not (entirely) a marketing gimmick. What ultimately matters is bottom-line performance, and right now, the P4 is a good bit faster than more "efficient" architectures.
If you're doing C++, you can easily just uses classes that embed SSE instructions. Thanks to the magic of operator overloading you'll end up with a class that performs at the level of ASM, but looks like a built-in data type to the user. Intel's intrinsics library, in fact, does exactly this.
Menus are reasonable. There's no chevrons at the bottom of them revealing all of the choices; if there's that many choices, then something is wrong. Toolbars are another great example. They have a handful or two of very large icons that are easy to spot. The whole purpose of a toolbar is to provide very quick access to very commonly used and unique functions, not to duplicate the menus in the toolbars. For instance, you rarely find toolbar buttons for new, open, save, and print. Those are functions that are always located in the file menu, why duplicate that on the toolbar? >>>> So True! Tell this to the KDE folks, who, in some programs, have a dozen such toolbars! The context menu for Konqueror is 18 items long! All this defeats the whole purpose of toolsbars and context menus. I dearly love KDE, but the first thing I did to my install was pare down all those toolbars to one toolbar with a dozen icons or less.
That's my point. In theory, Islam brings with it not only a religion, but a culture, law, and system of government as well. Unlike Christianity, which is just a religion, the closest analogue to Islam might be "Western culture" in general. However, in practice, only Islamic countries that are theocracies actually implement the Islamic code of law. There are a great many secular Islamic countries where the actual law and system of government is based upon more familiar Western models, even though that is not in accordance with tradition.
PS> And I'd argue that Saudi Arabia is barbaric for the hand thing. I'm a Muslim, but I'm glad I don't see Christians I meet on the street championing slavery just because it says so in the Bible...
Its interesting. There was once a time when people would go to the same lengths for Christianity. Over time, reality set in and the religious frevor of the populace dissapeared. Interestingly at that same time, Islam was a religious for the cultured, well educated urban centers of the Middle East. It supported literature, art, science, and all those other humanistic things that seem to have been forgotten in today's world. So what does this tell you? Religion has nothing to do with it. Today, Islam is largely a religion composed of the economic lower end of the world population. This is how these people have behaved all throughout history. This is how they will behave for all history to come. In several centuries, this lower segment will have a different religion, and we'll be criticizing that instead.
There really isn't one. In the case of Islam, the state and the religious community are the same thing. Interestingly, it is the presence of strong central religious authorities in Christianity, and their friction with the state that lead to a tradition of seperated Church and state. While in theory Islam also has a strong central religious authority, in practice it is very fragmented, so it is very easy and quite common for the state to control the religion. Of course, it all depends on what country you are talking about. A lot of the largest Islamic countries (Iraq, Egypt, Turkey, Pakistan, Bangladesh -- the last of which, FYI has a population of over 130 million people) have pretty much secular governments, while other Islamic countries (Iran, Saudi Arabia) have religious ones.
I think this is one of the hardest thing for most people here in the US to understand. Just because terrorism is wrong about their methods, doesn't mean they don't have a point. It's all orthogonal. I can admire George Bush's shoes, but still hate his politics. Similarly, just because Bin Laden is a maniac, doesn't mean that some of his points aren't valid and legitimate. Much more reasonable people making these same points should not have to suffer the stigma of association.
Actually, the stock FreeType 2.1.4 has a lot of Chester's work already in it. Looks likes a good bit nicer than the Cleartype rendering I'm starting at now. I've always hated OS X's font rendering though, most Mac displays just aren't high-res enough to ignore hinting like that.
Quartz Extreme is about based the Windows compositing engine on OpenGL rather than software. It has nothing at all to do with Quartz, which is a drawing API and still software rendered.
Slashdot Mirror
Actually, mmap() is also used to allocate the memory to back the heap. So if a given mmap()'ed chunk of the heap is empty, that memory can just be returned to the OS.
Hmm, let's do a little survey:
BeOS --- Known for being blazingly fast, if anything. It was pretty much a microkernel for god's sake. Used IPC for everything, including sending data to the app_server (the equivilent of X in its architecture).
Windows --- All the NT kernel-based OSs use an IPC mechanism called LPC to communicate with the Win32 server and the GDI.
OS X --- Not known for having a fast GUI, but the fact that it runs the GUI in a server (lightweight window process in OSX-speak) isn't the reason.
The big thing is that IPC isn't that much of a performance hit. Graphics are easily batchable, so sending a whole bunch of drawing commands doesn't hurt anything. And you know what? You're going to be batching them anyway, since sending individual commands to the graphics card over the AGP bus is not exactly the way to get optimal performance. Now, there *are* some defficiencies in all existing architectures. The ideal method, for current hardware, is what is used by OpenGL ICD's on Linux and Windows. The actual graphics library is a hardware-specific module dynamically loaded into each application. The application calls the library to do drawing commands, and the library creates a hardware-digestible command buffer right in memory. Periodically, this buffer is DMA'ed to the hardware. Now in all current systems, there is an extra step --- the graphics server is the one that creates the command buffer, so you have one extra step converting a high-level window system command buffer to a low-level graphic's driver command buffer. To tell the truth, for 2D work, this really doesn't matter much. The *core* X protocol (no shared memory or anything) is fast enough on my machine to do x11perf -putimage500 at 80fps. That means copying about 80MB of images to the screen every second. Let's just say that no desktop application has graphics complex enough to need this kind of bandwidth. The bottleneck is clearly somewhere else.
I realize that boxes with NO WINDOWS on them are a shocking design decision these days, but you need to consider it. :)
>>>>>>>>
I second that. Boxes with now Windows on them are just great. More people should try it
I believe that OS 10.2 uses OpenGL for the entire interface?
>>>>>>>>>
This is probably the millionth time I've said this. I feel like "Celebrity Jeopardy" skit where Keanu Reeves keeps saying "whoa, I know kung-fu" and Alex Trebek keeps saying "for the last time Mr. Reeves, no you don't!"
Quartz "Extreme" does not use OpenGL for "the entire interface." It's right in Apple's Siggraph paper, with pretty pictures and everything. Quartz still uses the CPU to render graphics into memory buffers. The only time OpenGL gets used is when those buffers are composited together to get the final picture. This is a step up from the previous software compositor, but other windowing systems don't even have the extra compositing step, which exists only to support the transparency and genie effects.
The main problem is that 3D is a whole different kettle of fish than 2D. The 'nv' 2D driver is 80kb compiled. The NVIDIA 3D driver is about 6MB of code, split up over a 400K X driver, a 5MB OpenGL library (libGL is vendor specific in the ICD architecture) and a 400K GLX driver. It's a whole lot more code, it's very hardware-specific, and it's a rather specialized field. The field of kernels is something else entirely. Kernel coding is a well understood field of computer science, and there are lots of OSS kernel developers who have a lot of experience in academia and the commercial industry. There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two.
Try resizing your window, does the toolkit follow instantly? or does it lag?
>>>>>>>>
It follows instantly. I'm running KDE 3.1.1 on Gentoo 1.4 using a 2GHz P4 and a GeForce4 MX with the NVIDIA drivers. The only tweeks I've done:
1) Using kernel 2.5.66. There are some interactivity updates in this one, though Gentoo's stock 2.4 is probably better overall (I/O scheduler in 2.5.66 is a bit weird).
2) dotNET theme. Keramik is quite fast, but there is a synchronization issue that makes the gradient menubar seem to "crawl" across the screen when resizing.
3) "RenderAccel" turned on in the NVIDIA drivers (its off by default).
Pretty much everything resizes instantly, even JuK, which has a listview with over 1000 elements in it. The scrollbars seem a little uneasy at times, but they never tear or rubber-band noticibly, so it could just be the update rate on my LCD. The only thing I've seen that actually rubber-bands is konqueror browsing Slashdot. If anybody is using Konq, this is a great way to understand exactly where the bottlenecks are. Open up the Slashdot front page. Resize the window quite small. At this size Konqueror won't bother anymore to layout the text to fit the window. It'll let it spill off the window (which IE does at a significantly larger size, btw). Now, if you resize the window through a limited range of motion at this size, you'll see no rubber banding. Now try the same thing at nearly full size. The HTML and CSS requirements necessitate that Konq now goes through every element on the page and lays it out for the new window size. This happens for each frame. This is where a lot of the rubber-banding comes from.
That's just the tip of the iceburg. Some drivers map the memory more than once. With my 64MB GeForce 4MX, X has a VM footprint of ~300MB. The actual memory footprint, though, is only about 30MB. These figures should be rather accurate, because I think they fixed some memory reporting issues in 2.5 (which I'm running).
I second that. I have also done benchmarks. X is comparable to DirectDraw in terms of speed in blitting, and a good deal faster in primitive drawing (since DirectDraw doesn't accelerate that :). Now that finals are over, maybe it's time to properly write up some of these and post them.
As someone who learned this painfully many years ago , you do need the networking stack compiled in. UNIX domain sockets depend on them.
Any frame rate that exceeds the refresh rate of your display is effectively wasted. You just won't see the extra frames. A 23% improvement just means that many more frames you won't see.
>>>>>>
This is a stupid arguement. If you're frame rate is exceeding your refresh rate then why not just turn the detail up? Or are you somehow running Unreal II at 1600x1200 with full detail on a 2GHz Celeron?
I've ordered a lot of stuff off pricewatch, and I have yet to get a bum deal or have anybody not give me the stated price. b
Actually, the difference is that 800 baud is not the same speed as 800 bps. A 200 MHz QDR bus has the same transfer rate as a 800 MHz SDR bus.
PS> Who the f*ck invented the term "quad pumped?" Sounds like something a sports caster would say.
Not on my code. I'm using 3.2.2, and there is still a lot of C++ code where Intel C++ will easily be over 20% faster. A lot of it has to do with high-level optimizations. You throw complex/abstracted code at GCC, and you lose a significant amount of performance compared to low level C type code. Meanwhile, ICC will compile away most of that abstraction, and you'll get code that's as fast as the equivilent C code. Now both compilers optimize very well, and a performance diff of 20% in certain cases really isn't that important, but the performance difference is there, and there are several cases where ICC will do obvious optimizations and GCC won't.
Um, there are two reasons for the performance diff. First, current code barely uses GeForce4-level features, much less FX level features. Second, the newer architecture is much more generalized (and higher-precision) than the old one, and the new drivers aren't fully optimized. We saw the same thing when the PPro came out. It was a much faster architeture, but it didn't show because code wasn't out there to take advantage of it. The "P4" comment makes no sense, because the clock-speed of the card isn't generally used in advertisements, so there is no reason to inflate it. Anybody whose smart enough to check out Toms Hardware or SharkyExtreme to find out the real clock speed will know enough to check out actual benchmarks.
PS> The "P4" isn't a trick. The clock-speed vs IPC is a design trade off, not (entirely) a marketing gimmick. What ultimately matters is bottom-line performance, and right now, the P4 is a good bit faster than more "efficient" architectures.
If you're doing C++, you can easily just uses classes that embed SSE instructions. Thanks to the magic of operator overloading you'll end up with a class that performs at the level of ASM, but looks like a built-in data type to the user. Intel's intrinsics library, in fact, does exactly this.
Sleep. Eat. Code. Go out with somef riends. Watch a movie, whatever.
Menus are reasonable. There's no chevrons at the bottom of them revealing all of the choices; if there's that many choices, then something is wrong. Toolbars are another great example. They have a handful or two of very large icons that are easy to spot. The whole purpose of a toolbar is to provide very quick access to very commonly used and unique functions, not to duplicate the menus in the toolbars. For instance, you rarely find toolbar buttons for new, open, save, and print. Those are functions that are always located in the file menu, why duplicate that on the toolbar?
>>>>
So True! Tell this to the KDE folks, who, in some programs, have a dozen such toolbars! The context menu for Konqueror is 18 items long! All this defeats the whole purpose of toolsbars and context menus. I dearly love KDE, but the first thing I did to my install was pare down all those toolbars to one toolbar with a dozen icons or less.
That's my point. In theory, Islam brings with it not only a religion, but a culture, law, and system of government as well. Unlike Christianity, which is just a religion, the closest analogue to Islam might be "Western culture" in general. However, in practice, only Islamic countries that are theocracies actually implement the Islamic code of law. There are a great many secular Islamic countries where the actual law and system of government is based upon more familiar Western models, even though that is not in accordance with tradition.
PS> And I'd argue that Saudi Arabia is barbaric for the hand thing. I'm a Muslim, but I'm glad I don't see Christians I meet on the street championing slavery just because it says so in the Bible...
Its interesting. There was once a time when people would go to the same lengths for Christianity. Over time, reality set in and the religious frevor of the populace dissapeared. Interestingly at that same time, Islam was a religious for the cultured, well educated urban centers of the Middle East. It supported literature, art, science, and all those other humanistic things that seem to have been forgotten in today's world. So what does this tell you? Religion has nothing to do with it. Today, Islam is largely a religion composed of the economic lower end of the world population. This is how these people have behaved all throughout history. This is how they will behave for all history to come. In several centuries, this lower segment will have a different religion, and we'll be criticizing that instead.
There really isn't one. In the case of Islam, the state and the religious community are the same thing. Interestingly, it is the presence of strong central religious authorities in Christianity, and their friction with the state that lead to a tradition of seperated Church and state. While in theory Islam also has a strong central religious authority, in practice it is very fragmented, so it is very easy and quite common for the state to control the religion. Of course, it all depends on what country you are talking about. A lot of the largest Islamic countries (Iraq, Egypt, Turkey, Pakistan, Bangladesh -- the last of which, FYI has a population of over 130 million people) have pretty much secular governments, while other Islamic countries (Iran, Saudi Arabia) have religious ones.
I think this is one of the hardest thing for most people here in the US to understand. Just because terrorism is wrong about their methods, doesn't mean they don't have a point. It's all orthogonal. I can admire George Bush's shoes, but still hate his politics. Similarly, just because Bin Laden is a maniac, doesn't mean that some of his points aren't valid and legitimate. Much more reasonable people making these same points should not have to suffer the stigma of association.
Actually, the stock FreeType 2.1.4 has a lot of Chester's work already in it. Looks likes a good bit nicer than the Cleartype rendering I'm starting at now. I've always hated OS X's font rendering though, most Mac displays just aren't high-res enough to ignore hinting like that.
Have you seen Xft do subpixel rendering? Cleartype's implementation, for all its hype, isn't all that good. Xft's subpixel-AA text is very black.
Heh. BeOS has had this for the better part of a decade now :) The "inbox" folder was nothing more than a live query that looked at certain attributes.
Quartz Extreme is about based the Windows compositing engine on OpenGL rather than software. It has nothing at all to do with Quartz, which is a drawing API and still software rendered.