August 27, 2019
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote:
> On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:
>> The Symmetry Autumn of Code 2019 application selection process has come to an end. This year, we've got five projects instead of three. Congratulations to everyone who was selected! You can read about them and their projects over at the D Blog:
>>
>> https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/
>
> Sorry, I haven't been following. Don't we already have an implementation of the "Create a CI or other infrastructure for measuring D’s progress and performance" project? I just haven't been maintaining it because there hasn't been a lot of interest in it while it was being maintained.

Max, if you're still excited about this project, please ping me on IRC or Slack. Would love to brainstorm with you and hear your ideas.

August 27, 2019
On Tuesday, 27 August 2019 at 12:58:20 UTC, Vladimir Panteleev wrote:

> It will eventually zero in to commit-level accuracy after it's been running for a while. I cleared the database as the last time it was running, it was on another CPU, so the timings are going to be different. (Still need to decide on a way to measure execution time in some deterministic way.)

If you look at the vibe.d compile-time graph, you'll see there's a 2.5s increase around Mid-2014.  When I zoom in and visit the commit, it's just a DDoc comment change (https://github.com/dlang/phobos/pull/3542).  I don't see how that could account for the large increase in compile time.

Mike
August 27, 2019
On Tuesday, 27 August 2019 at 14:42:28 UTC, Vladimir Panteleev wrote:
> On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote:
>> On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:
>>> The Symmetry Autumn of Code 2019 application selection process has come to an end. This year, we've got five projects instead of three. Congratulations to everyone who was selected! You can read about them and their projects over at the D Blog:
>>>
>>> https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/
>>
>> Sorry, I haven't been following. Don't we already have an implementation of the "Create a CI or other infrastructure for measuring D’s progress and performance" project? I just haven't been maintaining it because there hasn't been a lot of interest in it while it was being maintained.
>
> Max, if you're still excited about this project, please ping me on IRC or Slack. Would love to brainstorm with you and hear your ideas.

Vladimir, I would love to (and I need to acquire a mentor, so if you're not busy... ;) ) but I am struggling to even load the forum (I'm on holiday) but I'll be back to civilisation within a day or two.


To anyone else reading: If the gods allow it, I'm *trying* to answer questions about my proposal but my internet connection is genuinely shit ATM

August 27, 2019
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote:
> On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:
>> The Symmetry Autumn of Code 2019 application selection process has come to an end. This year, we've got five projects instead of three. Congratulations to everyone who was selected! You can read about them and their projects over at the D Blog:
>>
>> https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/
>
> Sorry, I haven't been following. Don't we already have an implementation of the "Create a CI or other infrastructure for measuring D’s progress and performance" project? I just haven't been maintaining it because there hasn't been a lot of interest in it while it was being maintained.
>
> Here's the original blog post:
>
> https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/
>
> I'll give it a kick and get it back online if there is interest. Seems wasteful to reimplement it from scratch, though.

I was aware of the site when i wrote the proposal, but the idea is to create the infrastructure to add more measurements too, e.g. profiling the compiler or testing it under limited memory (I found out how much memory my CTFE thing was using the other day!). Assuming I can get it to work I'd also like to throw the Linux perf system in there too, but

As mentioned in the summary, this will extend to runtime performance too but that obviously raises the question of how to ensure consistent performance of the testing machine (or give a relative figure).
August 28, 2019
On Tuesday, 27 August 2019 at 17:11:33 UTC, Mike Franklin wrote:

> If you look at the vibe.d compile-time graph, you'll see there's a 2.5s increase around Mid-2014.

Sorry, that should be Mid-2015.


August 28, 2019
On Monday, 26 August 2019 at 11:03:51 UTC, Jacob Carlborg wrote:
> On 2019-08-26 05:55, Andrej Mitrovic wrote:
>
>> I'm guessing this means we might even be able to use multiple versions of Phobos one day. However before we do that, we will really need to fix the use of globals in Phobos.
>
> I don't think that's necessary. All symbols will have the version be part of the mangled name.

Hm... this approach has a few scenarios where I imagine that it fails in weird ways:

- resources that can be initialized only once that are encapsulated in a library: e.g. two versions of a logging library that write to the same file and recreate the file during initialization. On Windows, opening the same file for writing again might fail. On Linux, it would replace the existing inode entry for the file while both library instances continue to happily write to their instance of the file.

- violating implicit expectations about relationships between dependencies; for example, consider two libraries libFoo and libBar working on data structures defined in a libCore. An application uses all three of them and passes pointers to libCore data structures to functions in libFoo and libBar. Recently, libFoo and libCore have been updated and the libCore data structures changed. The libBar update is not done yet. So if libBar is built with its own private copy of the old libCore, expectations about structure memory layouts are out of whack. If something like that compiles and links, it's likely going to be nearly impossible to debug.

