<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>To prune, or not to prune: exploring the efficacy of pruning for model compression · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1710.01878/</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/1710.01878/feed.xml" rel="self" type="application/rss+xml" /><item><title>To prune, or not to prune: exploring the efficacy of pruning for model compression — mentioned by ekelsen</title><link>https://news.ycombinator.com/item?id=22512153</link><guid isPermaLink="false">urn:hackerpapers:mention:1710.01878:22512153</guid><pubDate>Sat, 07 Mar 2020 15:55:04 GMT</pubDate><description>&lt;p&gt;The implications are unclear to me. We already know how to prune models for inference. For example https://arxiv.org/abs/1710.01878, along with earlier work (and more recent work). There&amp;#x27;s also work showing that you can take advantage of the sparsity to achieve practical speed gains: https://arxiv.org/abs/1911.09723. We can also train networks that are sparse from the beginning of training (without requiring any special knowledge of the solution): https://arxiv.org/abs/1911.11134. It remains to be shown that this can be done with a speed advantage.&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1710.01878/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>stat.ML</category></item></channel></rss>
