Programming

27005 readers
291 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS
76
77
78
79
 
 

I wrote a blog post about me getting in to FSharp web application development, but am having issues deciding how I want the data access to look. I'm very much open to feedback!

80
81
82
83
 
 

.

84
85
86
 
 

Crossposted from https://lemmy.ml/post/46897859

It is not my project.

I was looking for a lite version of Zed IDE without AI integrations, collab feature, telemetry etc and suddenly found it ^_^

I didn't test it excessively yet, but definitely give a try.

If you already tried it, please share your opinions.

87
88
89
 
 

cross-posted from: https://lemmy.ml/post/46884793

The Khronos OpenCL Working Group has released OpenCL 3.1, bringing widely deployed, field-proven capabilities into the core specification to expand functionality, including SPIR-V ingestion, that developers will be able to rely on across conformant implementations.

Features now mandated by OpenCL 3.1 have been deployed as extensions or optional capabilities. This is by design. The OpenCL working group evolves the specification by proving features in the field as extensions first, watching how they get used across multiple implementations, refining them based on developer feedback, and only then graduating them into the core specification.

Every conformant OpenCL 3.1 implementation will be required to consume SPIR-V kernels — a feature that has been one of the most requested by developers. OpenCL 3.1 additionally requires support for the SPIR-V query extension, which enables applications to enumerate the SPIR-V capabilities, extensions, and versions that a device supports, simplifying the adoption of new SPIR-V features as they become available.

Several features essential to HPC and AI kernels are also now mandatory in the core OpenCL 3.1 specification:

  • Subgroups, including shuffles, rotations, and an expanded set of supported data types. A fundamental building block for tuned reductions, scans, and matrix kernels.
  • Integer dot products, including saturating and accumulating variants, together with extended bit operations: Both map directly to dedicated hardware instructions on a wide range of modern silicon, and both are common building blocks for matrix multiplications and the low-precision arithmetic central to inference workloads.
  • A new query for the suggested local work-group size. This gives applications and profilers a runtime hint for the optimal work-group size for a given kernel and device, eliminating the need for manual tuning or repeated size calculations across multiple enqueues and improving performance predictability on diverse hardware.
  • A standard device UUID query, matching Vulkan’s VkPhysicalDeviceIDProperties::deviceUUID. This allows applications to correlate the same physical device across APIs, which is essential for multi-device systems and for external memory-sharing scenarios that span OpenCL and Vulkan.
90
 
 

The Cooley-Tukey fast Fourier transform can compute discrete Fourier transforms efficiently for signals of highly-composite length, such as powers of 2. However, to compute signal lengths with large prime factors, an algorithm such as Bluestein's is needed to prevent the algorithm from degenerating to quadratic complexity.

Thanks to Bluestein's algorithm, FFTs of prime-length input sequences are "only" ~4-6x slower than nearby powers of 2. The clunkiness of Bluestein's makes fast Fourier transforms interesting: the steps to complete the algorithm is not a monotonic function of the problem size, shooting up and down depending on the factors of the input length.

Interestingly, I found that almost no signal processing knowledge is required to understand and derive Bluestein's algorithm; anyone with general computing knowledge can follow along and should be able to implement Bluestein's algorithm after reading this post.

91
92
93
94
95
96
97
98
99
100
view more: ‹ prev next ›