View mode: basic / threaded / horizontal-split · Log in · Help
August 14, 2010
Re: dmd 1.063 and 2.048 release
On 08/11/2010 04:15 PM, Walter Bright wrote:
>
> This is probably the last FreeBSD 7 release for D1. The next will be for
> FreeBSD 8!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.063.zip
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.048.zip

Hi,

  Congratulations for this release! This time it really made a 
difference when i switched from 2.0.46. The framerate of my app used to 
degenerate with time very quickly and now it remains fast and stable!

  Maybe some of the many fixes helped the garbage collector?

  Congratulations again.

j.
August 15, 2010
Re: dmd 1.063 and 2.048 release
== Quote from Jordi (jordi@rovira.cat)'s article
> On 08/11/2010 04:15 PM, Walter Bright wrote:
> >
> > This is probably the last FreeBSD 7 release for D1. The next will be for
> > FreeBSD 8!
> >
> > http://www.digitalmars.com/d/1.0/changelog.html
> > http://ftp.digitalmars.com/dmd.1.063.zip
> >
> > http://www.digitalmars.com/d/2.0/changelog.html
> > http://ftp.digitalmars.com/dmd.2.048.zip
> Hi,
>    Congratulations for this release! This time it really made a
> difference when i switched from 2.0.46. The framerate of my app used to
> degenerate with time very quickly and now it remains fast and stable!
>    Maybe some of the many fixes helped the garbage collector?
>    Congratulations again.
> j.

Probably the GC.minimize() patch.  Previously the GC would **never** give memory
back to the OS.  In addition to the obvious reason, this is bad because the GC is
currently not well optimized and slows down a lot when the heap gets large, even
if most of it doesn't contain pointers and isn't scanned.
August 15, 2010
Re: dmd 1.063 and 2.048 release
On 08/15/2010 01:50 PM, dsimcha wrote:
> == Quote from Jordi (jordi@rovira.cat)'s article
>> On 08/11/2010 04:15 PM, Walter Bright wrote:
>>>
>>> This is probably the last FreeBSD 7 release for D1. The next will be for
>>> FreeBSD 8!
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.063.zip
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.048.zip
>> Hi,
>>     Congratulations for this release! This time it really made a
>> difference when i switched from 2.0.46. The framerate of my app used to
>> degenerate with time very quickly and now it remains fast and stable!
>>     Maybe some of the many fixes helped the garbage collector?
>>     Congratulations again.
>> j.
>
> Probably the GC.minimize() patch.  Previously the GC would **never** give memory
> back to the OS.  In addition to the obvious reason, this is bad because the GC is
> currently not well optimized and slows down a lot when the heap gets large, even
> if most of it doesn't contain pointers and isn't scanned.

Great. I always thought i was missing some important point about garbage 
collection, and i was doing everything wrong. I am used to manage my own 
memory in C++...

Anyway, i had to roll back to 2.0.46 as i have seen that from 2.0.47 
some behaviour has changed in my program. I cannot really make a small 
reproduction case, because it involves dragging objects around the 3d 
scene: since 2.0.47 they follow weird curved paths instead of moving 
correctly on the camera plane.

The code that calculate that (which is not new) just uses matrix and 
vector operations to project and unproject positions, but i cannot 
really find where do the numbers start to go wrong.

j.
August 15, 2010
Re: dmd 1.063 and 2.048 release
"Jordi" <jordi@rovira.cat> wrote in message 
news:i48n8t$1jv$1@digitalmars.com...
> On 08/15/2010 01:50 PM, dsimcha wrote:
>> == Quote from Jordi (jordi@rovira.cat)'s article
>>> On 08/11/2010 04:15 PM, Walter Bright wrote:
>>>>
>>>> This is probably the last FreeBSD 7 release for D1. The next will be 
>>>> for
>>>> FreeBSD 8!
>>>>
>>>> http://www.digitalmars.com/d/1.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.1.063.zip
>>>>
>>>> http://www.digitalmars.com/d/2.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.2.048.zip
>>> Hi,
>>>     Congratulations for this release! This time it really made a
>>> difference when i switched from 2.0.46. The framerate of my app used to
>>> degenerate with time very quickly and now it remains fast and stable!
>>>     Maybe some of the many fixes helped the garbage collector?
>>>     Congratulations again.
>>> j.
>>
>> Probably the GC.minimize() patch.  Previously the GC would **never** give 
>> memory
>> back to the OS.  In addition to the obvious reason, this is bad because 
>> the GC is
>> currently not well optimized and slows down a lot when the heap gets 
>> large, even
>> if most of it doesn't contain pointers and isn't scanned.
>
> Great. I always thought i was missing some important point about garbage 
> collection, and i was doing everything wrong. I am used to manage my own 
> memory in C++...
>
> Anyway, i had to roll back to 2.0.46 as i have seen that from 2.0.47 some 
> behaviour has changed in my program. I cannot really make a small 
> reproduction case, because it involves dragging objects around the 3d 
> scene: since 2.0.47 they follow weird curved paths instead of moving 
> correctly on the camera plane.
>
> The code that calculate that (which is not new) just uses matrix and 
> vector operations to project and unproject positions, but i cannot really 
> find where do the numbers start to go wrong.
>

This may be a pain to do, but you could narrow it down from the other 
direction: recompile DMD from varius trunk revisions between 2.046 and 2.047 
and see which actual commit created the problem.
August 15, 2010
Re: dmd 1.063 and 2.048 release
Nick Sabalausky wrote:
> This may be a pain to do, but you could narrow it down from the other 
> direction: recompile DMD from varius trunk revisions between 2.046 and 2.047 
> and see which actual commit created the problem.

