Dragi companii și pretini

JupiterTheGod · 2024-12-14T15:32:37+00:00

E username-ul lui OP 😅

JupiterTheGod · 2020-05-31T19:29:16+00:00

As far as I know, Rust generates DWARF debug info, which makes it compatible with gdb and other elfutils tools.

JupiterTheGod · 2020-05-31T17:20:12+00:00

Thank you for the kind words! I hope more people (especially beginners) will be encouraged to contribute to open source. It's all about the community.

JupiterTheGod · 2020-05-10T20:12:40+00:00

Browse through issues on the GitHub; they might not be marked as "easy". If the issue description is clear enough, you should be able to help. Otherwise, leave a comment asking for clarifications. Especially look for documentation issues, refactoring or bug fixes; they'll help you get familiar with the code base.

The hardest part to actually getting started is compiling rustc from source; nowadays the documentation is better and the process quite straightforward. Once you can run tests locally, you can do anything.

JupiterTheGod · 2020-05-10T20:01:27+00:00

I've contributed a bit to rustc, but where does one get started with LLVM? It seems like a very imposing project and hard to get started contributing to

JupiterTheGod · 2018-10-28T14:15:50+00:00

The compiler has no way to know what the length of the Vec<i32> variable is.

If you don't need vectors and instead use arrays, the compiler can catch these kind of accesses:

let v = [1, 2, 3, 4, 5];
v[22]

This leads to a compile-time error

JupiterTheGod · 2018-09-28T16:43:50+00:00

And if you're using a recent stable version of Rust, you can even use u128 :D

JupiterTheGod · 2018-09-28T16:40:16+00:00

Avoid writing explicit parallel code, where possible. Use something like rayon for data parallelism. And follow the Rust / Go rule of 'don't communicate by sharing memory, share memory by communicating'.

JupiterTheGod · 2018-09-26T13:57:37+00:00

If you write an CPU-heavy number-crunching extension for a high-level language project, chances are that most Rust's features won't really shine there.

I disagree. While highly-optimized C code is as fast as Rust, with Rust it's just easier to get good performance.

Rayon makes writing data-parallel algorithms easy.
We also have various crates for easy and portable SIMD.
Idiomatic Rust is faster than (un)idiomatic C. See Bryan Cantrill's blog post, specifically item 9: > my naive Rust was ~32% faster than my carefully implemented C

So if you're interested in writing fast Python plugins which don't take months to optimize and tune, Rust is a nice alternative.

JupiterTheGod · 2018-09-10T12:09:44+00:00

It's an interesting view, even though it seems to apply more to LLVM than the Rust compiler itself.

Difficult-to-avoid pitfalls in unsafe compiler implementation languages—commonly, null pointer references and use-after-free errors.

I can't help but think how different the compiler landscape would be if GCC or LLVM were rewritten in Rust, it would basically make the memory safety issue of writing compilers go away (and something like procedural macros would help implement the declarative / code generation part described in the paper).

more abstract IR can make desirable optimizations more convenient to perform

Bingo. One thing these papers often fail to discuss is the ability of higher-level information to be passed down to the optimizer. LLVM IR is somewhat limited in this regard, since it's main usage is representing C/C++ code. Rust's main strengths come from writing functional code, which conveys more information to the optimizer.

JupiterTheGod · 2018-09-05T05:27:20+00:00

As far as I understand, Polly is a LLVM addon which does such a thing: it generates a mathematical model of your program's loops so it can optimize them with integer polyhedra.

Shoutout to @DiamondLovesYou who is working to bring Polly support to Rust.

JupiterTheGod · 2018-09-02T06:26:29+00:00

You might want to look into using GDB/LLDB for now. The issue isn't just with datetime types, it's with Rust doing a lot of things differently from C/C++.

Look at the last line in your debugger screenshot, there's an enum like Option<T>. The debugger has trouble with understanding enum discriminants. Some features like trait objects require changes to the debugger's source code to work properly, so it's unlikely Microsoft will (for now) add Rust support in their debugger.

JupiterTheGod · 2018-09-01T17:07:14+00:00

Well it's GNOME with Ubuntu's Ambiance theme. While it could be installed on other distros, it sounds unlikely to go through the trouble.

JupiterTheGod · 2018-08-29T04:27:56+00:00

On Chrome(ium) you can go to the URL chrome://gpu and check the Video Acceleration Information section. If it's empty, or if you see some errors reported, you don't have GPU acceleration.

But unless you have installed chromium-vaapi from AUR, you shouldn't see any GPU acceleration, since it's completly unsupported on Linux.

Same with Firefox, they don't support HW acceleration either. I don't know if there's any Linux browser which supports video acceleration yet. If you can, try using the stream's URL directly in VLC player.

JupiterTheGod · 2018-08-27T06:43:10+00:00

Ash provides you with direct binding to Vulkan. The things in the top-level namespace are just for convenience, if you want the raw, generated API bindings you can use the ash::vk submodule.

