Re: [Iverilog-devel] More vec4-stack progress

[Martin W. <mai...@ma...>]

I've tracked down the construct that is causing the problem - it's a user 
function call in a continuous assignment statement. Looks like there's a 
memory leak there. The leak is present in the master branch as well. I've got 
a simple test case that exposes the problem, so I'll work on a fix. I'll wait 
until after the Big Merge before I push anything!

Stephen Williams wrote:
>
> OK, that's interesting. I theorize that what is going on here
> is that with the vec4-stack branch there are more vvp_vector4_t
> instances running around, and since they allocate some memory to
> hold the bit values there is a lot of allocation overhead.
> The way to address that may be to use a custom allocator within
> the vvp_vector4_t to allocate the bit space.
>
> Given that it is running faster then "master" even with the
> increased memory, I'm willing to accept the cost for now, and
> put it off until after the Big Merge.
>
> On 12/05/2014 12:38 PM, Martin Whitaker wrote:
>> Memory use is reported by 'vvp -v'. With the master branch, I get
>>
>> Compiling VVP ...
>>    ... VVP file version 0.10.0 (devel) (s20121218-480-g020e280-dirty)
>> Compile cleanup...
>>    ... Linking
>>    ... Removing symbol tables
>>    ... Compiletf functions
>>    ...     9343 functors (net_fun pool=786432 bytes)
>>                  2807 logic
>>                     0 bufif
>>                     0 resolv
>>                  2181 signals
>>    ...     8707 filters (net_fil pool=1310720 bytes)
>>    ...    44817 opcodes (1081344 bytes)
>>    ...     5474 nets
>>    ...     9343 vvp_nets (1048544 bytes)
>>    ...       12 arrays (129 words)
>>    ...      125 memories
>>                   125 logic (277608 words)
>>                     0 real (0 words)
>>    ...      407 scopes
>>    ... 0.167 seconds, 59244.0/17172.0/2052.0 KBytes size/rss/shared
>> Running ...
>>    ...execute EndOfCompile callbacks
>>    ...propagate initialization events
>>    ...execute StartOfSim callbacks
>>    ...run scheduler
>> Generating expected results
>> Running test
>>    ...execute Postsim callbacks
>>    ... 59.719 seconds, 261020.0/219492.0/2344.0 KBytes size/rss/shared
>> Event counts:
>>         130139 time steps (pool=128)
>>        2411954 thread schedule events
>>       23563521 assign events
>>                ...assign(vec4) pool=18724
>>                ...assign(vec8) pool=204
>>                ...assign(real) pool=256
>>                ...assign(word) pool=128
>>                ...assign(word/r) pool=204
>>        9721848 other events (pool=4096)
>>
>> With the vec4-stack branch, the only differences are:
>>
>>    ...    45991 opcodes (1105920 bytes)
>>
>>    ... 0.17 seconds, 60368.0/18228.0/2044.0 KBytes size/rss/shared
>>
>>    ... 55.939 seconds, 555040.0/513392.0/2356.0 KBytes size/rss/shared
>>
>>
>> Stephen Williams wrote:
>>>
>>> Those are pretty encouraging results.
>>>
>>> What are you looking at for the memory use?
>>>
>>> On 12/05/2014 12:06 PM, Martin Whitaker wrote:
>>>> Time taken for my long sequence of short tests:
>>>>
>>>>      master      22:48
>>>>      vec4-stack  18:28
>>>>
>>>> Time taken for my short sequence of longer tests:
>>>>
>>>>      master     (lossless)  12:12
>>>>      vec4-stack (lossless)   9:53
>>>>
>>>>      master     (strict)    11:49
>>>>      vec4-stack (strict)     9:35
>>>>
>>>> So performance looks good. Memory use is still a bit of a concern - for the
>>>> particular test I looked at, vvp reported
>>>>
>>>>      master      261,016 KB
>>>>      vec4-stack  554,984 KB
>>>>
>
>