#llvm c++ api

[kremlin]

How DOES the C preprocessor create two generations of completely asinine programmers??

oh man hahah oh maaan. ok, this won't be very approachable.

i don't recall what point i was trying to make with the whole "two generations" part but ill take this opportunity to justifiably hate on the preprocessor, holy fuck the amount of damage it has caused on software is immeasurable, if you ever thought computer programmers were smart people on principle...

the cpp:

there are like forty preprocessor directives, and they all inject a truly mind-boggling amount of vicious design problems and have done so for longer than ive been alive. there really only ever needed to be one: #include , if only to save you the trouble of manually having to copy header files in full & paste them at the top of your code. and christ almighty, we couldn't even get that right. C (c89) has way, waaaay fewer keywords than any other language. theres like 30, and half of those aren't ever used, have no meaning or impact in the 21st century (shit like "register" and "auto"). and C programmers still fail to understand all of them properly, specifically "static" (used in a global context) which marks some symbol as inelligible to be touched externally (e.g. you can't use "extern" to access it). the whole fucking point of static is to make #include'd headers rational, to have a clear seperation between external, intended-to-be-accessed API symbols, and internal, opaque shit. nobody bothers. it's all there, out in the open, if you #include something, you get all of it, and brother, this is only the beginning, you also get all of its preprocessor garbage.

this is where the hell begins:

#if #else

hey, do these look familiar? we already fucking have if/else. do you know what is hard to understand? perfectly minimally written if/else logic, in long functions. do you know what is nearly impossible to understand? poorly written if/else rats nests (which is what you find 99% of the time). do you know what is completely impossible to understand? that same poorly-written procedural if/else rat's nest code that itself is is subject to another higher-order if/else logic.

it's important to remember that the cpp is a glorified search/replace. in all it's terrifying glory it fucking looks to be turing complete, hell, im sure the C++ preprocessor is turing complete, the irony of this shouldn't be lost on you. if you have some long if/else logic you're trying to understand, that itself is is subject to cpp #if/#else, the logical step would be to run the cpp and get the output pure C and work from there, do you know how to do that? you open the gcc or llvm/clang man page, and your tty session's mem usage quadruples. great job idiot. trying figuring out how to do that in the following eight thousand pages. and even if you do, you're going to be running the #includes, and your output "pure C" file (bereft of cpp logic) is going to be like 40k lines. lol.

the worst is yet to come:

#define #ifdef #ifndef (<- WTF) #undef you can define shit. you can define "anything". you can pick a name, whatever, and you can "define it". full stop. "#define foo". or, you can give it a value: "#define foo 1". and of course, you can define it as a function: "#define foo(x) return x". wow. xzibit would be proud. you dog, we heard you wanted to kill yourself, so we put a programming language in your programming language.

the function-defines are pretty lol purely in concept. when you find them in the wild, they will always look something like this:

#define foo(x,y) \ (((x << y)) * (x))

i've seen up to seven parens in a row. why? because since cpp is, again, just a fucking find&replace, you never think about operator precedence and that leads to hilarious antipaterns like the classic

#define min(x,y) a < b ? a : b

which will just stick "a < b ? a: b" ternary statement wherever min(.. is used. just raw text replacement. it never works. you always get bitten by operator precedence.

the absolute worst is just the bare defines:

#define NO_ASN1 #define POSIX_SUPPORTED #define NO_POSIX

etc. etc. how could this be worse? first of all, what the fuck are any of these things. did they exist before? they do now. what are they defined as? probably just "1" internally, but that isn't the point, the philosophy here is the problem. back in reality, in C, you can't just do something like "x = 0;" out of nowhere, because you've never declared x. you've never given it a type. similar, you can't read its value, you'll get a similar compiler error. but cpp macros just suddenly exist, until they suddenly don't. ifdef? ifndef? (if not defined). no matter what, every permutation of these will have a "valid answer" and will run without problem. let me demonstrate how this fucks things up.

do you remember "heartbleed" ? the "big" openssl vulnerability ? probably about a decade ago now. i'm choosing this one specifically, since, for some reason, it was the first in an annoying trend for vulns to be given catchy nicknames, slick websites, logos, cable news coverage, etc. even though it was only a moderate vulnerability in the grand scheme of things...

(holy shit, libssl has had huge numbers of remote root vulns in the past, which is way fucking worse, heartbleed only gave you a random sampling of a tiny bit of internal memory, only after heavy ticking -- and nowadays, god, some of the chinese bluetooth shit would make your eyeballs explode if you saw it; a popular bt RF PHY chip can be hijacked and somehow made to rewrite some uefi ROMs and even, i think, the microcode on some intel chips)

anyways, heartbleed, yeah, so it's a great example since you could blame it two-fold on the cpp. it involved a generic bounds-checking failure, buf underflow, standard shit, but that wasn't due to carelessness (don't get me wrong, libssl is some of the worst code in existence) but because the flawed cpp logic resulted in code that:

A.) was de-facto worthless in definition B.) a combination of code supporting ancient crap. i'm older than most of you, and heartbleed happened early in my undergrad. the related legacy support code in question hadn't been relevant since clinton was in office.

to summarize, it had to do with DTLS heartbeats. DTLS involves handling TLS (or SSLv3, as it was then, in the 90s) only over UDP. that is how old we're talking. and this code was compiled into libssl in the early 2010s -- when TLS had been the standard for a while. TLS (unlike SSLv3 & predecessors) runs over TCP only. having "DTLS heartbeat support in TLS does not make sense by definition. it is like drawing a triangle on a piece of paper whose angles don't add up to 180.

how the fuck did that happen? the preprocessor.

why the fuck was code from last century ending up compiled in? who else but!! the fucking preprocessor. some shit like:

#ifndef TCP_SUPPORT <some crap related to UDP heartbeats> #endif ... #ifndef NO_UDP_ONLY <some TCP specific crap> #endif

the header responsible for defining these macros wasn't included, so the answer to BOTH of these "if not defined" blocks is true! because they were never defined!! do you see?

you don't have to trust my worldview on this. have you ever tried to compile some code that uses autoconf/automake as a build system? do you know what every single person i've spoken to refers to these as? autohell, for automatic hell. autohell lives and dies on cpp macros, and you can see firsthand how well that works. almost all my C code has the following compile process:

"$ make". done. Makefile length: 20 lines.

the worst i've ever deviated was having a configure script (probably 40 lines) that had to be rune before make. what about autohell? jesus, these days most autohell-cursed code does all their shit in a huge meta-wrapper bash script (autogen.sh), but short of that, if you decode the forty fucking page INSTALL doc, you end up with:

