Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| From: | Jan Ziak <0xe2.0x9a.0x9b@gmail.com> |
| Newsgroups: | comp.compilers |
| Date: | Fri, 15 Jul 2022 10:50:21 -0700 (PDT) |
| Organization: | Compilers Central |
| References: | 22-07-011 22-07-015 22-07-020 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="67149"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | performance, comment |
| Posted-Date: | 15 Jul 2022 14:22:44 EDT |
| In-Reply-To: | 22-07-020 |
On Friday, July 15, 2022 at 6:09:05 PM UTC+2, John wrote:
> It's still hard to imagine that the size difference would matter in a
compiler.
> If you're logging a million values a second and saving it to an archive, well,
> that's different. -John
Size matters if the compiler is built around data caches as its core principle
(which means that not only the lexical phase is utilizing caches, but also
means that optimizations are being cached as well). Retrieving cached data
from a storage device (such as: DDR4 DRAM, NVMe SSD) is limited by current
hardware constraints to approximately 10 GB/s in mainstream PCs, while the
speed of computing a SHA-256 hash is limited to approximately 2 GB/s per CPU
core. It is easy to imagine sketches of a compiler based on such a core
principle - it is hard to create a complete "fully fledged" compiler based on
such a core principle.
Btw: Starting a sentence with "It's still hard to imagine that ..." pretty
much ensures that a counter-example will be sent in response.
-atom
[Surely you're aware that the best way to get an answer to a question on
the Internet is to post a wrong answer. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.