AlmightySnoo 🐢🇮🇱🇺🇦

Yoko, Shinobu ni, eto… 🤔

עַם יִשְׂרָאֵל חַי Slava Ukraini 🇺🇦 ❤️ 🇮🇱

  • 25 Posts
  • 7 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle
  • HIP is amazing. For everyone saying “nah it can’t be the same, CUDA rulez”, just try it, it works on NVidia GPUs too (there are basically macros and stuff that remap everything to CUDA API calls) so if you code for HIP you’re basically targetting at least two GPU vendors. ROCm is the only framework that allows me to do GPGPU programming in CUDA style on a thin laptop sporting an AMD APU while still enjoying 6 to 8 hours of battery life when I don’t do GPU stuff. With CUDA, in terms of mobility, the only choices you get are a beefy and expensive gaming laptop with a pathetic battery life and heating issues, or a light laptop + SSHing into a server with an NVidia GPU.





  • For those who have tried Kakoune, once you’ve included things like Treesitter and the clangd language server, which one feels faster, Kakoune or Neovim?

    I’m still a Neovim main but one thing that I find interesting in Kakoune is their “client/server architecture” which apparently allows you to have one master Kakoune instance and multiple slave instances that would be in sync, kind of like how you can have multiple windows in any modern IDE (I’m not sure if Kakoune shares the clipboard with all of those instances?). That thing is still not available in Neovim (or Vim for that matter), which is a pain in multi-screen setups.






  • I know the guy meant it as a joke but in my team I see the damage “academic” OOP/UML courses do to a programmer. In a library that’s supposed to be high-performance code in C++ and does stuff like solving certain PDEs and performing heavy Monte-Carlo simulations, the guys with OOP/UML background tend to abuse dynamic polymorphism (they put on a pikachu face when you show them that there’s also static polymorphism) and write a lot of bad code with lots of indirections and many of them aren’t aware of the fact that virtual functions and dynamic_cast’s have a price and an especially ugly one if you use them at every step of your iterative algorithm. They’re usually used to garbage collectors and when they switch to C++ they become paranoiac and abuse shared_ptr’s because it gives them peace of mind as the resource will be guaranteed to be freed when it’s not needed anymore and they don’t have to care about when that is the case, they obviously ignore that under the hood there are atomics when incrementing the ref counter (I removed the shared pointers of a dev who did this in our team and our code became twice as fast). Like the guy in the screenshot I certainly wouldn’t want to have someone in my team who was molded by Java and UML diagrams.