$ automake (fails, some shit like "AUTOMAKE_1.13 or higher is required) $ autoconf (fails, some shit like "AUTOMCONF_1.12 or lower is required) $ aclocal (fails, ???) $ libtoolize (doesn't fail, but screws up the tree in a way that not even a `make clean` fixes $ ???????? (pull hair out, google) $ autoreconf -i (the magic word) $ ./configure (takes eighty minutes and generates GBs of intermediaries) $ make (runs in 2 seconds)

in conclusion: roflcopter

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ disclaimer | private policy | unsubscribe

[ultramaga]

Like OS/390, z/OS combines a number of formerly separate, related products, some of which are still optional. z/OS has the attributes of modern operating systems but also retains much of the older functionality originated in the 1960s and still in regular use—z/OS is designed for backward compatibility.

Major characteristics

z/OS supports[NB 2] stable mainframe facilities such as CICS, COBOL, IMS, PL/I, IBM Db2, RACF, SNA, IBM MQ, record-oriented data access methods, REXX, CLIST, SMP/E, JCL, TSO/E, and ISPF, among others.

z/OS also ships with a 64-bit Java runtime, C/C++ compiler based on the LLVM open-source Clang infrastructure,[3] and UNIX (Single UNIX Specification) APIs and applications through UNIX System Services – The Open Group certifies z/OS as a compliant UNIX operating system – with UNIX/Linux-style hierarchical HFS[NB 3][NB 4] and zFS file systems. These compatibilities make z/OS capable of running a range of commercial and open source software.[4] z/OS can communicate directly via TCP/IP, including IPv6,[5] and includes standard HTTP servers (one from Lotus, the other Apache-derived) along with other common services such as SSH, FTP, NFS, and CIFS/SMB. z/OS is designed for high quality of service (QoS), even within a single operating system instance, and has built-in Parallel Sysplex clustering capability.

Actually, that is wayyy too exciting for a bedtime story! I remember using the internet on a unix terminal long before the world wide web. They were very excited by email, but it didn't impress me much. Browers changed the world.

[govindhtech]

What is SPIR-V? How SYCL Expands C++ Virtual Functions

Discover SPIR-V and how it lets SYCL support heterogeneous C++ virtual functions. This post covers two notions that take SYCL in different directions.

At the 13th IWOCL International Workshop on OpenCL and SYCL, Intel's Alexey Sachiko presented several experimental ideas to expand SYCL's use and scope as a cross-architecture framework for accelerated computing from edge to cloud and AI PC to supercomputer.

Virtual functions are discussed first. SYCL aims to make C++ to multiarchitecture computing a smooth transition. Virtual functions can be redefined in derived classes to offload kernels, so expanding them is consistent.

The second concept is abstraction, although not of base class functions. Increased SPIR-V backend abstraction support will help SYCL's low-level implementation interface with the wide range of hardware architectures and custom accelerators available. The purpose is to improve SYCL LLVM-SPIR-V collaboration.

In many ways, SYCL is becoming more general. SYCL abstraction, from low-level hardware abstraction to C++ virtual function objects, will be discussed as its development continues.

SYCL Virtual Functions

Virtual functions have been used in C++ program development since its inception. Popular backend abstractions like the Kokkos C++ performance portability interface, used in high-speed scientific computing, require it.

Even though the SYCL standard allows one-definition rule (ODR) virtual inheritance, device functions cannot invoke virtual member functions, making code migration difficult.

Alexey begins his talk with a simple base class with a few virtual methods, direct classes with overrides, and offload kernels.

Easy oneAPI kernel property addition for virtual class inheritance.

The experimental indirectly callable function properties from the sycl_ext_oneapi_kernel_properties GitHub sandbox are included first. A function or offload kernel can be identified as a device function and invoked indirectly.

Why do virtual functions need this?

Program objects have virtual class overrides tables. For each virtual function call, a pointer from this table is loaded to call the relevant derived function.

In the Base function, SYCL device code limitations are violated when foo throws an exception and allocates memory.

The indirectly_callable feature makes the virtual function a device function with all its limitations, like the SYCL_EXTERNAL macro.

For the same reason, assume_indirect_calls properties_tag is needed. Kernel virtual calls without this property fail.

Alexey then discusses more advanced topics and future projects like optional kernel feature support and reqd_sub_group_size.

Considering Implementation

When designing an app with this new functionality, consider these high-level factors:

SYCL applications with virtual function support should separate each virtual function set into a device image. If you use optional kernel features, duplicate with empty functions. This provides all link stage symbols without speculative compilation.

For kernel-equipped device images, connect all images with the same virtual function sets.

When targeting SPIR-V, this happens runtime. Otherwise, it happens during build link.

See the for more on technology implementation.

Ext_intel_virtual_functions is in Intel's LLVM GitHub.

Test cases for sycl_ext_oneapi_virtual_functions extension in the same source code tree.

Improve SYCL Code using Virtual Functions

Recent versions of the Intel DPC++ Compatibility Tool 2025.1 and the Intel oneAPI DPC++/C++ Compiler include experimental and evolving virtual function functionality.

SPIR-V Backend SYCL Application

SPIR-V, a binary intermediate language for compute kernels and graphical-shader stages, was specified by the Khronos Group, which regulates SYCL. Its portable format unifies intermediate representation and programming interface for heterogeneous accelerators.

A varied language and API environment supports it

This creates a duality of intermediate abstracted hardware backend representation for C++ compilers based on LLVM and LLVM Intermediate Representation, as with all CLANG project compilers.

The SPIR-V to LLVM Translator provides bidirectional translation, however it is not updated as part of the LLVM project tree, making it prone to rare incompatibilities and disconnects.

To remedy this, Intel's compiler development team recommends SPIR-V as a normal LLVM code generation target, like other hardware target runtimes. Thus, the LLVM project includes an SPIR-V backend to ensure thorough integration testing and allow it to be used with OpenAI Triton backends, graphics-oriented programming models like Vulkan or HLSL, and heterogeneous computing with OpenCL or SYCL.

With extensive documentation, an active and growing LLVM SPIR-V working group supports and maintains the Backend:

SPIR-V Target User Guide

Clang SPIR-V Support

Intel compiler developers help resolve LLVM IR semantics and specifications to SPIR-V mapping difficulties as part of Intel's commitment to the open source community.

In his presentation, Alexey Sachkov details them and Intel's solution.

Is Spir-V?

SPIR-V, a high-level binary intermediate language, defines compute kernels and graphics shaders. It was created by Khronos Group, an OpenGL, Vulkan, and OpenCL organisation.

What that means and why it matters:

IR: GPU assembly language universal. Developers utilise GLSL or HLSL instead of writing shader code for each GPU architecture, which is complicated. Compilers create SPIR-V from this source code.

SPIR-V comes as compiled binary, not source code. This has numerous benefits:

Application startup and shader loading are faster when drivers don't parse and compile text-based shader code.

IP Protection: Shader source code is hidden, making algorithm reverse-engineering harder.

Closer Hardware: SPIR-V's lower-level representation allows more direct control and performance adjustment than high-level languages.

Standard and Portable: Before SPIR-V, each graphics API (like OpenGL or DirectX) handled shaders differently, requiring several compilers and duplication. SPIR-V is a royalty-free, open standard for graphics and computing APIs.

New, low-overhead graphics API Vulkan leverages SPIR-V shaders.

Although optional, OpenGL 4.6 and later support SPIR-V.

OpenCL: GPU/processor parallelism.

In Shader Model 7.0, Microsoft aims to replace DXIL with SPIR-V for Direct3D interoperability. Important for graphics ecosystem unity.

SYCL Code Compilation Target: SPIR-V

The SPIR-V Backend for LLVM is still being developed, however it has been a project target since January 2025. Try it and comment on the LLVM project RFC page.

Use SPIR-V, oneAPI, and SYCL Now

To learn about these and other new features in LLVM-based C++ compilers and toolchains with SYCL support, see the Intel oneAPI DPC++ C++ Compiler and oneAPI Overview landing page.

[mycplus]

Choosing the Right C++ Compiler for Your Project in 2025

Selecting the right C++ compiler is crucial for optimizing the performance, portability, and maintainability of your code. As technology evolves, compilers offer increasingly robust features to support modern C++ standards. Here’s a comprehensive guide to help you make an informed decision when choosing a compiler in 2025.

Choosing the Right Compiler for Your Needs

When choosing the right C++ compiler for your project, it’s helpful to explore the options available in the market. For a detailed overview of the best C++ compilers, including GCC, Clang, and MSVC, check out our guide on Best C++ Compilers to Use in 2024. This resource outlines features, use cases, and recommendations to help you make an informed decision.

For Beginners: Start with GCC or MSVC for their ease of use and excellent documentation.

For Advanced Developers: Use Clang or Intel C++ Compiler for their sophisticated optimization capabilities.

For Cross-Platform Projects: GCC and Clang are ideal due to their support for multiple operating systems.

For Enterprise Development: MSVC integrates seamlessly with enterprise Windows environments.

Key Factors to Consider

Standard Compliance Modern C++ compilers must support recent standards like C++20 and emerging features of C++23. Compliance ensures compatibility with cutting-edge libraries and features.

Platform Compatibility Consider the platforms your application will target. For instance, if you're building cross-platform software, a compiler like GCC or Clang is ideal due to its extensive OS support.

Performance Optimization Some compilers excel at producing highly optimized binaries. If runtime performance is critical, benchmarking compilers for your use case can provide valuable insights.

Development Ecosystem A compiler integrated into a robust IDE, like Microsoft Visual C++ with Visual Studio, can boost productivity with features such as advanced debugging and autocomplete.

Community and Support Active community support ensures access to tutorials, forums, and updates, which can be invaluable during development.

Popular C++ Compilers in 2025

GCC (GNU Compiler Collection)

Overview: Open-source and widely used across Linux systems, GCC supports the latest C++ standards and provides excellent optimizations.

Strengths: Cross-platform compatibility, strong community support, and frequent updates.

Use Cases: Ideal for cross-platform development and open-source projects.

Clang/LLVM

Overview: Known for its modular architecture and fast compilation speeds, Clang offers excellent diagnostics for developers.

Strengths: Advanced error messages, modern language feature support, and great integration with tools like Xcode.

Use Cases: Perfect for macOS and projects requiring integration with static analysis tools.

Microsoft Visual C++ (MSVC)

Overview: Integrated with the Visual Studio IDE, MSVC is a popular choice for Windows developers.

Strengths: Powerful debugging tools, easy integration with Windows APIs, and strong performance optimizations.

Use Cases: Best suited for Windows desktop and enterprise software development.

C++ Builder

Overview: A commercial compiler focused on rapid application development (RAD) for cross-platform applications.

Strengths: Easy-to-use visual tools, database integration, and support for multiple platforms.

Use Cases: Ideal for developers prioritizing GUI-heavy applications.

Intel C++ Compiler (ICX)

Overview: Tailored for performance-critical applications, ICX provides advanced optimizations for Intel processors.

Strengths: Best-in-class performance, compatibility with major development environments, and support for vectorization.

Use Cases: High-performance computing, machine learning, and scientific applications.

[dot-mirrors]

Securing Your Code: An In-Depth Guide to C++ Obfuscation

In today's software development landscape, protecting your code from unauthorized access and tampering is more important than ever. One of the most effective methods for securing your code is C++ obfuscation. This technique not only enhances the security of your applications but also protects your intellectual property. In this article, we will delve into the intricacies of C++ obfuscation, exploring its benefits, techniques, and best practices. If you're looking to safeguard your code, understanding the ins and outs of C++ obfuscation is crucial.

What is C++ Obfuscation?

C++ obfuscation is a process that transforms the code into a format that is difficult to understand and reverse-engineer. The primary purpose of this technique is to protect the software from being easily deciphered by malicious entities. Obfuscation can involve various methods, such as renaming variables, encrypting strings, and altering control flow. These transformations make it challenging for anyone attempting to decompile or analyze the code.

Benefits of C++ Obfuscation

Implementing C++ obfuscation in your projects brings several advantages. First and foremost, it significantly enhances the security of your code by making it harder for attackers to reverse-engineer and exploit vulnerabilities. This added layer of protection helps safeguard your intellectual property and prevents unauthorized access to your software. Additionally, obfuscation can deter software piracy and reduce the risk of code theft.

Common Techniques in C++ Obfuscation

String Encryption

String encryption is a popular obfuscation technique that involves encoding strings within the code to make them unreadable. During execution, these strings are decrypted, allowing the program to function normally. The primary advantage of string encryption is that it hides sensitive information, such as passwords and API keys, from plain sight. However, it can also increase the complexity of the code and impact performance.

Control Flow Obfuscation

Control flow obfuscation alters the logical flow of the program, making it difficult for an attacker to understand the code's execution path. This technique can involve adding fake branches, loops, and conditional statements that obscure the actual logic. While control flow obfuscation provides robust protection, it can also complicate debugging and maintenance.

Virtualization

Virtualization transforms the code into a virtual machine language, which is then interpreted by a custom virtual machine at runtime. This method offers high security by creating an additional layer between the code and the hardware. The process involves converting standard instructions into virtual instructions, which are difficult to reverse-engineer. However, virtualization can impact performance and increase the size of the executable.

Implementing C++ Obfuscation in Your Projects

Choosing the Right Tools

When it comes to selecting obfuscation tools, there are several options available, each with its own set of features and capabilities. Popular tools include Obfuscator-LLVM, Stunnix C/C++ Obfuscator, and VMProtect. When choosing a tool, consider factors such as ease of integration, performance impact, and the level of security provided.

Best Practices

Integrating obfuscation into your development cycle requires careful planning. Start by identifying the critical sections of your code that need protection. Implement obfuscation gradually and test thoroughly to ensure that the functionality remains intact. Maintaining a balance between code readability and obfuscation complexity is essential to prevent future maintenance issues.

Case Study: AntiSpy SDK

The AntiSpy SDK is a cutting-edge C obfuscation library that secures code across platforms using the latest technologies and C standards. This powerful tool protects your code with encrypted strings during compilation, virtualization, and control flow obfuscation. By implementing AntiSpy SDK, developers can ensure that their applications are safeguarded against reverse engineering and unauthorized access. Numerous real-world applications have successfully utilized this SDK, demonstrating its effectiveness in enhancing code security.

Conclusion

In conclusion, C++ obfuscation is a vital practice for developers aiming to secure their code and protect their intellectual property. By understanding and implementing various obfuscation techniques, you can significantly enhance the security of your applications. Tools like AntiSpy SDK offer advanced features that make the obfuscation process more efficient and effective. Embrace C++ obfuscation today to safeguard your software and stay ahead of potential threats.

[this-week-in-rust]

This Week in Rust 487

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @ThisWeekInRust on Twitter or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Foundation

Welcoming Software Engineer Adam Harvey to the Rust Foundation Team

New SLSA++ Survey Reveals Real-World Developer Approaches to Software Supply Chain Security

Newsletters

This Month in Rust OSDev: February 2023 | Rust OSDev

Project/Tooling Updates

autometrics 0.3: Defining Service-Level Objectives (SLOs) in Rust Source Code

Typst starts its public beta test and goes open source

Klint: Compile-time Detection of Atomic Context Violations for Kernel Rust Code

rust-analyzer changelog #173

Gitea 1.19.0 is released

Fornjot (code-first CAD in Rust) - Weekly Release - Finished!

activitypub-federation 0.4.0: Major rewrite with improvements to usability and documentation

Quickwit 0.5: Distributed tracing with Open Telemetry and Jaeger, VRL, Pulsar support, and more...!

pavex, a new Rust web framework - Progress report #2

Observations/Thoughts

Temporary lifetimes

Must move types

Defer blocks and async drop

A template proposal for adopting Rust at work

Patterns & Abstractions

Const as an auto trait

Item Patterns And Struct Else

Why use Rust on the backend?

The Importance of Logging

AsRef vs Borrow trait (ft. ChatGPT)

[audio] Cargo Limit with Alexander Lopatin :: Rustacean Station

[video] The Truth about Rust/WebAssembly Performance

Rust Walkthroughs

Using Cow in Rust for efficient memory utilization

STM32F4 Embedded Rust at the PAC: Creating Hardware Abstractions

STM32F4 Embedded Rust at the PAC: GPIO Interrupts

Build your own Counting Bloom Filter

[video] Setting up CI and property testing for a Rust crate

Research

Verus: Verifying Rust Programs using Linear Ghost Types

Ownership guided C to Rust translation

Optimizing a parser/compiler with data-oriented design: a case study

Miscellaneous

Bringing Rust to the Xen Project

The birth of a package manager [written in Rust ;)]

