Announcement

Collapse
No announcement yet.

More Work On Red Hat's Wayland Project

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Ze.. View Post
    Personally I'd love to see a c++ OS project doing a microkernel and using a linux driver compatibility layer for a lot of hardware support at the start. It'd be doable and interesting but wouldn't be useful for a long time.
    And performance will suck
    source: http://www.kernel.org/pub/linux/docs/lkml/#s15-3

    Comment


    • #17
      Originally posted by Vighy View Post
      And performance will suck
      source: http://www.kernel.org/pub/linux/docs/lkml/#s15-3
      Taking advice from quotes from 5+ years ago about problems encountered 17+ years ago by people who were never knowledgeable C++ programmers is pretty stupid. C++ has no problems with kernels or performance on any sane compiler when being used by any sane developer. Anyone thinking otherwise has their head up their arse, and that fully includes Linus and company.

      Comment


      • #18
        i have a question regarding eagle (if anyone knows)

        from what i can understand by reading stuff around the net eagle is an egl implementation for mesa


        will gallium (when OpenGL ES is implemented as stated here) make it obsolete??? (or i understood the whole thing wrong?)

        Comment


        • #19
          Originally posted by elanthis View Post
          Taking advice from quotes from 5+ years ago about problems encountered 17+ years ago by people who were never knowledgeable C++ programmers is pretty stupid. C++ has no problems with kernels or performance on any sane compiler when being used by any sane developer. Anyone thinking otherwise has their head up their arse, and that fully includes Linus and company.
          The note was not only related to C++, but also to microkernels (as you can read below, in the link)

          And remember that even today C++:
          a) produces more bloated code. (with every compiler, otherwise you are simply coding in C)
          b) has issues (remember when in RadeonHD they needed to convert back inline functions to macros since the compiler was not doing the right job?)
          c) leads developers to bad attitudes, seducing them with wonderful tools and then giving them worse performance (read what Keith Whitwell says: http://sourceforge.net/mailarchive/f...ame=mesa3d-dev )

          And what about microkernels? that's a design pattern with intrinsic performance issues, and that's not going to change in the future, since it's a design pattern and not an implementation.

          The kernel is a critical piece of software. it's not admitted performance loss there.

          If you want to a microkernel written in C++, write it, and you will find that performance sucks

          Comment


          • #20
            a) produces more bloated code. (with every compiler, otherwise you are simply coding in C)
            No, it doesn't. Yes, you can code various things identically in C++ as you would in C, and it produces identical output. That's a very intentional feature of C++, after all.

            Using any non-C feature does NOT magically produce more bloated code for no reason. Using a class or a method does not produce any more output than a struct and a function. Some features of C++ do produce additional output. Exceptions and RTTI are the two features that do that. Both of those can be turned off with compiler flags, which is useful if you have decided that the functionality provided by those features is not worth the "bloat."

            Don't even start to complain about those flags being non-standard, either, because the Linux kernel already makes use of a crap load of GCC extensions and specialized linker scripts, so it's not like it's being written in ANSI-standard C anyway.

            b) has issues (remember when in RadeonHD they needed to convert back inline functions to macros since the compiler was not doing the right job?)
            What does that have to do with C++? C compilers are not following the C++ spec when compiling C-with-non-standard-extensions, and therefor C++ should not be used?

            Macros, which are a standard part of C++, and which are used where appropriate by experienced C++ programmers, prove that C++ is worse than C?

            Any number of GCC versions are blacklisted by the kernel because of bugs in the nice-simple-easy-perfect C compiler or code generator (like the inline bug with RadeonHD). Why does C get a free pass?

            c) leads developers to bad attitudes, seducing them with wonderful tools and then giving them worse performance
            Bad attitudes...?
            Seducing them with wonderful tools? How dare they offer wonderful tools!
            Already covered the performance one enough.

            C++ is a more complicated tool than C, and hence requires more effort to learn to use effectively and efficiently. C++ can make coding MUCH easier, but it requires a greater investment of time and learning than C in exchange. Unfortunately, most programmers go through school, learn all the mathematical fundamentals of computer science, learn all the syntax and features of C++, learn all those fancy design patterns... and never actually learn how C++ (or C, or assembler, or Java, or anything really) actually works. And they end up writing a ton of crappy code in it as a result. And then the elitist grey beards start hating C++ because those poor kids paid $160,000 for four years of bad education.

            What those people fail to realize is that it's not really C++'s fault, any more than it's C's fault that there is an entire army of clueless novices writing horrendous C code in the hobbyist game community. Drives me nuts, but it's not C's fault that people who don't know what they're doing try to use a tool they don't understand. Nor is it JavaScript's fault that hordes of graphics designers keep pumping out a tremendous amount of truly horrific scripts in their barely-comprehensible HTML markup. Programming is a very complicated task that requires a great deal of education and a fair bit of talent. Unfortunately, a great many people keep getting diplomas claiming that they're Real Programmers(tm) despite lacking the necessary education or talent, and those people are pretty much exclusively taught C++ or Java, so we end up with a whole mess of people who shouldn't be writing code writing it in C++.

            The fallacy that people such as yourself or people like Linux keep believing in is the idea that those very same people would be great programmers if only they used C instead of C++. That's silly. I'm ready to believe that we'd have less bad programmers if most universities used C (and a good dose of LISP) in their core curriculum, but only because C is harder to use and requires more low-level knowledge before being able to accomplish anything.

            The thing is, once you do know those things, it starts getting really tedious having to do so much boilterplate code over and over and over because every little task in C requires a ton of work to get done, where-as C++ gives you equivalent control where you need it and lets you abstract away all those details when you don't need that control; and it does it without massive overhead (no overhead compared to C in most cases), making it useful for high-performance, systems-level tasks, and it is used very extensively in places where performance and efficiency are critical (e.g., games).

            Side story: I recall some years back a poor guy who hated C++ with a passion. Total die-hard C user. One of his memorable quotes: "When I first read about inheritance I laughed my balls off: those fucking idiots wrote up a whole fucking language feature instead of just using DUH cut-n-paste!" Never mind of course that inheritance reduces the likelihood of a bug fix not getting into all those cut-n-pasted copies. Never mind that having one method instead of ten nearly identical functions results in a smaller executable, which means more of the program fits in the code cache, which means less page faults, which can result in significantly better performance. Never mind that it organizes functionality and keeps identical behavior in one place instead of ten and thus makes it easier for new programmers to come up to speed on a large existing project. But no, C++ is a total train wreck, a bloated pile of useless features, and it even forces coders at gunpoint to use at least 40 different design patterns in every module. Ayup.

            And what about microkernels?
            I'm not really qualified to comment on them, so I didn't.

            Comment


            • #21
              I'm not going to quote all the post, since it was long and it would make the page longer

              What you said (made exception for now of when you say that I think bad C++ programmers would be good C programmers... since I think the opposite ), is absolutely right, and I think the same, but I just try to realize that we are living in a real world and we have to face real compilers that have real bugs or regressions.
              We need to make in account that even if theoretically speaking most of the features, and I mean features, of C++ would give the same result of C work-by-yourself-reinventing-the-wheel, in a real compiler most of the times produce bloated code.
              That's not a C++'s fault... but you need to deal with it.

              Now, about programmers, ok, bad C++ programmers would be even worse C programmers, but on the other hand when you are a good programmer in both the examples, it's a bit more difficult to optimize C++ than C.
              Inheritance is a wonderful tool and I do use it, but it's easy with it to generate bloat. You need to be veeeery careful to not loose performance.

              Finally, I hope we can quickly reach a point since we are out of topic

              Comment


              • #22
                to return a bit in topic, wayland works only on intel platforms because relies on features that are just provided by that driver (like kms)

                I opened a thread into which I ask if it's possible to develop kms for the VirtualBox video driver, since it seems to be smaller and less complex, and it would allow everyone to work on projects like wayland even if their HW wouldn't let them directly.

                http://www.phoronix.com/forums/showthread.php?t=15106

                tell me what do you think, or what kind of help you could provide.

                Comment


                • #23
                  Originally posted by Vighy View Post
                  And performance will suck
                  source: [url]http://www.kernel.org/pub/linux/docs/lkml/#s15-3[/url
                  That page basically distils down to "it's too much work". Honestly when it comes to Linux I agree with them but that doesn't mean that one couldn't write a new kernel, and initially make use of linux drivers with a compatibility layer.
                  Originally posted by Vighy View Post
                  And remember that even today C++:
                  a) produces more bloated code. (with every compiler, otherwise you are simply coding in C)
                  That's simply bullshit. That happened in the past with poor compilers but it's not a limitation of the language.
                  Originally posted by Vighy View Post
                  b) has issues (remember when in RadeonHD they needed to convert back inline functions to macros since the compiler was not doing the right job?)
                  Wait you mean even precious c compilers have issues? btw not inlining can be a performance win if it's a rarely used function and it reduces cache thrash.
                  Originally posted by Vighy View Post
                  c) leads developers to bad attitudes, seducing them with wonderful tools and then giving them worse performance (read what Keith Whitwell says: http://sourceforge.net/mailarchive/f...ame=mesa3d-dev )
                  Wait you mean developers that don't actually understand whats going on write bad code? shit that's a brilliant piece of insight

                  The simple fact is bad developers write bad code in whatever language they use whether it be c , c++ , java , O'Caml, python , perl , haskell , erlang , scheme , etc.
                  Originally posted by Vighy View Post
                  And what about microkernels? that's a design pattern with intrinsic performance issues, and that's not going to change in the future, since it's a design pattern and not an implementation.

                  The kernel is a critical piece of software. it's not admitted performance loss there.
                  Microkernels don't have to be slow , you only need to look at the L4 series of kernels and it's descendants. The lesson there is you need to be careful with how you design your scheduler and IPC mechanisms.

                  BTW monolithic kernels have their own problems you only need to look at the current work in asynchronous function calls in linux and the difficulty of implementing them.

                  Then we've got the fact that linux is tending more and more to getting some microkernel like features in it. We only need to look at FUSE,CUSE,Video4Linux and GEM/TTM/KMS to see this trend.

                  Micro-kernels allow us to do separation of concerns , so we can catch errors instead of silently corrupting data , this is a good thing and furthermore they limit the damage that any one modules/server/driver/interface can do. They aren't a magic bullet though and like any other kernel code they don't allow you to simply ignore the performance consequences of what you are doing.
                  Originally posted by Vighy View Post
                  If you want a microkernel written in C++, write it, and you will find that performance sucks
                  One of these days I'll have the time and I'll work on it for interest , at the moment though I don't have time since I'm in the middle of a big project with a lot of people depending upon it.

                  Comment


                  • #24
                    @Ze for the half of your post, it looks clear you didn't read my last post about C & C++

                    But this is not the place to go on further speaking about coding languages or programmers.

                    To remain in topic I asked if it was possible to develop kms for the guest additions of VirtualBox.

                    If in the future you want to develop a kernel... why not starting developing such a patch for a device driver?? It could help you!

                    Comment


                    • #25
                      Any updates on Wayland? The Google groups are silent

                      I'm really excided about the new Window server.

                      Comment


                      • #26
                        Originally posted by zAo_ View Post
                        Any updates on Wayland? The Google groups are silent

                        I'm really excided about the new Window server.
                        You'd really better reading the changelog of git commits, than relying on "textual" updates... since coders tend to code more than speaking

                        http://cgit.freedesktop.org/~krh/wayland

                        Comment


                        • #27
                          Originally posted by 89c51 View Post
                          i have a question regarding eagle (if anyone knows)

                          from what i can understand by reading stuff around the net eagle is an egl implementation for mesa


                          will gallium (when OpenGL ES is implemented as stated here) make it obsolete??? (or i understood the whole thing wrong?)

                          sorry but i think it got lost in the posts about c vs c++

                          anyone knows?

                          Comment

                          Working...
                          X