Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Sat, May 11, 2019 at 01:45:08AM +, Mike Franklin via Digitalmars-d-announce wrote: [...] > I think this thread is beginning losing sight of the larger picture. > What I'm trying to achieve is the opt-in continuum that Andrei > mentioned elsewhere on this forum. We can't do that with the way the > compiler and runtime currently interact. So, the first task, which > I'm trying to get around to, is to convert runtime hooks to templates. > Using the compile-time type information will allow us to avoid > `TypeInfo`, therefore classes, therefore the entire D runtime. We're > now much closer to the opt-in continuum Andrei mentioned previously on > this forum. Now let's assume that's done... Yes, that's definitely a direction we want to head in. I think it will be very beneficial. > Those new templates will eventually call a very few functions from the > C standard library, memcpy being one of them. Because the runtime > hooks are now templates, we have type information that we can use in > the call to memcpy. Therefore, I want to explore implementing `void > memcpy(T)(ref T dst, const ref T src) @safe, nothrow, pure, @nogc` > rather than `void* memcpy(void*, const void*, size_t)` There are some > issues here such as template bloat and compile times, but I want to > explore it anyway. I'm trying to imagine, what would memcpy in D look > like if we didn't have a C implementation clouding narrowing our > imagination. I don't know how that will turn out, but I want to > explore it. Put this way, I think that's a legitimate area to explore. But copying a block of memory from one place to another is simply just that, copying a block of memory from one place to another. It just boils down to how to copy N bytes from A to B in the fastest way possible. For that, you just reduce it to moving K words (the size of which depends only on the target machine, not the incoming type) of memory from A to B, plus or minus a few bytes at the end for non-aligned data. The type T only matters if you need to do type-specific operations like call default ctors / dtors, but at the memcpy level that should already have been taken care of by higher-level code, and it isn't memcpy's concern what ctors/dtors to invoke. The one thing knowledge of T can provide is whether or not T[] can be unaligned. If T.sizeof < machine word size, then you need extra code to take care of the start/end of the block; otherwise, you can just go straight to the main loop of copying K words from A to B. So that's one small thing we can take advantage of. It could save a few cycles by avoiding a branch hazard at the start/end of the copy, and making the code smaller for inlining. Anything else you optimize on copying K words from A to B would be target-specific, like using vector ops, specialized CPU instructions, and the like. But once you start getting into that, you start getting into the realm of whether all the complex setup needed for, e.g., a vector op is worth the trouble if T.sizeof is small. Perhaps here's another area where knowledge of T can help (if T is small, just use a naïve for-loop; if T is sufficiently large, it could be worth incurring the overhead of setting up vector copy registers, etc., because it makes copying the large body of T faster). So potentially a D-based memcpy could have multiple concrete implementations (copying strategies) that are statically chosen based on the properties of T, like alignment and size. [...] > However, DMD won't do the right thing. Honestly, at this point I don't even care. > I guess others are thinking that we'd just re-implement `void* > memcpy(void*, const void*, size_t)` in D and we'd throw in a runtime > call to `memcpy(&dstArray[0], &srcArray[0], T.sizeof())`. That's > ridiculous. What I want to do is use the type information to generate > an optimal implementation (considering size and alignment) that DMD > will be forced to inline with `pragma(inline)`. It could be possible to select multiple different memcpy implementations by statically examining the properties of T. I think that might be one advantage D could have over just calling libc's memcpy. But you have to be very careful not to outdo the compiler's optimizer so that it doesn't recognize it as memcpy and fails to apply what would otherwise be a routine optimization pass. > That implementation can also take into consideration target features > such as SIMD. I don't believe the code will be complex, and I expect > it to perform at least as well as the C implementation. My initial > tests show that it will actually outperform the C implementation, but > that could be a problem with my tests. I'm still researching it. Actually, if you want to compete with the C implementation, you might find that things could get quite hairy. Maybe not with memcpy, but other functions like memchr have very clever hacks to speed it up that you probably wouldn't think of without reading C library source code. There may also
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Saturday, 11 May 2019 at 00:32:54 UTC, H. S. Teoh wrote:
When it comes to performance, I've essentially given up looking
at DMD output. DMD's inliner gives up far too easily, leading
to a lot of calls that aren't inlined when they really should
be, and DMD's optimizer does not have loop unrolling, which
excludes a LOT of subsequent optimizations that could have been
applied. I wouldn't base any performance decisions on DMD
output. If LDC or GDC produces non-optimal code, then we have
cause to do something. Otherwise, IMO we're just uglifying D
code and making it unmaintainable for no good reason.
I think this thread is beginning losing sight of the larger
picture. What I'm trying to achieve is the opt-in continuum that
Andrei mentioned elsewhere on this forum. We can't do that with
the way the compiler and runtime currently interact. So, the
first task, which I'm trying to get around to, is to convert
runtime hooks to templates. Using the compile-time type
information will allow us to avoid `TypeInfo`, therefore classes,
therefore the entire D runtime. We're now much closer to the
opt-in continuum Andrei mentioned previously on this forum. Now
let's assume that's done...
Those new templates will eventually call a very few functions
from the C standard library, memcpy being one of them. Because
the runtime hooks are now templates, we have type information
that we can use in the call to memcpy. Therefore, I want to
explore implementing `void memcpy(T)(ref T dst, const ref T src)
@safe, nothrow, pure, @nogc` rather than `void* memcpy(void*,
const void*, size_t)` There are some issues here such as
template bloat and compile times, but I want to explore it
anyway. I'm trying to imagine, what would memcpy in D look like
if we didn't have a C implementation clouding narrowing our
imagination. I don't know how that will turn out, but I want to
explore it.
For LDC we can just do something like this...
void memcpy(T)(ref T dst, const ref T src) @safe, nothrow, @nogc,
pure
{
version(LDC)
{
// after casting dst and src to byte arrays...
// (probably need to put the casts in a @trusted block)
for(int i = 0; i < size; i++)
dstArray[i] = srcArry[i];
}
}
LDC is able to see that as memcpy and do the right thing. Also
if the LDC developers want to do their own thing altogether, more
power to them. I don't see anything ugly about it.
However, DMD won't do the right thing. I guess others are
thinking that we'd just re-implement `void* memcpy(void*, const
void*, size_t)` in D and we'd throw in a runtime call to
`memcpy(&dstArray[0], &srcArray[0], T.sizeof())`. That's
ridiculous. What I want to do is use the type information to
generate an optimal implementation (considering size and
alignment) that DMD will be forced to inline with
`pragma(inline)` That implementation can also take into
consideration target features such as SIMD. I don't believe the
code will be complex, and I expect it to perform at least as well
as the C implementation. My initial tests show that it will
actually outperform the C implementation, but that could be a
problem with my tests. I'm still researching it.
Now assuming that's done, we now have language runtime
implementations that are isolated from heavier runtime features
(like the `TypeInfo` classes) that can easily be used in -betterC
builds, bare-metal systems programming, etc. simply by importing
them as a header-only library; it doesn't require first compiling
(or cross-compiling) a runtime for linking with your program; you
just import and go. We're now much closer to the opt-in
continuum.
Now what about development of druntime itself. Well wouldn't it
be nice if we could utilize things like `std.traits`, `std.meta`,
`std.conv`, and a bunch of other stuff from Phobos? Wouldn't it
also be nice if we could use that stuff in DMD itself without
importing Phobos? So let's take that stuff in Phobos that
doesn't need druntime and put them in a library that doesn't
require druntime (i.e. utiliD). Now druntime can import utiliD
and have more idiomatic-D implementations.
But the benefits don't stop there, bare-metal developers,
microcontroller developers, kernel driver developers, OS
developers, etc... can all use the runtime-less library to
bootstap their own implementations without having to re-invent or
copy code out of Phobos and druntime.
I'm probably not articulating this vision well. I'm sorry.
Maybe we'll just have to hope I can find the time and energy to
do it myself and then others will finally see from the results.
Or maybe I'll go have a nice helping of crow.
Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Sat, May 11, 2019 at 12:23:31AM +, Mike Franklin via Digitalmars-d-announce wrote: [...] > Also, take a look at this data: > https://forum.dlang.org/post/jdfiqpronazgglrkm...@forum.dlang.org Why > is DMD making 48,000 runtime calls to memcpy to copy 8 bytes of data? > Many of those calls should be inlined. I see opportunity for > improvement there. [...] When it comes to performance, I've essentially given up looking at DMD output. DMD's inliner gives up far too easily, leading to a lot of calls that aren't inlined when they really should be, and DMD's optimizer does not have loop unrolling, which excludes a LOT of subsequent optimizations that could have been applied. I wouldn't base any performance decisions on DMD output. If LDC or GDC produces non-optimal code, then we have cause to do something. Otherwise, IMO we're just uglifying D code and making it unmaintainable for no good reason. T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Datapak: Data storage format with support for multiple compression algorithms
https://github.com/ZILtoid1991/datapak It's primarily function is to store application (such as game) assets in either compressed or uncompressed format, but its extendability enables it to store longer filenames and other OS important data, metadata, etc. Currently it's in a preliminary state, but works with zstd compression (the older zlib to be added soon, lz4 in a later version), and the hash/checksum functions haven't been fully implemented. Goals in the future: * Add support for fully random access of files where it's possible (such as in uncompressed mode and zstd with shared dictionary). * Collect data on what kind of functions I should add in the future (such as finalizing the default extension for file storage). * Making the library @safe compliant, mostly through @trusted wrappers and boundary checks towards low-level functions.
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Saturday, 11 May 2019 at 00:09:08 UTC, Mike Franklin wrote: On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote: I'm not 100% sure it's a good idea to implement memcpy in D just to prove that it can be done / just to say that we're independent of libc. Libc implementations of fundamental operations, esp. memcpy, are usually optimized to next week and back for the target architecture, taking advantage of the target arch's quirks to maximize performance. Not to mention that advanced compiler backends recognize calls to memcpy and can optimize it in ways they can't optimize a generic D function they fail to recognize as being equivalent to memcpy. I highly doubt a generic D implementation could hope to beat that, and it's a little unrealistic, given our current manpower situation, for us to be able to optimize it for each target arch ourselves. I understand that point of view. Indeed we have to demonstrate benefit. One benefit is to not have to obtain a C toolchain when building D programs. That is actually quite an inconvenient barrier to entry when cross-compiling (e.g. for developing microcontroller firmware on a PC). I'm also hoping that a D implementation would be easier to comprehend than something like this: https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S The D implementation still has to handle all of those corner cases, but I'd rather read D code with inline assembly sprinkled here and there than read the entire thing in assembly. The goal with the D implementation would be to minimize the assembly. For compilers that already do something special with memcpy and don't require a C standard library, there's no reason to do anything. My initial exploration into this has shown that DMD is not one of those compilers. Also, take a look at this data: https://forum.dlang.org/post/jdfiqpronazgglrkm...@forum.dlang.org Why is DMD making 48,000 runtime calls to memcpy to copy 8 bytes of data? Many of those calls should be inlined. I see opportunity for improvement there. Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote: I'm not 100% sure it's a good idea to implement memcpy in D just to prove that it can be done / just to say that we're independent of libc. Libc implementations of fundamental operations, esp. memcpy, are usually optimized to next week and back for the target architecture, taking advantage of the target arch's quirks to maximize performance. Not to mention that advanced compiler backends recognize calls to memcpy and can optimize it in ways they can't optimize a generic D function they fail to recognize as being equivalent to memcpy. I highly doubt a generic D implementation could hope to beat that, and it's a little unrealistic, given our current manpower situation, for us to be able to optimize it for each target arch ourselves. I understand that point of view. Indeed we have to demonstrate benefit. One benefit is to not have to obtain a C toolchain when building D programs. That is actually quite an inconvenient barrier to entry when cross-compiling (e.g. for developing microcontroller firmware on a PC). I'm also hoping that a D implementation would be easier to comprehend than something like this: https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S The D implementation still has to handle all of those corner cases, but I'd rather read D code with inline assembly sprinkled here and there than read the entire thing in assembly. The goal with the D implementation would be to minimize the assembly. For compilers that already do something special with memcpy and don't require a C standard library, there's no reason to do anything. My initial exploration into this has shown that DMD is not one of those compilers. On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote: [...] > Whereby I should say that tanya‘s range definitions differ > from Phobos. [..] I'm a bit uncomfortable with having multiple, incompatible range definitions. While the Phobos definition can be argued whether it's the best, shouldn't we instead be focusing on improving the *standard* definition of ranges, rather than balkanizing the situation by introducing multiple, incompatible definitions just because? It's one thing for Andrei to propose a std.v2 that, ostensibly, might have a new, hopefully improved, range API, deprecating the current definition; it's another thing to have multiple alternative, competing definitions in libraries that user code can choose from. That would be essentially inviting the Lisp Curse. Agreed. We should decide on one consistent definition. I don't know what that looks like right now. I'm more focused on low-level details right now. I do, however, like the idea of delegating the memory management (allocation/deallocation) outside of the library. If that's not feasible for some reason, then I would suggest it not be included in utiliD. I don't want dynamic memory allocation in utiliD; that should go into a higher-level library that may import utiliD. Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Friday, 10 May 2019 at 17:55:53 UTC, Johan Engelen wrote: Why would you use inline assembly ? (generalizing but: extremely bad portability, bad performance, bad readability) The only reason to use inline assembly is to achieve something that can't be achieved directly with D. For example, prior to the introduction of `volatileLoad` and `volatileStore` inline assembly was required to achieve `volatile` semantics. For memcpy and memcmp, one would first attempt to write a good implementation in straight D, but if the compiler doesn't generate good code for it, it would be appropriate to take control and provide an implementation in inline assembly. I don't know how a proper assembly implementation would not be performant. Perhaps you could elaborate. Recent discussion on LLVM mailinglist about the problem of the optimizer recognizing memcmp implementation and substituting it with a call to memcmp: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131973.html Yes, that bit me a while back when I was doing some bare-metal ARM Cortex-m development https://forum.dlang.org/post/clptjumxigcozfcyh...@forum.dlang.org For compilers that already provide an optimized intrinsic implementation for memcpy none of this is necessary; one could simply add a naive implementation, the compiler would recognize it, and replace it with their optimized version. DMD, to my understanding, is not one of those compilers. One of the goals is to no longer require a C toolchain to build D programs. If the compiler already provides intrinsics without needed a C standard library, Great! The other goal is to explore what D could improve upon with its design-by-introspection features and compiler guarantees (e.g. `pure` and `@safe`). My initial exploration into that can be found at https://github.com/JinShil/memcpyD I find it much easier to read D code like that than something like this: https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Fri, May 10, 2019 at 05:16:24PM +, Mike Franklin via Digitalmars-d-announce wrote: [...] > I've studied the ARM implementation of memcpy a little, and it's quite > hard to follow. I'd like for the D implementations to make such code > easier to understand and maintain. [...] I'm not 100% sure it's a good idea to implement memcpy in D just to prove that it can be done / just to say that we're independent of libc. Libc implementations of fundamental operations, esp. memcpy, are usually optimized to next week and back for the target architecture, taking advantage of the target arch's quirks to maximize performance. Not to mention that advanced compiler backends recognize calls to memcpy and can optimize it in ways they can't optimize a generic D function they fail to recognize as being equivalent to memcpy. I highly doubt a generic D implementation could hope to beat that, and it's a little unrealistic, given our current manpower situation, for us to be able to optimize it for each target arch ourselves. > On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote: [...] > > Whereby I should say that tanya‘s range definitions differ from > > Phobos. [..] I'm a bit uncomfortable with having multiple, incompatible range definitions. While the Phobos definition can be argued whether it's the best, shouldn't we instead be focusing on improving the *standard* definition of ranges, rather than balkanizing the situation by introducing multiple, incompatible definitions just because? It's one thing for Andrei to propose a std.v2 that, ostensibly, might have a new, hopefully improved, range API, deprecating the current definition; it's another thing to have multiple alternative, competing definitions in libraries that user code can choose from. That would be essentially inviting the Lisp Curse. T -- Life would be easier if I had the source code. -- YHL
Re: DConf 2019 Day 3 Slides
On Friday, 10 May 2019 at 08:03:52 UTC, Mike Parker wrote: The slides for Andrei's keynote can be found here: https://drive.google.com/open?id=1nrya9553FSMyBfLUmioYovVbqOoYycMe Thank you Andrei for presenting those last 3 slides. -Johan
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Friday, 10 May 2019 at 17:16:24 UTC, Mike Franklin wrote: On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote: - Memcmp, memcpy, memmove and memset are named equal, copy, copyBackward and fill respectively. I just wanted to create native implementations that are bit safer than their C counterparts. So they do the same job, but accept void[] instead of pointers. There are also templated functions with the same names, that work with ranges. I‘m not very comfortable with GCC‘s inline asm and it doesn‘t support naked asm as DMD does, so I put asm in the .S files and compile them separately. But I‘m fine with inline asm too. Why would you use inline assembly ? (generalizing but: extremely bad portability, bad performance, bad readability) Recent discussion on LLVM mailinglist about the problem of the optimizer recognizing memcmp implementation and substituting it with a call to memcmp: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131973.html cheers, Johan
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote: - Memcmp, memcpy, memmove and memset are named equal, copy, copyBackward and fill respectively. I just wanted to create native implementations that are bit safer than their C counterparts. So they do the same job, but accept void[] instead of pointers. There are also templated functions with the same names, that work with ranges. I‘m not very comfortable with GCC‘s inline asm and it doesn‘t support naked asm as DMD does, so I put asm in the .S files and compile them separately. But I‘m fine with inline asm too. A problem with the inline asm is that it should be written in several versions since DMD uses different calling conventions (unless we use extern(C)) and GDC and LDC use different asm syntax. Yeah, that is indeed unfortunate, and something I'll have to consider. I have had to write 3 different inline-asm implementations for some of my exporations, and didn't find it to be too bad. I very much prefer to read the D with the inline-asm than a straight assembly file. I've studied the ARM implementation of memcpy a little, and it's quite hard to follow. I'd like for the D implementations to make such code easier to understand and maintain. Tanya contains pretty much stuff now and I‘m just thinking to split it in a smaller parts (of a reasonable size), that are probably interesting for other people, who is ready to contribute, so I don‘t have to maintain everything myself. I don‘t know exactly what goes into this more „low-level“ library, we can always talk about it. Yes, I'm still working that out too. If you apply the rule that it should not require anything from druntime, the C standard library, or dynamic memory allocation, it does eliminate quite a bit, and narrows the scope. What I'm trying to do now is just focus on the obvious, and hopefully with that out of the way the rest will begin to reveal themselves. - OS API Not sure if it belongs to the scope of utilD. Some time ago it became clear to me, that while C has functions for dynamic memory management, it uses them internally very seldom. Instead it lets the user to allocate the memory. So there functions like: char *if_indextoname(unsigned int ifindex, char *ifname); that take an output buffer as the last argument. The same can be done with output ranges in D, so these system functions can be rewritten in D with a better interface. Whereby I should say that tanya‘s range definitions differ from Phobos. Yes, I like that. The buffer and memory management is then delegated outside of the library. That, IMO, makes the library more broadly useful. Fundamental algorithms (e.g. from std.algorithm, std.range, etc.) that can operate on memory buffers/ranges in this way would be good candidates for utiliD, IMO. But I'd want them to meet the criteria of being fundamental and broadly useful; not too specialized. Specialized algorithms that are designed for specific problem domains should probably go in a library designed for that problem domain. - meta Another thing probably interesting for utilD library is meta-programming. Tanya has „tanya.meta“ package which contains templates similar to to std.traits and std.meta + some nice extras like Union/Intersection/Difference working on sets of types, that are inspired by Boost Hana. This part is completely independent (from Phobos and the rest of tanya) and can even be a separate library. I'm thinking metaprogramming modules and packages are good candidates for utilitD as long as they are broadly useful. I see them more as extensions of the language than a library. Though, in a way, that's basically what libraries are too. I'll have to think about this some more but at the moment I'm leaning towards inclusion in utiliD. Mike
Re: DConf 2019 Day 3 Slides
Ali Çehreli closes out Day 3: https://drive.google.com/open?id=1Q1CS-TAtp25ofQYlsSq8TQQ3aZMJ_TdF
Re: DConf 2019 Day 3 Livestream
On Friday, 10 May 2019 at 07:10:25 UTC, Mike Parker wrote: Join us on YouTube again for Day 3: https://www.youtube.com/watch?v=nIXvs3mIg-E&feature=youtu.be Did anyone make a local copy of today's livestream by any chance? YouTube seems to only allow you to go back 2 hours into the stream.
Re: DConf 2019 Day 3 Livestream
On Friday, 10 May 2019 at 13:29:51 UTC, Les De Ridder wrote: On Friday, 10 May 2019 at 07:10:25 UTC, Mike Parker wrote: Join us on YouTube again for Day 3: https://www.youtube.com/watch?v=nIXvs3mIg-E&feature=youtu.be Did anyone make a local copy of today's livestream by any chance? YouTube seems to only allow you to go back 2 hours into the stream. The recorded talks will be ready in around two weeks.
Re: DConf 2019 Day 3 Slides
Kai Nacke follows John Colvin: https://drive.google.com/open?id=15AX00lv1o8Kujtzg7itQVyV01aJLUcQh
Re: DConf 2019 Day 3 Slides
John Colvin is up after Ethan: https://drive.google.com/open?id=1uQFpdD2MZAqNrbW6SSRzPpNn0G0yiK14
Re: DConf 2019 Day 3 Slides
Ethan will be opening the afternoon session. His slides are here: https://docs.google.com/presentation/d/1-mcJmcdPXSvtxAQu0AJW2D4C0SLToaDhZjp5uSBXoBE/edit?usp=sharing
The D install.sh script can now install a specific version of Dub
tl;dr: the D install script is now able to install a specific version of DUB. ./install.sh dmd-2.072.2,dub ./install.sh ldc-1.10.0,dub This is mostly useful if you want to test an old version of a DMD or LDC on a CI, but want to take advantage of all the stability fixes in dub and thus use the latest dub. The install.sh script is used on Travis too, so this will now work on Travis too: d: dmd-2.072.2,dub But of course you can select a specific version too: ./install.sh dmd-2.072.2,dub.1.7.2 Learn more about the install script: https://dlang.org/install Learn more about using D on Travis: https://docs.travis-ci.com/user/languages/d/ More details about this change: https://github.com/dlang/installer/pull/301
Re: DConf 2019 Day 3 Slides
Steven Schveighoffer is up after Bastiaan. His slides are here: https://drive.google.com/open?id=13drfMduAOAJS9tLzsXvzieoc3qf6h0Bj
Re: LDC 1.16.0-beta1
On Thursday, 9 May 2019 at 21:14:02 UTC, kinke wrote: Glad to announce the first beta for LDC 1.16; mainly just an upgrade to D 2.086.0. Thanks!
Re: DConf 2019 Day 3 Slides
The second talk is by Bastiaan Veelo: https://www.dropbox.com/s/c7is19vh6iizb9n/Veelo_DConf_2019.pdf?dl=0
DConf 2019 Day 3 Slides
The slides for Andrei's keynote can be found here: https://drive.google.com/open?id=1nrya9553FSMyBfLUmioYovVbqOoYycMe
DConf 2019 Day 3 Livestream
Join us on YouTube again for Day 3: https://www.youtube.com/watch?v=nIXvs3mIg-E&feature=youtu.be