Crate of the Week

This week's crate is Speedy2D, a crate offering cross-platform Hardware-accelerated drawing of shapes, images, and text, with an easy to use API.

Thanks to Aleksey Kladov for the suggestion!

Please submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

racoon - Open Source IAM call for contributors

Ockam - create clap command to show the details of a secure-channel listener on a node

Ockam - create clap command to delete an existing Forwarder on a node

Ockam - ockam run - a single command to run many ockam “create” commands

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from the Rust Project

321 pull requests were merged in the last week

inherit_overflow: adapt pattern to also work with v0 mangling

read_buf_exact: on error, all read bytes are appended to the buffer

add enable-warnings flag for llvm, and disable it by default

add useless_anonymous_reexport lint

add note for mismatched types because of circular dependencies

do not ICE for unexpected lifetime with ConstGeneric rib

don't ICE for late-bound consts across AnonConstBoundary

don't suggest similar method when unstable

fix ICE in custom-test-frameworks feature

fix ClashingExternDeclarations lint ICE

emit diagnostic when calling methods on the unit type in method chains

ensure ptr::read gets all the same LLVM load metadata that dereferencing does

erase escaping late-bound regions when probing for ambiguous associated types

error-msg: expand suggestion for unused_def lint

error-msg: impl better suggestion for E0532

fall back to old metadata computation when type references errors

fast path for process_obligations

fix generics_of for impl's RPITIT (Return Position Impl Trait In Trait) synthesized associated type

fix generics mismatch errors for RPITITs on -Zlower-impl-trait-in-trait-to-assoc-ty

install projection from RPITIT to default trait method opaque correctly

