Am 28.08.2012 01:53, schrieb Sean Kelly:
> On Aug 24, 2012, at 1:16 PM, David <d@dav1d.de> wrote:
>>
>> That's not the problem. The problem has nothing to do with the tessellation, since the *rendering* is also 1000% slower (when all data is already processed).
>
> Is the alignment different between one and the other? I would't think so since it's dynamic memory, but the performance difference suggests that it might be.
>

The arrays are 100% identical (I dumped a Vertex()-array and a raw float-array, they were 100% identical).

David:

> The arrays are 100% identical (I dumped a Vertex()-array and a raw float-array, they were 100% identical).

I hope some people are realizing how much time is being wasted in this thread. Taking a look at the asm is my suggestion still. If someone is rusty in asm, it's time to brush away the rust with a steel brush.

Bye,
bearophile

Am 28.08.2012 17:41, schrieb bearophile:
> David:
>
>> The arrays are 100% identical (I dumped a Vertex()-array and a raw
>> float-array, they were 100% identical).
>
> I hope some people are realizing how much time is being wasted in this
> thread. Taking a look at the asm is my suggestion still. If someone is
> rusty in asm, it's time to brush away the rust with a steel brush.
>
> Bye,
> bearophile

You're right, but I also said, that I don't care anylonger, I found a workaround, I can live with it. I generally tend to ignore dmd bugs and just workaround them, I don't have the time to track down every stuipid bug from a ~8k codebase.

Thanks anyways for your help.

David:

> I generally tend to ignore dmd bugs and just workaround them, I don't have the time to track down every stuipid bug from a ~8k codebase.

I understand you don't care much anymore for the discussed problem, and I know that localizing D/DMD bugs requires some time and work.

But I'd like you to not ignore all the bugs you find, and instead minimize some of them and submit them to Bugzilla. Despite thousands of open bugs and about a hundred of open patches, many bugs do get fixed at every release. If you submit bugs, D/DMD will improve, in your future you will find less bugs to work around in your D code, and you will help other present and future D programmers avoid hitting them. This is important because D is young and its community is small. The idea is: they give you a compiler/language for free, and you give something back to the community submitting some bugs :-)

Bye and thank you,
bearophile

> But I'd like you to not ignore all the bugs you find, and instead
> minimize some of them and submit them to Bugzilla. Despite thousands of
> open bugs and about a hundred of open patches, many bugs do get fixed at
> every release. If you submit bugs, D/DMD will improve, in your future
> you will find less bugs to work around in your D code, and you will help
> other present and future D programmers avoid hitting them. This is
> important because D is young and its community is small. The idea is:
> they give you a compiler/language for free, and you give something back
> to the community submitting some bugs :-)

I totally agree

> I understand you don't care much anymore for the discussed problem, and
> I know that localizing D/DMD bugs requires some time and work.

And that's the problem, I tried to track down a few of the bugs I hit. 50% vanished when I changed unrelated code (cool hugh? getting a segfault in std.net.curl → std.regex → std.functional.memoize, when chaning your ResourceManager, which has really nothing to do with either curl, regex or std.functional nor the module which calls std.net.curl), then I wasn't able to reproduce a few others, in the end, I think, I was able to track down a single dmd bug. That was with a relativly small code-base (maybe 1-2k?) now I have around 8k and I just don't have the time and maybe the knowledge. At least I can fix phobos/druntime bugs.

Not sure why I wrote that, I don't wanna whiny, D is great/buggy and I knew it, when I started that project. And I am glad there are people like you, Kenji and lots of others who keep on improving D in their free time (not to forget Walter and Andrei).

On 08/28/2012 06:35 PM, David wrote:
> Am 28.08.2012 17:41, schrieb bearophile:
>> David:
>>
>>> The arrays are 100% identical (I dumped a Vertex()-array and a raw
>>> float-array, they were 100% identical).
>>
>> I hope some people are realizing how much time is being wasted in this
>> thread. Taking a look at the asm is my suggestion still. If someone is
>> rusty in asm, it's time to brush away the rust with a steel brush.
>>
>> Bye,
>> bearophile
>
> You're right, but I also said, that I don't care anylonger, I found a
> workaround, I can live with it. I generally tend to ignore dmd bugs and
> just workaround them, I don't have the time to track down every stuipid
> bug from a ~8k codebase.
>
> Thanks anyways for your help.

Use this to create a minimal test case with minimal user interaction:
https://github.com/CyberShadow/DustMite

> Use this to create a minimal test case with minimal user interaction:
> https://github.com/CyberShadow/DustMite

Doesn't help if dmd doesn't crash, or?

On 08/29/2012 01:26 AM, David wrote:
>> Use this to create a minimal test case with minimal user interaction:
>> https://github.com/CyberShadow/DustMite
>
> Doesn't help if dmd doesn't crash, or?
>

It doesn't help a lot if compilation succeeds, but you stated that you
generally tend to ignore dmd bugs. Most dmd bugs make compilation fail.

On Wed, 29 Aug 2012, Timon Gehr wrote:

> On 08/29/2012 01:26 AM, David wrote:
> > > Use this to create a minimal test case with minimal user interaction: https://github.com/CyberShadow/DustMite
> > 
> > Doesn't help if dmd doesn't crash, or?
> > 
> 
> It doesn't help a lot if compilation succeeds, but you stated that you generally tend to ignore dmd bugs. Most dmd bugs make compilation fail.

It's more generally useful than that.  It can reduce for any set of commands that together produce a binary decision: pass or fail.  The key problem is that it does need to be deterministic.  It doesn't matter if it's dmd that fails, or an execution of the output code, or really anything that determines pass or fail.  The basic pattern is:

while (progress can be made)
   try a reduction

   if reduction still reproduces the error
      continue
   else
      revert
done

(it's obviously more complex and there's tons of magic inside try a reduction)