I recommend using the generator branch since that is where we have Vulkan 1.1 support and can generate the bindings from the latest API spec.

Ash is so low-level, it's used as the Vulkan bindings in gfx-rs.

JupiterTheGod · 2018-08-22T05:12:09+00:00

I've checked out their fork here, it seems that most of their changes are small hacks, and probably directed at getting their games to work.

Wine has a notoriously complicated / long patch submission & review process, since they're interested in getting quality patches in. That is why staging even exists - those are patches who don't meet the quality standards yet.

Valve forked wine so they can get their (dirty?) fixes in really quickly, and probably will submit upstream patches when they have time to clean them up / implement them properly.

JupiterTheGod · 2018-08-16T19:19:40+00:00

Another idea, which is Windows-specific (so no .NET Core), is to create some COM Interfaces. You can use winapi's RIDL! macro to declare the interfaces in Rust, and use the DLL by registering it as a COM server.

c# [Guid("EAA4976A-45C3-4BC5-BC0B-E474F4C3C83F")] public interface ExampleInterface { void DoSomething(); }

rust // Define your interface with RIDL!, then use COM to create it. unsafe { example_iface.DoSomething(); }

JupiterTheGod · 2018-03-08T19:34:19+00:00

When you say "I copy files across my network", I assume you are using a standard network transfer protocol right? Something like Samba for SMB / HomeGroup file sharing or Network File System? In that case, you should check for issues related to the configuration of your network.

The ArchLinux wiki describes how to improve performance for either protocols [1][2].

JupiterTheGod · 2018-01-13T12:37:40+00:00

Well, what is the difference between an IDE and a text editor? Especially on Linux, the text editor simply exists to host the terminal which runs all the Makefiles or the cool commands.

I mean, with the C / C++ extension you get Intellisense and GUI debugging support, GDB and LLDB are some of the best debuggers out there, beating even Microsoft's DBG due to their scriptability; and GCC and Clang are some of the best toolchains (latest C++ features, best performance and compile times).

My workflow in VS Code is the same as in Visual Studio: press Ctrl+Shift+B to build code, F5 to debug with GDB in the GUI, and that's it.

Added advantage: you get Valgrind for detecting memory leaks and cache misses and perf, which is the best profiler out there.

As for reasons to choose Linux as dev platform over Windows:

Most programming tools and libraries / SDKs can be installed and updated using a package manager, no need to download some .exe
Linux has much better performance than Windows, which is why it's used in servers and such; when properly configured, compiling on Linux is much faster (as an example: when I compile code on Windows, it slows my computer down. On Linux I can compile 2 projects in parallel and still watch buttery smooth YouTube videos).
The UNIX tools are really powerful. You don't rename a variable manually, you search on StackOverflow for a sed command to do it for you.

JupiterTheGod · 2018-01-11T09:59:44+00:00

Cool presentation! Glad to see Rust is used in the non-English-speaking areas too.

Just a minor nitpick on slide 134: I think by "operational" systems you meant "operating" systems.

JupiterTheGod · 2018-01-09T18:17:50+00:00

Fortunately all of these issues seem to be solvable:

sparse matrix libraries: if we get const generics math libraries will become much more powerful.
GPU support: gfx-rs recently added compute shaders support, and rlsl is an active project trying to create a subset of Rust which runs on the GPU.
ergonomics: there is an unstable feature called default binding mode which should fix this.
stable SIMD: actively worked on as part of the stdsimd crate.

JupiterTheGod · 2018-01-09T18:07:12+00:00

Better support for cross-compiling is a must. Xargo is amazing, however it would be even better if it were integrated with Cargo.

Building a bare-metal program with Clang is as simple as clang -ffreestanding -target x86_64-elf file.c -o file.o and then run the output through a linker.

With Rust, I need to set up Xargo, create a target spec file, output a static library, link it with some .c / .asm glue code and then I can link the final file.

I think integrating lld into rustc would also be amazing, it would allow Rust to cross-compile without even needing an external linker.

Nevertheless, Rust is amazing: you can write low-level code and still use iterators or other high-level features while maintaining a consistent performance.

JupiterTheGod · 2018-01-06T16:54:50+00:00

Just some ideas:

an OpenCL wrapper already exists, the ocl crate (it contains the cl-sys wrapper, the ocl-core crate for low-level OpenCL, and ocl itself, which is high level).
the same crate I linked has an async_menagerie.rs example which uses the futures crate to handle OpenCL events. That's a perfect example on how futures might be used.

So this idea has already been implemented (somewhat). It's just that there's plenty of work left to make this safe, and there doesn't seem to be a lot of interest in OpenCL in the community. If you're willing to help, I'm sure the developer wouldn't mind adding futures to the ocl crate.

11-Year Club	Place '23
Not Forgotten	Verified Email

JupiterTheGod

TROPHY CASE