Tech Agenda Track: Meeting Minutes 3/26

Haskell Foundation Technical Task Force (Slot 2) - Meeting Minutes
March 26, 2021


Andrew Lelechenko
Ben Gamari
Richard Eisenberg
Emily Pillmore
Davean Scies

Previous Meeting Minutes:


Emily: Proposal process in flight, we’ll have it in the github.

Vector Types Proposal

Ben: Meeting with lehins (Alexey Kuleshevich of Massiv) and winterland (Z-data) to sync on what we can agree on. Concrete migration strategy? Compatibility? We’ll need to talk.

Emily: Are the right people invited?
Ben: Yes, Andrew, Emily, winterland (of z-data), alexey, michael etc. etc. All stakeholders.
Ben: We must make sure Winterland is involved and he does a lot in this area.
Emily: I can help doing the proposal scaffolding in the meantime so you can hit the ground running.
Ben: I do worry about the risk associated with a large project like this
Emily: I’m not super worried about because this is what the point of HF is


Action Items:

Meeting with Alexey Kuleshevich of Massiv and Z-data folks to sync on what we can agree on.
Concrete migration strategy? Compatibility?
Not at the proposal stage yet.

GHC Performance Dashboard Proposal

Ben: As noted earlier, there is a document (meta: first link below) that can be considered a proposal.
Emily: Just posted, so we’ll take time to read. What are next steps?
Ben: Section 6 tracks work needed.
Emily: I like the idea of off-the shelf solutions like Grafana
Ben: There is an impedance mismatch. They are time series, but we are commit-based. Timeseries is sometimes a misleading way of viewing history. It’s more useful to view them on a commit basis.
Ben: Next steps: this requires people to do things.
Andrew: I don’t quite understand how we’re factoring the benchmarks. What are we measuring?
Davean: we’ve talked about this and it depends. You will want different things depending on the library.


Action Items:

Finish the proposal and find someone to lead this project.
Find resources to do this. People, time.


Ben: We need to figure out who will be able to move projects along if they get stalled
Emily: I can dedicate some of my time, you can act as advisor.
Richard: There is a broader “runtime system” that we need to sort out. We have a program, but no structure for what’s going to happen when projects kickoff.
Emily: yes, we’ll do a separate meeting and nail this down.
Richard: Project managers are not so weird for open source. Offering support, mentorship, friendship etc., we would not need to pay people. It does work for some things. We should try it before putting money towards it.
Davean: I think these proposals are low-enough skill that we can do this


Excited to read that z-data is being considered seriously as a replacement for vectors and text.


We’re certainly looking for inspiration from Z-Data. It’s a great set of ideas.

So when will be the next meeting? Is it the Haskell foundation meeting at 2021/4/9 ?

The tech track meetings take place on Tuesdays. The next meeting will take place on April 6, 2021.

HF meetings are intended to be posted to the HF calendar. That calendar includes the Tuesday, April 6 meeting.

Not sure where the right place to record this is, but I asked a friend who had encountered issues diagnosing pinned-memory induced fragmentation what tools might have helped with the job, and this was the reply: “default output of any of the memory inspecting tools to know what fraction of the heap is pinned memory (it took a little while to realize that’s what was going on), and some kind of way to work backwards through heap references to the thing that’s retaining pinned memory (or anything, even when it’s not pinned memory)”

I think it makes sense to encourage people to only use pinned memory when appropriate, but since we know pinned memory will need to be used some places, and will cause fragmentation when used, improving the tooling on profiling in the ways suggested (or other ways, more creative) should be on the radar.

I agree on both counts. GHC 9.2 improve things in the latter category, having support for cost-centre profiling of pinned allocations (see GHC #7275).