Try mixing/matching the compiler & Phobos to see which one of those caused the 
issue.
August 15, 2010
Re: dmd 1.063 and 2.048 release
On 8/15/2010 12:54 PM, Walter Bright wrote:
> Nick Sabalausky wrote:
>> This may be a pain to do, but you could narrow it down from the other
>> direction: recompile DMD from various trunk revisions between 2.046 and 2.047
>> and see which actual commit created the problem.
> 
> Try mixing/matching the compiler & Phobos to see which one of those caused the
> issue.

While I agree that it's worth trying a bisection -- it's generally really quick
and easy to do (the compiler and libraries build rather fast -- about a minute
for me).  It can be a very useful technique for finding where bugs were introduced.

That said, it's likely to be rather difficult for this release due to the number
of fixes in the compiler that the library requires and for the periods during
which the two didn't work together.

Do try it.. worst case is you've wasted a little bit of time.  Best case you've
found the cause of the bug.

Later,
Brad
August 16, 2010
Re: dmd 1.063 and 2.048 release
Brad Roberts wrote:
> On 8/15/2010 12:54 PM, Walter Bright wrote:
>> Nick Sabalausky wrote:
>>> This may be a pain to do, but you could narrow it down from the other
>>> direction: recompile DMD from various trunk revisions between 2.046 and 2.047
>>> and see which actual commit created the problem.
>> Try mixing/matching the compiler & Phobos to see which one of those caused the
>> issue.
> 
> While I agree that it's worth trying a bisection -- it's generally really quick
> and easy to do (the compiler and libraries build rather fast -- about a minute
> for me).  It can be a very useful technique for finding where bugs were introduced.
> 
> That said, it's likely to be rather difficult for this release due to the number
> of fixes in the compiler that the library requires and for the periods during
> which the two didn't work together.
> 
> Do try it.. worst case is you've wasted a little bit of time.  Best case you've
> found the cause of the bug.
> 
> Later,
> Brad

The latest compiler should work with the old Phobos, except that it will 
complain about the a&b==c bugs. That's simple to do, it just involves 
copying the 2.048 compiler onto the 2.047 release. Knowing if it is the 
compiler or Phobos/druntime would be an enormous help.
August 16, 2010
Re: dmd 1.063 and 2.048 release
On 08/16/2010 04:11 PM, Don wrote:
> Brad Roberts wrote:
>> On 8/15/2010 12:54 PM, Walter Bright wrote:
>>> Nick Sabalausky wrote:
>>>> This may be a pain to do, but you could narrow it down from the other
>>>> direction: recompile DMD from various trunk revisions between 2.046
>>>> and 2.047
>>>> and see which actual commit created the problem.
>>> Try mixing/matching the compiler & Phobos to see which one of those
>>> caused the
>>> issue.
>>
>> While I agree that it's worth trying a bisection -- it's generally
>> really quick
>> and easy to do (the compiler and libraries build rather fast -- about
>> a minute
>> for me). It can be a very useful technique for finding where bugs were
>> introduced.
>>
>> That said, it's likely to be rather difficult for this release due to
>> the number
>> of fixes in the compiler that the library requires and for the periods
>> during
>> which the two didn't work together.
>>
>> Do try it.. worst case is you've wasted a little bit of time. Best
>> case you've
>> found the cause of the bug.
>>
>> Later,
>> Brad
>
> The latest compiler should work with the old Phobos, except that it will
> complain about the a&b==c bugs. That's simple to do, it just involves
> copying the 2.048 compiler onto the 2.047 release. Knowing if it is the
> compiler or Phobos/druntime would be an enormous help.

Found it. It took me 7 iterations of binary search across the svn 
repositories for dmd, druntime and phobos. The commit causing the issue 
is 505 in dmd. It is related to structs returning *this, which indeed i 
do in my maths structs.

Now, i don't know if the bug is in dmd or in my code, but i suspect that 
something is being treated as a reference when it shouldn't. Should i 
add an issue even if i am not sure?

j.
August 16, 2010
Re: dmd 1.063 and 2.048 release
Michal Minich wrote:
> On Wed, 11 Aug 2010 17:34:20 -0400, Sean Kelly wrote:
> 
>> Michal Minich Wrote:
>>
>>> On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:
>>>
>>>> Module constructor is not called when it is placed in imported
>>>> module, and WinMain is used.
>>> Are there some changes to runtime initialization, or it is a bug? (in
>>> that case I will submit it).
>> There were some changes and I must have missed updating rt_init(). 
>> Please submit a bug.  What you'll likely see is shared static ctors
>> being called but not thread-specific (ie. non-shared) static ctors
>> called for the main thread.
> 
> bug report:
> http://d.puremagic.com/issues/show_bug.cgi?id=4622

Fixed:

http://www.dsource.org/projects/druntime/changeset/368
August 16, 2010
Re: dmd 1.063 and 2.048 release
Jordi wrote:
> Found it. It took me 7 iterations of binary search across the svn 
> repositories for dmd, druntime and phobos. The commit causing the issue 
> is 505 in dmd. It is related to structs returning *this, which indeed i 
> do in my maths structs.
> 
> Now, i don't know if the bug is in dmd or in my code, but i suspect that 
> something is being treated as a reference when it shouldn't. Should i 
> add an issue even if i am not sure?

Try to reduce it to the smallest possible reproducible test case, and then post 
it to bugzilla.
1 2 3 4 5
Top | Discussion index | About this forum | D home