make fns from other crates with RPITIT work for -Zlower-impl-trait-in-trait-to-assoc-ty

fix object safety checks for new RPITITs

fix linker detection for clang with prefix

flatten/inline format_args!() and (string and int) literal arguments into format_args!()

implement FixedSizeEncoding for UnusedGenericParams

implement checked Shl/Shr at MIR building

only expect a GAT const param for type_of of GAT const arg

pass the right HIR back from get_fn_decl

remove identity_future indirection

remove box expressions from HIR

replace ZST operands and debuginfo by constants

simplify proc macro signature validity check

some cleanups in our normalization logic

suggest surrounding the macro with {} to interpret as a statement

use unused_generic_params from crate metadata

miri: move reject with isolation logic in fcntl

miri: tree borrows

properly allow macro expanded format_args invocations to use captures

optimize dep node backtrace and ignore fatal errors

fallback to lstat when stat fails on Windows

stabilise unix_socket_abstract

stabilize atomic_as_ptr

use index based drop loop for slices and arrays

allow using Range as an Iterator in const contexts

cargo: accurately show status when downgrading dependencies

cargo: add --ignore-rust-version flag to cargo install

cargo: add more information to wait-for-publish

cargo: align semantics of generated vcs ignore files

cargo: handle case mismatches when looking up env vars in the Config snapshot

rustdoc: correctly merge import's and its target's docs in one more case

rustdoc: docFS: replace rayon with threadpool and enable it for all targets

rustdoc: implement bag semantics for function parameter search

clippy: add allow_attribute lint

clippy: new lint to detect &std::path::MAIN_SEPARATOR.to_string()

clippy: enhance ifs_same_cond to warn same immutable method calls as well

clippy: fix almost_swapped false positive (let mut a = b; a = a)

clippy: fix almost_swapped: Ignore external macros

clippy: issue function modifiers in the right order in manual_async_fn lint

rust-analyzer: add an autofix for inserting an unsafe block to missing unsafe diagnostic

rust-analyzer: prioritize missing variants in match pattern completions

rust-analyzer: allow the status bar item to be clicked again

rust-analyzer: fix reference completions being emitted in places other than argument lists

rust-analyzer: fix rustc proc-macro handling being broken on the rustc workspace itself

rust-analyzer: fix visibility resolution not respecting parent blocks

rust-analyzer: only skip adjustment hints for block, if and match expressions for reborrows

rust-analyzer: lint incoherent inherent impls

Rust Compiler Performance Triage

A mixed week, with some nice wins, but also at least two PR's that were subsequently reverted, such as the upgrade to LLVM 16. We do want to note PR #108944, which cut down on crate metadata, binary sizes, and was an overall win on execution time for many benchmarks.

Triage done by @pnkfelix. Revision range: 00587489..ef03fda3

1 Regressions, 4 Improvements, 11 Mixed; 2 of them in rollups 37 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs

[disposition: merge] RFC: result_ffi_guarantees

Tracking Issues & PRs

[disposition: merge] Initial support for return type notation (RTN)

[disposition: merge] rustdoc: add support for type filters in arguments and generics

[disposition: merge] rustdoc: run more HIR validation to mirror rustc

[disposition: merge] Add a builtin FnPtr trait that is implemented for all function pointers

[disposition: merge] Clarify stability guarantee for lifetimes in enum discriminants

New and Updated RFCs

No New or Updated RFCs were created this week.

Call for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. The following RFCs would benefit from user testing before moving forward:

No RFCs issued a call for testing this week.

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Upcoming Events

Rusty Events between 2023-03-22 - 2023-04-19 🦀

Virtual

2023-03-22 | Virtual (Richmond, VA, US) | Rustaceans RVA

Rustaceans RVA - March Meetup

2023-03-27 | Virtual | Rust Formal Methods Interest Group

Flux: Ergonomic Verification of Rust Programs with Liquid Types

2023-03-28 | Virtual (Berlin, DE) | Berline.rs - OpenTechSchool Berlin

Rust Hack and Learn

2023-03-28 | Virtual (Dallas, TX, US) | Dallas Rust

Last Tuesday

2023-03-28 | Virtual (Redmond, WA, US) | Microsoft Reactor Redmond

Crack code interview problems in Rust: S2 Ep3

2023-03-29 | Virtual (Cardiff, UK) | Rust and C++ Cardiff

Writing your own rust 'book' with mdBook

2023-03-31 | Virtual (Tunis, TN) | Rust Tunisia

Rust Meetup Tunisia - Volume I, Number III

2023-04-04 | Virtual (Buffalo, NY, US) | Buffalo Rust Meetup

Buffalo Rust User Group, First Tuesdays

2023-04-05 | Virtual (Indianapolis, IN, US) | Indy Rust

Indy.rs - with Social Distancing

2023-04-05 | Virtual (Stuttgart, DE) | Rust Community Stuttgart

Rust-Meetup

2023-04-11 | Virtual (Berlin, DE) | Berline.rs - OpenTechSchool Berlin

Rust Hack and Learn

2023-04-11 | Virtual (Dallas, TX, US) | Dallas Rust

Second Tuesday

2023-04-11 | Virtual | Rust Live

Rust Live: Asynchronous Rust

2023-04-18 | Virtual (Washington, DC, US) | Rust DC

Mid-month Rustful—Introducing duplicate! and the peculiarities of proc macros

2023-04-19 | Virtual (Vancouver, BC, CA) | Vancouver Rust

Rust Study/Hack/Hang-out

Europe

2023-03-28 | Zurich, CH | Rust Zurich

High performance concurrent data structures in Rust - March Meetup

2023-03-29 | Paris, FR | Rust Paris

Rust Paris meetup #57

2023-04-04 | Berlin, DE | Berline.rs

Rust and Tell - Goodbye👋 Edition

2023-04-06 | Lyon, FR | Rust Lyon

Rust Lyon Meetup #3

2023-04-19 | Zurich, CH | Rust Zurich

sett: data encryption and transfer made easy(ier)

Asia

2023-04-08 | Kyoto, JP | Kansai Rust

Demystifying Closures

2023-04-12 | Kuala Lumpur, MY | Rust Malaysia; Telegram

Rust Meetup Malaysia April 2023: How far is Dioxus from React? by Ivan Tham | Map

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

The generated program is a random sequence of bytes that just happens to take the shape of a seemingly working program by accident. Such is the joy of code that causes UB. You cannot deduce anything from what happens when you execute a program with UB, since that act is by itself meaningless. You need to establish that your program has no UB before making any inference based on what you see the program do after it came out of the compiler.

– Ralf Jung on github

Thanks to bugaevc for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin, bennyvasquez.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

[csharp-official]

While indeed it is true that C and C++ have decades of headsup, to me it feels like a lot of issues with platform support could be fixed if Rust had a GCC frontend as an alternative to LLVM frontend... although Rust also assumes power-of-two-bits integral types, so I guess exotic archs could be a problem. Not sure how many are there of these... Also different lengths of data pointers vs function pointers appear sometimes in embedded, so I hope Rust does not make an assumption on that.

And yeah I can certainly imagine how extension software in Rust may not necessarily work well... but Rust's lack of complex runtime and direct compilation to native code would be useful for writing code that is supposed to be called from other languages - by exposing the C API shared library.

Does carcinisation mean everything will eventually be rewritten in rust?

- @assembly-official

Hopefully not! Certain domains just really do not suit rust well. It's an awful first language, of course, and python has many strengths which suit it to the academic / scientific world. I wouldn't want to use rust as an extension language for other software, either, unless it's written in rust itself. Lots of things like that which I'm not fully awake enough to think of.

Additionally, as I've pointed out elsewhere, rust's platform support is pretty minimal compared to C/C++. Those languages have *decades* of advantage on rust (in addition to much larger developer communities) and I'm not holding out hope that rust ever catches up.

This is not to discount rust's advantages, of course, I just don't think it can, or should, replace everything. I understand the "rewrite it all in rust" fervor, and have made jokes along those lines myself, but it's always in good fun and never serious.

[nintedu-blog]

Why Do Programmers prefer Kotlin over Java Programming?

Android applications are evolving with time. Developers are searching for new ways that to boost their apps in terms of usability and stability. After Java, firms are adopting Kotlin at a powerful rate.

