Page 8 of 8 FirstFirst ... 678
Results 71 to 80 of 80

Thread: Ubuntu Is Going After A New Linux Kernel API

  1. #71
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    299

    Default

    So the question to those stating the obvious that GC'd languages and platforms may use more memory on average. What is the alternative? Abandon GC and let everyone manage memory manually?

    There are trade offs when choosing a language. No language is good for every use case.

    My opinion:
    Manually manage memory when deterministic memory management is required.
    GC'd languages that offer productivity improvements where deterministic memory management is not important.

  2. #72
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    299

    Default

    Quote Originally Posted by jrch2k8 View Post
    very good article btw.

    i would add an famous phrase we use in my country "lazy work twice" which means the time you save not knowing how memory will come to bite you later twice because you will end having to learn at least the basics of memory managament, how gc works for your picked language and burn specialized forums to find out you have to touch again a lot of your code to optimize it to meet acceptable performance levels, hence should have been faster just learn memory management and use a native language from the beggining.

    of course gc'ed languages have their proper use, the point is use the right tool for the job
    GC'd and native languages are not mutually exclusive.

  3. #73
    Join Date
    Aug 2013
    Posts
    36

    Default

    Quote Originally Posted by jayrulez View Post
    So the question to those stating the obvious that GC'd languages and platforms may use more memory on average. What is the alternative? Abandon GC and let everyone manage memory manually?

    There are trade offs when choosing a language. No language is good for every use case.

    My opinion:
    Manually manage memory when deterministic memory management is required.
    GC'd languages that offer productivity improvements where deterministic memory management is not important.
    I don't think anyone around here said this. Take some time and read the article I posted in my previous post and you will see what our point is. GC on a mobile -low memory- device is rubbish. We usually tend to think about Android when we say that.

    Now, Ubuntu Phone is starting with QML/C++ in the first place, so the memory footprint and speed would be better in the first place. This new API comes in handy when you want to boost the speed of the application you are currently running, as everyone else would be forced to clear their caches and there would be no more need to swap (on ARM this is a real problem). So the "use as much memory as possible" pattern in Linux is even more proeminent. This is furthered by the fact that on a mobile device because you never really close applications, just add more applications to the current open application stack.

  4. #74
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,525

    Default

    Quote Originally Posted by jayrulez View Post
    My opinion:
    Manually manage memory when deterministic memory management is required.
    GC'd languages that offer productivity improvements where deterministic memory management is not important.
    I agree completely. It's quite similar to choosing a high-level or a low-level language, too: if you have a game where there is performance-critical code, you probably want to optimise it, by using SIMD and/or assembly etc. But that's completely unnecessary if you're just writing a GUI frontend to a CLI application, for instance.

    Quote Originally Posted by matzipan View Post
    I don't think anyone around here said this. Take some time and read the article I posted in my previous post and you will see what our point is. GC on a mobile -low memory- device is rubbish. We usually tend to think about Android when we say that.
    All right then, I agree completely to the above point when the target audience is desktop (and I really don't care about mobile at this point).

  5. #75
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    299

    Default

    Quote Originally Posted by matzipan View Post
    I don't think anyone around here said this. Take some time and read the article I posted in my previous post and you will see what our point is. GC on a mobile -low memory- device is rubbish. We usually tend to think about Android when we say that.

    Now, Ubuntu Phone is starting with QML/C++ in the first place, so the memory footprint and speed would be better in the first place. This new API comes in handy when you want to boost the speed of the application you are currently running, as everyone else would be forced to clear their caches and there would be no more need to swap (on ARM this is a real problem). So the "use as much memory as possible" pattern in Linux is even more proeminent. This is furthered by the fact that on a mobile device because you never really close applications, just add more applications to the current open application stack.
    I've read that article a while back.

    It is not all black and white.

    You mentioned QML/C++ should make better use of memory. Remember QML is also garbage collected and QML currently introduces quite a bit of overhead (Should be reduced when they switch to the V4 engine).

    I would argue that C#/Mono would also fit well on mobile. In the same way that you can use C++ for performance critical code in C++/QML world, you can use C++ for the same in C#/Mono world (https://github.com/mono/cppsharp : Note this is not like traditional p/invoke). You can also optimize code by using SimD and inline assembly in Mono. You can also disable the GC for critical code segments (AFIK: this is not possible (yet) in QML).

    You could then compile the C# code to a native binary [ngen in windows, full aot in Mono] (bypassing the virtual machine and and any jitting). The only overhead in this case should come from garbage collection and whatever horrible code one might have written. This would put you in pretty much the same situation as C++/QML.

    I am not saying that C#/Mono is better than C++/QML [I actually prefer QML to anything else out there], but dismissing them as bad for devices based on generalizations made about GC'd languages is incredibly shortsighted.


    I'm not sure if this is a solved problem o feel free to point it out if it is. Using Qt/QML would introduce a lot of overhead for developers if developing for a platform the scale of android. This overhead would come from requiring a lot more testing (Native code is not equal on all ARM processors), increase in development time.

    Requiring multiple binaries to distribute for different ARM chips.
    C#/Mono would have the same problem when compiled to native binaries.

  6. #76
    Join Date
    Mar 2011
    Posts
    374

    Default

    Did anybody read this:
    Quote Originally Posted by Kayden View Post
    I'm surprised no one has mentioned this, yet...but based on the 30 second overview, this sounds a lot like the existing madvise() function. Programs can use that to tell the OS "If you're running low on memory, feel free to throw this away, and just give me zeroes later." It's existed on Linux since at least the 2.4 kernel, and also exists on BSD and MacOS X.
    Or has this turned into a discussion about GC vs. direct memory now?

  7. #77
    Join Date
    Jul 2013
    Location
    Bordeaux, France
    Posts
    288

    Default

    I think that the main difference is that the programmer has to make a constant check, like having a specific thread running which does a madvise call like every 20 seconds and sleeps in between.

    While here, it would be abstracted by the use of a (common) signal system, which I find to be more elegant.

  8. #78
    Join Date
    Aug 2013
    Posts
    36

    Default

    Quote Originally Posted by jayrulez View Post
    I've read that article a while back.

    It is not all black and white.

    You mentioned QML/C++ should make better use of memory. Remember QML is also garbage collected and QML currently introduces quite a bit of overhead (Should be reduced when they switch to the V4 engine).

    I would argue that C#/Mono would also fit well on mobile. In the same way that you can use C++ for performance critical code in C++/QML world, you can use C++ for the same in C#/Mono world (https://github.com/mono/cppsharp : Note this is not like traditional p/invoke). You can also optimize code by using SimD and inline assembly in Mono. You can also disable the GC for critical code segments (AFIK: this is not possible (yet) in QML).

    You could then compile the C# code to a native binary [ngen in windows, full aot in Mono] (bypassing the virtual machine and and any jitting). The only overhead in this case should come from garbage collection and whatever horrible code one might have written. This would put you in pretty much the same situation as C++/QML.

    I am not saying that C#/Mono is better than C++/QML [I actually prefer QML to anything else out there], but dismissing them as bad for devices based on generalizations made about GC'd languages is incredibly shortsighted.


    I'm not sure if this is a solved problem o feel free to point it out if it is. Using Qt/QML would introduce a lot of overhead for developers if developing for a platform the scale of android. This overhead would come from requiring a lot more testing (Native code is not equal on all ARM processors), increase in development time.

    Requiring multiple binaries to distribute for different ARM chips.
    C#/Mono would have the same problem when compiled to native binaries.
    I am not familiar with how compiled-to-native C#/Mono work, is it still GC'd? If they are, you still have the same problem. If not, it might be that you could use it, but I can't really see the advantage over regular C/C++. I use C# over .NET at work and I find it a pain to do even the most basic thing, especially of all the boilerplate you have to write. Sure, it has a brilliant object model, but being strongly typed is a big turn-off for me.

    I am not sure about the testing bit, but I don't think it should be any problem really. You have native code running on different x86, x64, Intel, AMD, whatever architectures running just fine. And ARM has matured enough by now that it can take most of the stuff (reference needed). I think what varies in an ARM SoC is not the CPU core itself, but all the stuff that you would normally find on a PC motherboard: connectivity, bridges, decoders, GPU, etc.

    Using Qt/QML would introduce a lot of overhead for developers if developing for a platform the scale of android
    What do you mean by that, why so?

  9. #79
    Join Date
    Feb 2011
    Posts
    1,068

    Default

    Quote Originally Posted by jayrulez View Post
    You mentioned QML/C++ should make better use of memory. Remember QML is also garbage collected and QML currently introduces quite a bit of overhead (Should be reduced when they switch to the V4 engine).
    That is only if you are using javascript for actual code. If you are just using QML, which is a way to describe the behavior of the UI, then it shouldn't make a big difference.

  10. #80
    Join Date
    Oct 2008
    Posts
    3,038

    Default

    Quote Originally Posted by matzipan View Post
    I am not familiar with how compiled-to-native C#/Mono work, is it still GC'd?
    Yes, it is. Just like you can run C or C++ programs with a GC if you want to. You can choose to use unsafe blocks in C# which turns off the GC, but that's pretty ugly and if you have to do that you're probably better off with another language anyway.

    I use C# over .NET at work and I find it a pain to do even the most basic thing, especially of all the boilerplate you have to write. Sure, it has a brilliant object model, but being strongly typed is a big turn-off for me.
    What boilerplate do you mean? There is the "var" type for those who don't like strong typing. And for those who don't, are there many languages that don't GC either?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •