<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>High-Performance GPU-to-CPU Transpilation and Optimization via High-Level Parallel Constructs · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2207.00257/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2207.00257/feed.xml" rel="self" type="application/rss+xml" /><item><title>High-Performance GPU-to-CPU Transpilation and Optimization via High-Level Parallel Constructs — mentioned by vimarsh6739</title><link>https://news.ycombinator.com/item?id=42744915</link><guid isPermaLink="false">urn:hackerpapers:mention:2207.00257:42744915</guid><pubDate>Sat, 18 Jan 2025 01:19:11 GMT</pubDate><description>&lt;p&gt;One of the more subtle aspects of retargeting GPU code to run on the CPU is the presence of fine grained(read - block level and warp level) explicit synchronization mechanisms being available in the GPU. However, this is not the same in CPU land, so additional care has to be taken to handle this. One example of work which tries this is https://arxiv.org/pdf/2207.00257 . Interestingly, in the same work, contrary to what you’d expect, transpiling GPU code to run on CPU gives ~76% speedups in HPC workloads compared to a hand optimized multi-core CPU implementation on Fugaku(a CPU only…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2207.00257/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.PL</category></item></channel></rss>
