Announcement

Collapse
No announcement yet.

Latest Trolling? The Linux Kernel In Perl

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

  • #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.

        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; 05 January 2014, 04: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; 05 January 2014, 04: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