<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Neural Architecture Codesign for Fast Physics Applications · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2501.05515/</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/2501.05515/feed.xml" rel="self" type="application/rss+xml" /><item><title>Neural Architecture Codesign for Fast Physics Applications — mentioned by chsun</title><link>https://news.ycombinator.com/item?id=47557556</link><guid isPermaLink="false">urn:hackerpapers:mention:2501.05515:47557556</guid><pubDate>Sat, 28 Mar 2026 19:35:51 GMT</pubDate><description>&lt;p&gt;Thank you for the comment, and the questions are great. The problems you described here are pretty much precise. In the past, and mostly now, we are replying on the commercial Vivado/Vitis HLS toolchains for the deployment of these networks through hls4ml, a template based compiler of the quantized models to the HLS projects. For this class of fully parallel (II=1) models, the tools usually give fine results, but indeed can be wrong sometimes (great recent example from our college&amp;#x27;s post: https://sioni.web.cern.ch/2026/03/24/debugging-fastml). Tool runtime is another issue. For the models…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2501.05515/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.LG</category></item></channel></rss>
