Comments (3)
I confirmed that this is still a problem with the recently released GHC 9.8.2. And I also see that it's an issue with 9.6 (both 9.6.2 and 9.6.4 the latest) -- I would guess that we just jumped to 9.8.1 and hadn't run the testsuite with 9.6. I opened an issue with GHC for it (issue 24487). If I use +RTS -s
to dump statistics, I don't observe much of a difference between 9.4.8 and 9.8.2, nor is the runtime much different, so I'm actually not sure if this is a behavior difference in BSC and maybe it really is more directly GHC's doing. (That could maybe be confirmed by dumping a trace from BSC of its evaluation steps, and confirming whether BSC is doing the same evaluation in both cases.)
from bsc.
It appears that GHC 9.4 and 9.8 are using the amounts of memory, it's just that GHC 9.4 was not properly handling the RTS -M
flag. (As indicated on the GHC issue, there was a fix to the accounting of heap space that was introduced in 9.6). On the GHC issue, the are graphs generated by using the RTS -S
flag to generate trace of heap usage and actual live bytes (which may be less than the heap size due to minimum allocatable block sizes and fragmentation) etc. Those graphs are essentially the same for 9.4 and 9.8.
So GHC 9.8 is doing the right thing and the two failing tests just need a little more heap space to compile. (This is in contract to the VsortOriginal
example that exhausts a 400M heap, and when I gave it 500M it churned for longer than I was willing to wait.) So I've submitted PR #681 to remove the check of the GHC version and just slightly increase the heap given to the two newly failing tests.
I wonder if these tests need to be restructured, to somehow directly measure what is actually being tested. I don't immediately understand what the tests are testing, or I would propose something. The tests appear to have for-loops which BSC's evaluator unrolls, and if BSC is not careful in how it optimizes (and prunes branching paths), then the unrolling could expand uncontrollably. If these a testing BSC's ability to keep the unrolling out of control (by proper optimizations in ITransform), then maybe a direct way to measure that is by looking at a trace from the evaluator. I guess that heap size was deemed to be a good enough proxy for the size of the unrolling. And maybe that's OK, since the one "expected fail" uses significantly more heap. Although we might consider having GHC report the actual live bytes, as a better measure. (Interestingly, for Bug1490MyUnion.bsv
that seemed to be only 10M out of 256M!?) We could keep this GitHub issue open for that, but I'm coming around to thinking that the heap is a good enough proxy and that it may not be worth our time to keep looking at it. So I'm going to close it, but feel free to comment.
from bsc.
BSC is compiled with -with-rtsopts=-H256m -K10m -i1
which means that a minimum heap size of 256M is being set. It seems that GHC is ignoring the max heap -M
value if the minimum is larger. So any -M
value less than 256M has no effect, which is why BSC compiled with GHC 9.4 doesn't have a heap overflow with lower values. And the change in how the current heap size is calculated (starting in GHC 4.6) explains why the example started failing (because the old accounting was less than 256M while the new accounting is greater).
from bsc.
Related Issues (20)
- Bluesim leaves junk in loaded registers if the full range of hex digits isn't specified HOT 3
- uppercase names not allowed in interface property `arg_names` HOT 4
- bsc ignores `always_ready` when checking for duplicate wires
- module verilog does not allow sharing ports among conflicting methods
- `-dparsed` output produces invalid register updates with BSV HOT 2
- `-dparsed` produces invalid BSV module function that takes another module as an argument HOT 2
- Missing `Ord Bool` instance HOT 7
- Static check of file descriptor argument to tasks like $fgetc HOT 3
- Testsuite reports an error getting BSC version HOT 2
- Internal Compiler Error when quoting a character value. HOT 4
- Bluesim's symbol-probing interface has wrong values for FIFO
- Unresolved numeric contexts that should be resolvable HOT 6
- Verilog import fails in macro substitution HOT 2
- Unexpected syntax error HOT 1
- expandPorts.tcl has hardcoded paths which do not exist. HOT 1
- Unexpected behavior in Stmt sequence when using par HOT 2
- Bluesim divide-by-zero behavior is inconsistent on arm64 HOT 2
- Type synonyms with phantom parameters can lead to strange behaviors (E.g., compiler hang) HOT 4
- doc example for mkUniqueWrapper2 HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bsc.