Announcement

Collapse
No announcement yet.

Memory Folios Being Sought For Linux 5.15

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

  • Cape
    replied
    Originally posted by Vistaus View Post
    But this is not going to benefit desktop users, right? 'Cause normally when something like this is being proposed/worked on by a company invested in Linux, people in the community say it will not benefit desktop users.
    In this case:
    - Vidias: probably not much. Videogames already optimize the allocation of memory as much as they can (as in: they try to limit frequent allocation/deallocation of memory). Also doesn't change anything done in the GPU
    - WebBobwsing: i'd say significantly. JavaShit allocate and deallocate shit all day for no reason. Also rendering is done mostly with dynamic alloc
    - Video editing / 3d modelling / musekick production: meh... if it's mostly a done on the GPU it won't be affected. Maybe rendering on the CPU might gain a partial speedup. Also musekick programs shouldn't benefit much, as audio handling shouldn't involve many frequent allocation/deallocations... but you never know
    - General feel / responsiveness: UNINSTALL GNOME

    Leave a comment:


  • coder
    replied
    Originally posted by Vistaus View Post
    But this is not going to benefit desktop users, right? 'Cause normally when something like this is being proposed/worked on by a company invested in Linux, people in the community say it will not benefit desktop users.
    This is very obtuse logic. Instead of looking at the principle behind the change, you'd do better to focus on the nature of the change, itself.

    I'd expect this to benefit anything which makes heavy use of dynamic memory allocation. Whether that's good for you depends on what you do, but it's a good bet that it'll improve the performance of web browers and web apps.

    Leave a comment:


  • coder
    replied
    Originally posted by LuukD View Post
    [My apologies mate. I misinterpreted your comment.
    Don't apologize! You were absolutely right to criticize uid313 for needlessly injecting Rust into a thread that had nothing to do with it!

    Leave a comment:


  • LuukD
    replied
    Originally posted by Vistaus View Post
    But this is not going to benefit desktop users, right? 'Cause normally when something like this is being proposed/worked on by a company invested in Linux, people in the community say it will not benefit desktop users.
    It depends a little on the programs you run, but it may very well be beneficial to desktop users.
    I am sure Michael will benchmark the implications for the desktop in due time.

    Leave a comment:


  • dev547
    replied
    Originally posted by uid313 View Post
    work to add Rust to the kernel
    Sometimes people do strange things just not to add Nim or Zig.

    Leave a comment:


  • Vistaus
    replied
    But this is not going to benefit desktop users, right? 'Cause normally when something like this is being proposed/worked on by a company invested in Linux, people in the community say it will not benefit desktop users.

    Leave a comment:


  • LuukD
    replied
    Originally posted by uid313 View Post

    But I love Rust!
    It is a very nice language which much more robustness, reliability, and safety than other low-level languages such as C and C++ but while providing convenient zero-cost abstractions common in high-level languages such as generics. The Option<T> and Result<T> types are great, especially together with the match statement.
    My apologies mate. I misinterpreted your comment.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by uid313 View Post
    But I love Rust!
    It is a very nice language which much more robustness, reliability, and safety than other low-level languages such as C and C++ but while providing convenient zero-cost abstractions common in high-level languages such as generics. The Option<T> and Result<T> types are great, especially together with the match statement.
    Except C of Linux kernel is not pure C. https://man7.org/linux/man-pages/man1/sparse.1.html

    Really I would like to see sparse with the Linux kernel grow more __attribute__(()) to provide more rust checking features so reducing the distance between Linux kernel C and Rust.

    Leave a comment:


  • uid313
    replied
    Originally posted by LuukD View Post

    Wow, another inventive way to hijack a topic just to announce to the world that you do not like Rust.
    ...
    I like Matthews work on memory folios and hope it will make it in 5.15. It will likely speed up all compile jobs - even Rusty ones!
    But I love Rust!
    It is a very nice language which much more robustness, reliability, and safety than other low-level languages such as C and C++ but while providing convenient zero-cost abstractions common in high-level languages such as generics. The Option<T> and Result<T> types are great, especially together with the match statement.

    Leave a comment:


  • LuukD
    replied
    Originally posted by uid313 View Post
    Good that the kernel will compile faster because Google is sponsoring work to add Rust to the kernel which will make it compile slower.
    Wow, another inventive way to hijack a topic just to announce to the world that you do not like Rust.
    ...
    I like Matthews work on memory folios and hope it will make it in 5.15. It will likely speed up all compile jobs - even Rusty ones!

    Leave a comment:

Working...
X