Unlike Java and different languages, Kotlin may be a fairly new language. it's developed exploitation the strength of Java and therefore the power of C++. Kotlin may be a high-level ASCII text file artificial language, presently targeting Java and JavaScript. it's wide employed in automaton app development.

Kotlin runs on a JVM and uses the LLVM compiler infrastructure. It resolved several problems that Java developers were facing earlier. Kotlin is influenced by many standard languages like Scala, Groovy, Gosu, etc. It primarily uses existing Java categories to supply superb results.

Why you must like Kotlin Over Java?

Kotlin is thought for its code safety, clarity and particularly ability. you'll be able to decision Java anytime whereas writing code in Kotlin. it's an excellent feature-packed IDE and tools support. you'll be able to even use its extension functions to make clean genus Apis. So, let’s see some blessings of Kotlin as compared to Java.

1. Support for practical Programming

When a developer starts engaged on a computer code or application development project, he/she typically have an inventory of tasks to be done and targets to accomplish.

With Kotlin, they'll solve issues a lot of simply and fastly. it's higher support for practical programming (than Java) that enables developers to use operate ideas a lot of in brief. it'll not solely improve the performance however conjointly facilitate developers to keep up the consistency.

2. Kotlin is curt

Gone ar the times once developers ought to write pages of code to attain some common practicality. Kotlin permits you to unravel a similar downside in fewer lines of code. Kotlin may be a far more curt than Java. It doesn’t solely save time however conjointly promotes readability and code maintainability.

If you're a developer, you won’t ought to deep dive into the ocean of logic and code to unravel an easy bug. With Kotlin, you'll be able to scan, write and alter code a lot of expeditiously. Kotlin brings several helpful options like sensible casts, knowledge categories, kind interference, etc.

[hackgit]

[Media] ​​Triton

​​Triton A dynamic binary analysis library. It provides internal components that allow you to build your program analysis tools, automate reverse engineering, perform software verification or just emulate code. ▫️ Dynamic symbolic execution ▫️ Dynamic taint analysis ▫️ AST representation of the x86, x86-64, ARM32 and AArch64 ISA semantic ▫️ Expressions synthesis ▫️ SMT simplification passes ▫️ Lifting to LLVM as well as Z3 and back ▫️ SMT solver interface to Z3 and Bitwuzla ▫️ C++ and Python API https://github.com/jonathansalwan/Triton

[canmom]

Natalie Lawhead does good as ever, this is one of the biggest collections of game engines I've seen anyone put together.

It's worth discussing what's missing from a lot of these engines - the features that kept people with Unity instead of these alternatives. Not to say we have to stay with Unity, but the big challenges that other engines have to meet.

The biggest one is multiplatform support. Particularly if you want to release games on consoles (Android excepted), you have to deal with all sorts of opaque black-box proprietary APIs and all sorts of weird gotchas and headaches. One of the best features of Unity is that it runs, and runs well, on nearly anything. Which isn't to say Unity doesn't have its own gotchas trying to build for different platforms, but it provides a very good abstraction over a lot of difficulty.

Unfortunately, console support is a big barrier for a lot of open-source projects. Godot spells it out pretty clearly. The console manufacturers won't license their proprietary devkits to an open source project.

This means the only real alternative for console dev is Unreal, or a proprietary engine. Unreal isn't quite as universal as Unity, but it's fairly close. It handily beats Unity on high-end graphics features. However, its design is generally less flexible, and the editor is quite cumbersome and demands a pretty high-end PC. It also doesn't have the CPU performance of Unity DOTS, even though it's written in pure C++.

(For standalone VR, Unity has been pretty much the only game in town, but the situation isn't as dire as other consoles since Android is at least open source and OpenXR provides an open source abstraction layer that other engines can implement. So while there's not a great Unity alternative yet, it's entirely possible that Bevy or something else could become viable.)

That leads in to the second reason - performance. I've been watching people in the Latios Framework discord try and figure out some alternative ECS-based engine for the kind of super-high-performance code that Unity DOTS enables. Unity DOTS is kind of an engineering miracle. The Burst compiler is fantastic - only the Rust compiler can stand alongside it really (not surprising since both are based on LLVM) - and there are a lot of extremely smart design choices in how it handles e.g. ECS iteration and rendering.

There are other ECS-based game engines out there, with Bevy probably the most advanced. It's also possible to cobble together your own by combining an existing engine with an existing ECS library. The problem is that for a realistic game engine that goes beyond a tech demo, there are a lot of pitfalls that can erode the benefits of ECS (a somewhat polemic article, but a good explanation of how ECS alone doesn't guarantee great cache performance). Bevy currently doesn't have the rendering performance of Entities Graphics, although it's moving in an exciting way.

Unity is a strange beast - it's a hodgepodge of features, some of them really cutting edge, some of them more or less abandoned after the people championing it left the company. There are usually multiple ways to do any given thing (e.g. user input or UI), and it's a bit of a steep learning curve to go from 'using Unity' to 'using Unity well'. However, the good parts of Unity are actually really good. It's taken years to get them this good. It sucks to have to reinvent it.