The thing is that the resulting failure cases are likely surprising, not obvious and therefore hard to debug. If you want to do this, it should be optional and require explicit opt-in from all dependencies in a chain. Libraries have to be designed in very specific ways to make this work and these restrictions would be new to the D ecosystem.
August 30, 2019
On Tuesday, 27 August 2019 at 17:11:33 UTC, Mike Franklin wrote:
> On Tuesday, 27 August 2019 at 12:58:20 UTC, Vladimir Panteleev wrote:
>
>> It will eventually zero in to commit-level accuracy after it's been running for a while. I cleared the database as the last time it was running, it was on another CPU, so the timings are going to be different. (Still need to decide on a way to measure execution time in some deterministic way.)
>
> If you look at the vibe.d compile-time graph, you'll see there's a 2.5s increase around Mid-2014.  When I zoom in and visit the commit, it's just a DDoc comment change (https://github.com/dlang/phobos/pull/3542).  I don't see how that could account for the large increase in compile time.

The JS part of the project was adopted from somewhere else (Mozilla's project for tracking Firefox performance), so it was a bit hammered-on to the data schema we use here. Mozilla never builds individual successive commits; you have to do it yourself to zero in on a specific change. Because of this, the UI was confusing and it wasn't obvious whether a commit is actually the cause of a change in the metrics.

I've now changed it to only draw a line between two points if they're adjacent in the git history. Still not perfect but better. You can see this now by zooming into the big change in e.g. "Empty program - compilation - peak heap size". (The vibe.d one isn't resolved yet, give it a few days.)

The problem with representing this data is that we have the whole commit list, which is nice and linear, but not all commits are tested, and we can't graph untested commits because they effectively don't have an Y value. There's also way too many commits to draw at once, so it groups commits that occurred near the same time together in one node, which again causes complications when it's a mix of tested and untested commits. (Currently it uses the median of the test results for tested commits.)

More changes:
https://github.com/CyberShadow/TrenD/commits/master
September 04, 2019
On Monday, 26 August 2019 at 03:55:43 UTC, Andrej Mitrovic wrote:
> On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:
>> ...
>> Solve Dependency Hell:
>> This is considered as a crucial first step in making Phobos available via the DUB registry
>
> I'm guessing this means we might even be able to use multiple versions of Phobos one day. However before we do that, we will really need to fix the use of globals in Phobos.

Honestly, I'm a bit leery about this use-multiple-versions approach. It feels like it carries some serious risks of code bloat, which may be accentuated by the fact that DUB has some serious dependency resolution bugs even with single version dependencies... :-\
September 04, 2019
On Tuesday, 27 August 2019 at 17:32:30 UTC, Max Haughton wrote:
> On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote:
>> On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:
>>> The Symmetry Autumn of Code 2019 application selection process has come to an end. This year, we've got five projects instead of three. Congratulations to everyone who was selected! You can read about them and their projects over at the D Blog:
>>>
>>> https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/
>>
>> Sorry, I haven't been following. Don't we already have an implementation of the "Create a CI or other infrastructure for measuring D’s progress and performance" project? I just haven't been maintaining it because there hasn't been a lot of interest in it while it was being maintained.
>>
>> Here's the original blog post:
>>
>> https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/
>>
>> I'll give it a kick and get it back online if there is interest. Seems wasteful to reimplement it from scratch, though.
>
> I was aware of the site when i wrote the proposal, but the idea is to create the infrastructure to add more measurements too, e.g. profiling the compiler or testing it under limited memory (I found out how much memory my CTFE thing was using the other day!). Assuming I can get it to work I'd also like to throw the Linux perf system in there too,

Take a look at BPF.  Might be some work to wrap and if I recall right some of the C headers are a bit gnarly.  But it's pretty powerful.

https://github.com/brendangregg/bpf-docs

September 05, 2019
On Wednesday, 4 September 2019 at 23:56:07 UTC, Laeeth Isharc wrote:
> On Tuesday, 27 August 2019 at 17:32:30 UTC, Max Haughton wrote:
>> On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote:
>>> [...]
>>
>> I was aware of the site when i wrote the proposal, but the idea is to create the infrastructure to add more measurements too, e.g. profiling the compiler or testing it under limited memory (I found out how much memory my CTFE thing was using the other day!). Assuming I can get it to work I'd also like to throw the Linux perf system in there too,
>
> Take a look at BPF.  Might be some work to wrap and if I recall right some of the C headers are a bit gnarly.  But it's pretty powerful.
>
> https://github.com/brendangregg/bpf-docs

I'll look into it, thank you. Seems like a big rabbit hole to go down but the project is far from set in stone.
1 2
Next ›   Last »