Announcement

Collapse
No announcement yet.

Latest Trolling? The Linux Kernel In Perl

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

  • #16
    Originally posted by board View Post
    Why do Netbeans, Eclipse and Eclipse derivatives have slow GUIs and slow startup times? Is it the programmers? Or is it Java and its crappy GUI libraries?
    No, it's because Eclipse is bloated and an over-engineered/buggy POS.

    Comment


    • #17
      Originally posted by wargames View Post
      No, it's because Eclipse is bloated and an over-engineered/buggy POS.
      Netbeans is no different, and it's developed by Sun/Oracle.

      Comment


      • #18
        Why can't I see a problem?

        Comment


        • #19
          Originally posted by board View Post
          Why do Netbeans, Eclipse and Eclipse derivatives have slow GUIs and slow startup times? Is it the programmers? Or is it Java and its crappy GUI libraries?
          Why is Qt Creator lightning fast?
          Possible reasons: usage of JIT compiler, CPU cache doesn't work well with Java apps, calling native function from Java function has overhead.

          Comment


          • #20
            Originally posted by brosis View Post
            Kernel A can't be upgraded to A+1, because kernel A+1 depends on Perl version B+1.
            Perl version B can't be upgraded to version B+1, because currently used Kernel A does not support Perl version B+1.

            Do you want to destroy the system via force install Kernel A+1 and Perl version B+1? (Y/n)

            Welcome to circular dependency hell.
            Wouldn't happen.. You'd embed a version of the perl interpretor inside the kernel itself so that it didnt have an external dependency. Each kernel would depend upon the version of perl embedded inside of itself

            Comment


            • #21
              Originally posted by Ericg View Post
              Wouldn't happen.. You'd embed a version of the perl interpretor inside the kernel itself so that it didnt have an external dependency. Each kernel would depend upon the version of perl embedded inside of itself
              And that would actually be the only option, as you can't wait for userspace to be ready (so you can have the usual perl interpreter, instead of one embedded into the kernel) to load the kernel, as you need the kernel to load userspace.

              Originally posted by JS987 View Post
              Possible reasons: usage of JIT compiler, CPU cache doesn't work well with Java apps, calling native function from Java function has overhead.
              Even though those are not caused by the language itself, using it means you use those things. So, indeed, is a problem with using Java.

              Comment


              • #22
                Originally posted by board View Post
                Why do Netbeans, Eclipse and Eclipse derivatives have slow GUIs and slow startup times? Is it the programmers? Or is it Java and its crappy GUI libraries?

                Why is Qt Creator lightning fast?
                One more example: IntellijIDEA, which is probably the best looking (and performing) Java-based IDE out there still takes ages to start up and consumes huge amounts of RAM.

                Comment


                • #23
                  Originally posted by JS987 View Post
                  Possible reasons: usage of JIT compiler, CPU cache doesn't work well with Java apps, calling native function from Java function has overhead.
                  http://en.wikipedia.org/wiki/Java_performance

                  Comment


                  • #24
                    Originally posted by tuuker View Post
                    What next, soon someone gets idea to write kernel in java then .C# then Pascal etc.... and finally Kernel becomes massive bloat that cannot work without those dependencies. I think Antti and those classmates/professors are smoking something thats it.
                    Kernel + OS in Java :
                    JX
                    Jnode

                    Kernel + OS in C#
                    Singularity(M$)
                    Sharp OS

                    Although none of them survived(JNode seems to somewhat active), this ideas are not bad as a research/hobby project. With the increasing performance and new technologies, next generation computers can be made to have vm as primary hardware abstraction so traditional code can run on that.

                    Comment


                    • #25
                      Originally posted by board View Post
                      Tell me in what project is Java a better choice than C/C++ in terms of performance?

                      I can promise you that Java is worse in almost every case.
                      Hmm... are we ever going to get away from "Jave/C# is slow therefore you should never-ever-ever use it" arguments? Maybe I'll grant that there can be a 30-40% CPU overhead. Still, I remember when people were saying the exact same thing about C vs assembly.

                      Java is better than C++ in terms of performance of the programmers (as is C#). C++ is not appropriate for most server-side systems, and you can very easily offset the performance overhead by buying more/faster hardware. Usually this is cheaper than the marginally-increased costs of building C++ systems.

                      Of course, I am now arguing against my original point that the syntax of the programming language that you choose is not a the biggest technical factor when dealing with a complex program like the Kernel

                      Comment


                      • #26
                        Originally posted by OneTimeShot View Post
                        Hmm... are we ever going to get away from "Jave/C# is slow therefore you should never-ever-ever use it" arguments? Maybe I'll grant that there can be a 30-40% CPU overhead. Still, I remember when people were saying the exact same thing about C vs assembly.

                        Java is better than C++ in terms of performance of the programmers (as is C#). C++ is not appropriate for most server-side systems, and you can very easily offset the performance overhead by buying more/faster hardware. Usually this is cheaper than the marginally-increased costs of building C++ systems.

                        Of course, I am now arguing against my original point that the syntax of the programming language that you choose is not a the biggest technical factor when dealing with a complex program like the Kernel
                        Comparing C to assembly is not like comparing Java to C++. C brought a lot to the table that was not there when people had to write assembly. With C you can build something like the Linux kernel, but with assembly that would be literally beyond the ability of mankind. So whatever tiny overheads you would get by using C it was worth it. The "sacrifices" people have made by avoiding pure assembly were worth it.

                        In the case of Java vs C++, it's not the same. The amount of overhead you get with Java just to build a compile-once-run-everywhere application is just too much. Besides, companies that produce enterprise level software do not mind having some OS specific code and recompiling their softwares for Mac, Linux(rpm/deb) and Windows. They don't. Most programming tasks can be achieved with multi-platform libraries such as Qt, Boost, Sqlite, ICU and what have you. There wont be any problems maintaining a single source code for all platforms unless you wish to avoid Qt and use OS-specific GUI libraries, in that case you'll have to write some "glue-code" (which I've never tried myself, but I can imagine that would be still better than Java).

                        And no way I'm going to sacrifice 30%-40% CPU and 200MB-300MB ram overhead. That's just unprofessional. Besides, when it comes to server-side applications, you absolutely don't want to have that type of overhead. Yes hardware is cheaper than competent C++ employees. But do you think that choosing Java would be beneficial in the long-term? If my company would expand and I'd be left with a Java-based solution (with the overhead mentioned above) and that would require more and more servers, I'd be pretty disappointed. When my server-side solution is functional, I wont be spending much money on employees, it would instead go into maintaining a growing user-base and buying more hardware just to cover the wasteful overhead from Java. Theoretically, that doesn't look good.
                        Last edited by board; 01-05-2014, 03:41 PM.

                        Comment


                        • #27
                          Shifting a modern kernel to a modern interpreted languages on modern CPU architectures is a terrible idea. HOWEVER, a kernel and CPU largely based around a single interpreted language could be a great idea. If you create an interpreted language designed specifically for 1 type of CPU, you could get excellent performance with a fraction of the memory consumption, and considerably easier development. I suppose maybe you could take something like perl or python and highly modify them for a new OS so it can take advantage of all available pipelines in a CPU. But, I think something like a 5GHz RISC architecture would be more ideal; It seems most interpreted languages aren't really optimized for any instruction sets, aren't very good with multi-core CPUs (they're fine with openCL), and tend to take procedures one step at a time.
                          Last edited by schmidtbag; 01-05-2014, 03:47 PM.

                          Comment


                          • #28
                            Originally posted by board View Post
                            In the case of Java vs C++, it's not the same. The amount of overhead you get with Java just to build a compile-once-run-everywhere application is just too much.

                            And no way I'm going to sacrifice 30%-40% CPU and 200MB-300MB ram overhead. That's just unprofessional. Besides, when it comes to server-side applications, you absolutely don't want to have that type of overhead. Yes hardware is cheaper than competent C++ employees. But do you think that choosing Java would be beneficial in the long-term?
                            OK, that's your opinion (and in some cases you'd be right), but you'll find that there are a lot of people who disagree for various reasons. Java and C# are hugely popular languages and frameworks - and there aren't many alternatives in this area. In my line of work (for example) we use them for their security properties - you'd be laughed out of the room for even considering using a non-managed language on a server.

                            Comment


                            • #29
                              Originally posted by tuuker View Post
                              What next, soon someone gets idea to write kernel in java then .C# then Pascal etc....
                              People have written kernels in Pascal (or Pascal-derivatives) for decades.
                              And people have written kernels in Java & C# since more than a decade ago too.
                              In fact, at some point a couple of guys wrote a kernel (mostly) in Python (it did actually have working mouse & keyboard drivers written in interpreted Python, for example).

                              Comment


                              • #30
                                Originally posted by OneTimeShot View Post
                                OK, that's your opinion (and in some cases you'd be right), but you'll find that there are a lot of people who disagree for various reasons. Java and C# are hugely popular languages and frameworks - and there aren't many alternatives in this area. In my line of work (for example) we use them for their security properties - you'd be laughed out of the room for even considering using a non-managed language on a server.
                                That's true, but it still requires you to know what you are doing, which a lot of people don't, and doesn't discount the fact it has it's price. You pay that performance loss because you need the added security, and that's reasonable, because security is critical. In a lot of other cases, users pay that price because the developer is lazy.

                                Comment

                                Working...
                                X