(The third reason is of course there's a huge amount of expertise and assets and shit built up around Unity. But - unless Unity does some pretty drastic actions to regain trust, or it dies and gets opensourced - that can't be helped, the ship's going down, not now but likely in a year or two when the currently-in-progress Unity projects have been released.)

It's probably going to be pretty chaotic for a while. What I really hope is that when all the dust settles, the 'next Unity' will be free software that can thrive as much as Blender has without risking this kind of 'enshittification'. With both this and Flash, it's fucking appalling that such a huge block of cultural output could be put at risk of being erased by the actions of one company. Also it will be the year of Linux on the desktop and federated social media you guys. For real! I promise!

A great look at what Unity alternatives there are out there besides running from one for-profit corporate product to the next

[govindhtech]

SYCL 2020’s Five New Features For Modern C++ Programmers

SYCL

For accelerator-using C++ programmers, SYCL 2020 is interesting. People enjoyed contributing to the SYCL standard, a book, and the DPC++ open source effort to integrate SYCL into LLVM. The SYCL 2020 standard included some of the favorite new features. These are Intel engineers’ views, not Khronos’.

Khronos allows heterogeneous C++ programming with SYCL. After SYCL 2020 was finalized in late 2020, compiler support increased.

SYCL is argued in several places, including Considering a Heterogeneous Future for C++ and other materials on sycl.tech. How will can allow heterogeneous C++ programming with portability across vendors and architectures? SYCL answers that question.

SYCL 2020 offers interesting new capabilities to be firmly multivendor and multiarchitecture with to community involvement.

The Best Five

A fundamental purpose of SYCL 2020 is to harmonize with ISO C++, which offers two advantages. First, it makes SYCL natural for C++ programmers. Second, it lets SYCL test multivendor, multiarchitecture heterogeneous programming solutions that may influence other C++ libraries and ISO C++.

Changing the base language from C++11 to C++17 allows developers to use class template argument deduction (CTAD) and deduction guides, which necessitated several syntactic changes in SYCL 2020.

Backends allow SYCL to target more hardware by supporting languages/frameworks other than OpenCL.

USM is a pointer-based alternative to SYCL 1.2.1’s buffer/accessor concept.

A “built-in” library in SYCL 2020 accelerates reductions, a frequent programming style.

The group library abstracts cooperative work items, improving application speed and programmer efficiency by aligning with hardware capabilities (independent of vendor).

Atomic references aligned with C++20 std::atomic_ref expand heterogeneous device memory models.

These enhancements make the SYCL ecosystem open, multivendor, and multiarchitecture, allowing C++ writers to fully leverage heterogeneous computing today and in the future.

Backends

With backends, SYCL 2020 allows implementations in languages/frameworks other than OpenCL. Thus, the namespace has been reduced to sycl::, and the SYCL header file has been relocated from to .

These modifications affect SYCL deeply. Although implementations are still free to build atop OpenCL (and many do), generic backends have made SYCL a programming approach that can target more diverse APIs and hardware. SYCL can now “glue” C++ programs to vendor-specific libraries, enabling developers to target several platforms without changing their code.

SYCL 2020 has true openness, cross-architecture, and cross-vendor.

This flexibility allows the open-source DPC++ compiler effort to support NVIDIA, AMD, and Intel GPUs by implementing SYCL 2020 in LLVM (clang). SYCL 2020 has true openness, cross-architecture, and cross-vendor.

Unified shared memory

Some devices provide CPU-host memory unified views. This unified shared memory (USM) from SYCL 2020 allows a pointer-based access paradigm instead of the buffer/accessor model from SYCL 1.2.1.

Programming with USM provides two benefits. First, USM provides a single address space across host and device; pointers to USM allocations are consistent and may be provided to kernels as arguments. Porting pointer-based C++ and CUDA programs to SYCL is substantially simplified. Second, USM allows shared allocations to migrate seamlessly between devices, enhancing programmer efficiency and compatibility with C++ containers (e.g., std::vector) and algorithms.

Three USM allocations provide programmers as much or as little data movement control as they want. Device allocations allow programmers full control over application data migration. Host allocations are beneficial when data is seldom utilized and transporting it is not worth the expense or when data exceeds device capacity. Shared allocations are a good compromise that immediately migrate to use, improving performance and efficiency.

Reductions

Other C++ reduction solutions, such as P0075 and the Kokkos and RAJA libraries, influenced SYCL 2020.

The reducer class and reduction function simplify SYCL kernel variable expression using reduction semantics. It also lets implementations use compile-time reduction method specialization for good performance on various manufacturers’ devices.

The famous BabelStream benchmark, published by the University of Bristol, shows how SYCL 2020 reductions increase performance. BabelStream’s basic dot product kernel computes a floating-point total of all kernel work items. The 43-line SYCL 1.2.1 version employs a tree reduction in work-group local memory and asks the user to choose the optimal device work-group size. SYCL 2020 is shorter (20 lines) and more performance portable by leaving algorithm and work-group size to implementation.

Group Library

The work-group abstraction from SYCL 1.2.1 is expanded by a sub-group abstraction and a library of group-based algorithms in SYCL 2020.

Sub_group describes a kernel’s cooperative work pieces running “together,” providing a portable abstraction for various hardware providers. Sub-groups in the DPC++ compiler always map to a key hardware concept SIMD vectorization on Intel architectures, “warps” on NVIDIA architectures, and “wavefronts” on AMD architectures enabling low-level performance optimization for SYCL applications.

In another tight agreement with ISO C++, SYCL 2020 includes group-based algorithms based on C++17: all_of, any_of, none_of, reduce, exclusive_scan, and inclusive_scan. SYCL implementations may use work-group and/or sub-group parallelism to produce finely tailored, cooperative versions of these functions since each algorithm is supported at various scopes.

Atomic references

Atomics improved in C++20 with the ability to encapsulate types in atomic references (std::atomic_ref). This design (sycl::atomic_ref) is extended to enable address spaces and memory scopes in SYCL 2020, creating an atomic reference implementation ready for heterogeneous computing.

SYCL follows ISO C++, and memory scopes were necessary for portable programming without losing speed. Don’t disregard heterogeneous systems’ complicated memory topologies.

Memory models and atomics are complicated, hence SYCL does not need all devices to use the entire C++ memory model to support as many devices as feasible. SYCL offers a wide range of device capabilities, another example of being accessible to all vendors.

Beyond SYCL 2020: Vendor Extensions

SYCL 2020’s capability for multiple backends and hardware has spurred vendor extensions. These extensions allow innovation that provides practical solutions for devices that require it and guides future SYCL standards. Extensions are crucial to standardization, and the DPC++ compiler project’s extensions inspired various elements in this article.

Two new DPC++ compiler features are SYCL 2020 vendor extensions.

Group-local Memory at Kernel Scope

Local accessors in SYCL 1.2.1 allow for group-local memory, which must be specified outside of the kernel and sent as a kernel parameter. This might seem weird for programmers from OpenCL or CUDA, thus has created an extension to specify group-local memory in a kernel function. This improvement makes kernels more self-contained and informs compiler optimizations (where local memory is known at compile-time).

FPGA-Specific Extensions

The DPC++ compiler project supports Intel FPGAs. It seems that the modifications, or something similar, can work with any FPGA suppliers. FPGAs are a significant accelerator sector, and nous believe it pioneering work will shape future SYCL standards along with other vendor extension initiatives.

Have introduced FPGA choices to make buying FPGA hardware or emulation devices easier. The latter allows quick prototyping, which FPGA software writers must consider. FPGA LSU controls allow us to tune load/store operations and request a specific global memory access configuration. Also implemented data placement controls for external memory banks (e.g., DDR channel) to tune FPGA designs via FPGA memory channel. FPGA registers allow major tuning controls for FPGA high-performance pipelining.

Summary

Heterogeneity endures. Many new hardware alternatives focus on performance and performance-per-watt. This trend will need open, multivendor, multiarchitecture programming paradigms like SYCL.

The five new SYCL 2020 features assist provide portability and performance mobility. C++ programmers may maximize heterogeneous computing with SYCL 2020.

Read more on Govindhtech.com

[countermmorg]

Visual studio 2014 download free. full version 64 bit

Visual studio 2014 freeload full version 64 bit software#

Visual studio 2014 freeload full version 64 bit code#

Third party wrappers are also available for Python, Perl, Fortran, Java, Ruby, Lua, Common Lisp, Haskell, R, MATLAB, IDL, Julia, and native support in Mathematica. In addition to libraries, compiler directives, CUDA C/C++ and CUDA Fortran, the CUDA platform supports other computational interfaces, including the Khronos Group's OpenCL, Microsoft's DirectCompute, OpenGL Compute Shader and C++ AMP. Fortran programmers can use 'CUDA Fortran', compiled with the PGI CUDA Fortran compiler from The Portland Group. C/C++ programmers can use 'CUDA C/C++', compiled to PTX with nvcc, Nvidia's LLVM-based C/C++ compiler.

Visual studio 2014 freeload full version 64 bit software#

The CUDA platform is accessible to software developers through CUDA-accelerated libraries, compiler directives such as OpenACC, and extensions to industry-standard programming languages including C, C++ and Fortran. Copy the resulting data from GPU memory to main memory.GPU's CUDA cores execute the kernel in parallel.Copy data from main memory to GPU memory.When it was first introduced, the name was an acronym for Compute Unified Device Architecture, but Nvidia later dropped the common use of the acronym.

Visual studio 2014 freeload full version 64 bit code#

CUDA-powered GPUs also support programming frameworks such as OpenMP, OpenACC and OpenCL and HIP by compiling such code to CUDA.ĬUDA was created by Nvidia. This accessibility makes it easier for specialists in parallel programming to use GPU resources, in contrast to prior APIs like Direct3D and OpenGL, which required advanced skills in graphics programming. ĬUDA is designed to work with programming languages such as C, C++, and Fortran. CUDA is a software layer that gives direct access to the GPU's virtual instruction set and parallel computational elements, for the execution of compute kernels. CUDA (or Compute Unified Device Architecture) is a parallel computing platform and application programming interface (API) that allows software to use certain types of graphics processing unit (GPU) for general purpose processing, an approach called general-purpose computing on GPUs ( GPGPU).

[longeducation]

Nvidia quadro m5000

NVIDIA QUADRO M5000 SOFTWARE

NVIDIA QUADRO M5000 CODE

Third party wrappers are also available for Python, Perl, Fortran, Java, Ruby, Lua, Common Lisp, Haskell, R, MATLAB, IDL, Julia, and native support in Mathematica. In addition to libraries, compiler directives, CUDA C/C++ and CUDA Fortran, the CUDA platform supports other computational interfaces, including the Khronos Group's OpenCL, Microsoft's DirectCompute, OpenGL Compute Shader and C++ AMP. Fortran programmers can use 'CUDA Fortran', compiled with the PGI CUDA Fortran compiler from The Portland Group. C/C++ programmers can use 'CUDA C/C++', compiled to PTX with nvcc, Nvidia's LLVM-based C/C++ compiler, or by clang itself.

NVIDIA QUADRO M5000 SOFTWARE

The CUDA platform is accessible to software developers through CUDA-accelerated libraries, compiler directives such as OpenACC, and extensions to industry-standard programming languages including C, C++ and Fortran.

Copy the resulting data from GPU memory to main memory.

GPU's CUDA cores execute the kernel in parallel.

Copy data from main memory to GPU memory.

When it was first introduced, the name was an acronym for Compute Unified Device Architecture, but Nvidia later dropped the common use of the acronym.

NVIDIA QUADRO M5000 CODE

CUDA-powered GPUs also support programming frameworks such as OpenMP, OpenACC and OpenCL and HIP by compiling such code to CUDA.ĬUDA was created by Nvidia. This accessibility makes it easier for specialists in parallel programming to use GPU resources, in contrast to prior APIs like Direct3D and OpenGL, which required advanced skills in graphics programming. ĬUDA is designed to work with programming languages such as C, C++, and Fortran. CUDA is a software layer that gives direct access to the GPU's virtual instruction set and parallel computational elements, for the execution of compute kernels. CUDA (or Compute Unified Device Architecture) is a parallel computing platform and application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for general purpose processing, an approach called general-purpose computing on GPUs ( GPGPU).

[swarnalata31techiio]

The comparison between Kotlin and Python

Kotlin:-

Kotlin is a general-purpose, free, open-source, statically typed “pragmatic” programming language initially designed for the JVM (Java Virtual Machine) and Android that combines object-oriented and functional programming features. It is focused on interoperability, safety, clarity, and tooling support. Versions of Kotlin targeting JavaScript ES5.1 and native code (using LLVM) for several processors are in production as well.

Python:-

Python is a widely-used, interpreted, object-oriented, and high-level programming language with dynamic semantics, used for general-purpose programming. It was created by Guido van Rossum, and first released on February 20, 1991.

Kotlin VS Python- Comparison

Kotlin:-

Statistically typed language providing OOPs and FP paradigm.

Unicode support is present.

Kotlin does not provide an Interpreter.

Kotlin provides Cross-Platform application support.

You can use HTML5 as the template language.

Kotlin is a compiled language hence a compiler is provided.

Kotlin Native used as a front end language.

Python:-

It is one of the most popular high-level programming languages.

Unicode Support is also present.

Python provides an Interpreter.

Python also provides cross-platform application support.

You can use Django, Chameleon as a template language.

Python does not provide a compiler as it is an interpreted language.

C# used for front end language.

Let’s discuss some important features of Python Programming Language:-

Easy Language

Python is an easy language. It is easy to read, write, learn and understand.

Python has a smooth learning curve. It is easy to learn.

Python has a simple syntax and Python code is easy to understand.

Readable

The Python language is designed to make developers' life easy. Reading a Python code is like reading an English sentence. This is one of the key reasons that make Python best for beginners.

Interpreted Language

Python is an interpreted language. It comes with the IDLE (Interactive Development Environment). This is an interpreter and follows the REPL structure (Read-Evaluate-Print-Loop). It executes and displays the output of one line at a time.

Let’s discuss some important features of Kotlin:-

Kotlin is Open-Source

The very first thing you should know about Kotlin is that it is an open-source programming language. But, apart from being open-source, Kotlin also provides a single-click tool using which, developers can convert existing Java code.

Kotlin Supports Full Java Interoperability

The lazy-loading feature increases the startup time, which is very useful when using it for Android development.

In simple words, it’s the best solution for all developers who want to reduce their Android app startup time so that their apps’ content can be shown faster.

Data Classes in Kotlin

The necessity of a class is always argued by programming language designers/makers. Typically, a data class in Java contains lots of boilerplate code which developers have to skip to find out the real use of that class.

Collection Filtering

We all know that when working with an API, web developers need to deal with collections quite often. But by using Kotlin’s collection filtering feature, it’s easier to tell what your resulting list should contain.

[this-week-in-rust]

This Week in Rust 479

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @ThisWeekInRust on Twitter or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community

Official

Officially announcing the types team

Diversifying our Content Delivery Networks

Foundation

Lars Bergstrom Elected as Rust Foundation Board of Directors Chair

Join the Rust Foundation at Rust Nation UK 2023

Newsletters

Project/Tooling Updates

rust-analyzer changelog #165

hyper-ish 2022 in review

Mobc 0.8.1 release with improved stability

Zenoh 0.7.0, a pure Rust Pub/Sub/Query protocol for cloud-to-thing continuum, was released and it is packed with new features.

Fornjot (code-first CAD in Rust) - Weekly Release

Slint 0.3.4 release

Astra: A Blocking HTTP Server Built on Top of Hyper

First steps with NGenate - A dataflow and visual programming platform built with rust

toml vs toml_edit

This Week in Fyrox #11

The year 2022 in Dimforge and our objectives for 2023

Observations/Thoughts

Rust in 2023: Growing up

The State of Developer Ecosystem 2022 in Rust: Discover recent trends

The size of Rust Futures

Capability-Safety I: Prelude

Surprises in the Rust JSON Ecosystem

The Git source code audit, viewed as a Rust programmer

Turning a Rust struct into an enum is not always a major breaking change

14 Rust Tools for Linux Terminal Dwellers

[audio] Rust Magazine with Shuang Zhu

[audio] Rust Nation with Ernest Kissiedu

Rust Walkthroughs

Temporary Values, Borrowing, and Lifetimes

Due to limitations in the borrow checker, this implies a 'static lifetime

Rust concepts I wish I learned earlier

Comparative fuzzing in Rust

domain-specific error macros

Building a Simple DB in Rust - Part 2 - Basic Execution

Rust FFI and cbindgen: Integrating Embedded Rust Code in C

Research

Miscellaneous

The crates.io registry is now a GitHub secret scanning integrator

Six fun things to do with Rust operator overloading

Packaging Rust Applications for the NPM Registry

Announcing Rust Support in CodeSandbox

[video] 10 Reasons Not To Use Rust (The Whole Truth)

[video] Sneaking By The Rust Borrow Checker - Interior Mutability

Crate of the Week

This week's crate is Darkbird, a mnesia-inspired high concurrency, real time, in-memory storage library.

Thanks to DanyalMh for the self-suggestion!

Please submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Ockam - Implement 'ockam node logs' CLI command

Ockam - Implement 'ockam worker list' CLI command

Ockam - Add a CI check to avoid conflicts in 'TypeTag' ids

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from the Rust Project

378 pull requests were merged in the last week

llvm-wrapper: adapt for LLVM API change

enable sanitizers for s390x-linux

put noundef on all scalars that don't allow uninit

add 'static lifetime suggestion when GAT implied 'static requirement from HRTB

add raw identifier for keyword in suggestion

check ADT fields for copy implementations considering regions

constify TypeId ordering impls

diagnostics: suggest changing s@self::{macro}@::macro for exported

dont randomly use _ to print out const generic arguments

drop tracking Visit break expressions

encode const mir for closures if they're const

fix check macro expansion

label closure captures/generator locals that make opaque types recursive

lazy dominator tree construction in borrowck

make CastError::NeedsDeref create a MachineApplicable suggestion

make error emitted on impl &Trait nicer

refactor basic blocks control flow caches

simplify derive(Debug) output for fieldless enums

suggest remove deref for type mismatch

suggestion for attempted integer identifier in patterns

tweak "borrow closure argument" suggestion

unify stable and unstable sort implementations in same core module

use UnordMap and UnordSet for id collections (DefIdMap, LocalDefIdMap, etc)

various cleanups around pre-TyCtxt queries and functions

add heapsort fallback in select_nth_unstable

implement alloc::vec::IsZero for Option<$NUM> types

lift T: Sized bounds from some strict_provenance pointer methods

add Arc::into_inner for safely discarding Arcs without calling the destructor on the inner type

hashbrown: provide default hasher types to Vacant and Occupied entries

futures: add Either::as_pin_mut and Either::as_pin_ref

futures: implement FusedStream for all streams in ReadyChunks

(cherry-pick) WebAssembly multivalue stackify fix

cargo: stabilize sparse-registry

cargo: wrapper type for data that should never be logged

rustfmt: correct span for structs with const generics

clippy: add multiple_unsafe_ops_per_block lint

clippy: add machine applicable suggestion for bool_assert_comparison

clippy: fix false positive in unnecessary_safety_comment

clippy: fix suggestion in transmutes_expressible_as_ptr_casts when the source type is a borrow

rust-analyzer: don't escape non-snippets in assist

rust-analyzer: don't respond with a ContentModified while loading the workspace

rust-analyzer: fix checkOnSave to check config patching not always working

rust-analyzer: fix markdown removal in hover handling whitespace weirdly

rust-analyzer: handle slice patterns in "Fill match arms"

rust-analyzer: more precise binop inference

rust-analyzer: substitute vscode variables in config.serverPath

rust-analyzer: parse const_closures syntax

rust-analyzer: replace SmolStr usage with lang item enum for lang items

rust-analyzer: use workspace.dependencies to declare local dependencies

Rust Compiler Performance Triage

Largely a win for compiler performance with 100 test cases in real-world crates showing some sort of change in performance with an average 1% improvement. These wins were a combination of many different changes including how doc(hidden) gets more efficiently encoded in metadata, some optimizations in the borrow checker, and simplification of the output from derive(Debug) for fieldless enums.

Triage done by @rylev. Revision range: 1f72129f..c8e6a9e8

Summary:

(instructions:u) mean range count Regressions ❌ (primary) 0.4% [0.2%, 0.7%] 19 Regressions ❌ (secondary) 0.9% [0.2%, 1.5%] 34 Improvements ✅ (primary) -1.3% [-17.2%, -0.2%] 81 Improvements ✅ (secondary) -2.1% [-7.1%, -0.2%] 64 All ❌✅ (primary) -1.0% [-17.2%, 0.7%] 100

2 Regressions, 5 Improvements, 3 Mixed; 1 of them in rollups 34 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs

No RFCs entered Final Comment Period this week.

Tracking Issues & PRs

[disposition: merge] Autotrait bounds on dyn-safe trait methods

[disposition: close] Stabilize ControlFlow::{BREAK, CONTINUE}

[disposition: merge] Add missing normalization for union fields types

[disposition: merge] rustdoc: change trait bound formatting

New and Updated RFCs

[new] Cargo target features

[new] Avoid non-local definitions in functions

Call for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. The following RFCs would benefit from user testing before moving forward:

No RFCs issued a call for testing this week.

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Upcoming Events

Rusty Events between 2023-01-25 - 2023-02-22 🦀

Virtual

2023-01-25 | Virtual (Redmond, WA, US; San Francisco, CA, US) | Microsoft Reactor Redmond | Microsoft Reactor San Francisco

Primeros pasos con Rust: QA y horas de comunidad | San Francisco Mirror

2023-01-26 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup

Rust Lightning Talks!

2023-01-26 | Virtual (Karlsruhe, DE) | The Karlsruhe Functional Programmers Meetup Group

Stammtisch (gemeinsam mit der C++ UG KA)

2023-01-26 | Virtual (Redmond, WA, US; San Francisco, CA, US; New York, NY, US; Stockholm, SE) | Microsoft Reactor Redmond and Microsoft Reactor New York and Microsoft Reactor San Francisco and Microsoft Reactor Stockholm

Crack code interview problems in Rust - Ep. 3 | New York Mirror | San Francisco Mirror | Stockholm Mirror

2023-01-27 | Virtual (Tunis, TN) | Rust Meetup Tunisia

Rust Meetup Tunisia - Volume I, Number I

2023-01-30 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Reactor New York and Microsoft Reactor San Francisco

Primeros pasos con Rust - Control de errores en Rust | New York Mirror | San Francisco Mirror

2023-01-31 | Virtual (Berlin, DE) | OpenTechSchool Berlin

Rust Hack and Learn

2023-01-31 | Virtual (Dallas, TX, US) | Dallas Rust

Last Tuesday

2023-01-31 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Reactor New York and Microsoft Reactor San Francisco

Primeros pasos con Rust - Compresión de cómo Rust administra la memoria | New York Mirror | San Francisco Mirror

2023-02-01 | Virtual (Cardiff, UK) | Rust and C++ Cardiff

New Year Virtual Social + Share

2023-02-01 | Virtual (Indianapolis, IN, US) | Indy Rust

Indy.rs - with Social Distancing

2023-02-01 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Reactor New York and Microsoft Reactor San Francisco

Primeros pasos con Rust: QA y horas de comunidad | New York Mirror | San Francisco Mirror

2023-02-01 | Virtual (Stuttgart, DE) | Rust Community Stuttgart

Rust-Meetup

2023-02-06 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Reactor New York and Microsoft Reactor San Francisco

Primeros pasos con Rust - Implementación de tipos y rasgos genéricos | New York Mirror | San Francisco Mirror

2023-02-07 | Virtual (Beijing, CN) | WebAssembly and Rust Meetup (Rustlang)

Monthly WasmEdge Community Meeting, a CNCF sandbox WebAssembly runtime

2023-02-07 | Virtual (Buffalo, NY, US) | Buffalo Rust Meetup

Buffalo Rust User Group, First Tuesdays

2023-02-07 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Reactor New York and Microsoft Reactor San Francisco

Primeros pasos con Rust - Módulos, paquetes y contenedores de terceros | New York Mirror | San Francisco Mirror

2023-02-08 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Rector New York and Microsoft Reactor San Francisco

Primeros pasos con Rust: QA y horas de comunidad | New York Mirror | San Francisco Mirror

2023-02-11 | Virtual | Rust GameDev

Rust GameDev Monthly Meetup

2023-02-13 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Rector New York and Microsoft Reactor San Francisco

Primeros pasos con Rust - Escritura de pruebas automatizadas | New York Mirror | San Francisco Mirror

2023-02-14 | Virtual (Berlin, DE) | OpenTechSchool Berlin

Rust Hack and Learn

2023-02-14 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US) | Microsoft Reactor Redmond and Microsoft Rector New York and Microsoft Reactor San Francisco

Primeros pasos con Rust - Creamos un programa de ToDos en la línea de comandos | San Francisco Mirror | New York Mirror

2023-02-14 | Virtual (Saarbrücken, DE) | Rust-Saar

Meetup: 26u16

2023-02-15 | Virtual (Redmond, WA, US; New York, NY, US; San Francisco, CA, US; São Paulo, BR) | Microsoft Reactor Redmond and Microsoft Rector New York and Microsoft Reactor San Francisco and Microsoft Reactor São Paulo

Primeros pasos con Rust: QA y horas de comunidad | San Francisco Mirror | New York Mirror | São Paulo Mirror

2023-02-15 | Virtual (Vancouver, BC, CA) | Vancouver Rust

Rust Study/Hack/Hang-out

Asia

2023-02-01 | Kyoto, JP | Kansai Rust

Rust talk: How to implement Iterator on tuples... kind of

Europe

2023-01-25 | Paris, FR | Rust Paris

Rust Paris meetup #55

2023-01-26 | Copenhagen, Dk | Copenhagen Rust Meetup Group

Rust Hack Night #32

2023-02-02 | Berlin, DE | Prenzlauer Berg Software Engineers

PBerg engineers - inaugural meetup; Lukas: Serverless APIs using Rust and Azure functions (Fee)

2023-02-02 | Hamburg, DE | Rust Meetup Hamburg

Rust Hack & Learn February 2023

2023-02-02 | Lyon, FR | Rust Lyon

Rust Lyon meetup #01

2023-02-04 | Brussels, BE | FOSDEM

FOSDEM 2023 Conference: Rust devroom

2023-02-21 | Zurich, CH | Rust Zurich

Practical Cryptography - February Meetup (Registration opens 7 Feb 2023)

North America

2023-01-26 | Lehi, UT, US | Utah Rust

Building a Rust Playground with WASM and Lane and Food!

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Rust has demonstrated that you using a type system as a vehicle for separation logic works, even in imperative languages, and it's nothing as arcane as those immutable functional predecessors would suggest. It did this by making sure the language defines a type system that helps you, by making sure core properties of soundness can be expressed in it.

soundness requirement for memory access: lifetimes

soundness requirements for references with value semantics: > &/&mut _

soundness requirements for resources: Copy and Drop

making sure your logic is monotic: traits instead of inheritance, lack of specialization (yes, that's a feature).

(notably missing: no dependent types; apparently not 'necessary' but I'm sure it could be useful; however, research is heavily ongoing; caution is good)

This allows the standard library to encode all of its relevant requirements as types. And doing this everywhere is its soundness property: safe functions have no requirements beyond the sum of its parameter type, unsafe functions can. Nothing new or special there, nothing that makes Rust's notion of soundness special.

Basing your mathematical reasoning on separation logic makes soundness reviews local instead of requiring whole program analysis. This is what makes it practical. It did this pretty successfully and principled, but did no single truly revolutionary thing. It's a sum of good bits from the last decade of type system research. That's probably why people refer to it as 'the soundness definition', it's just a very poignant way to say: "we learned that a practical type systems works as a proof checker".

– HeroicKatora on /r/cpp

Thanks to Stephan Sokolow for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin, bennyvasquez.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust