|
| 1 | +\documentclass[aspectratio=169]{beamer} |
| 2 | + |
| 3 | +\usepackage{ulem} |
| 4 | +\usepackage{dejavu} |
| 5 | +\usepackage{listings} |
| 6 | + |
| 7 | + |
| 8 | + \usetheme{Rochester} |
| 9 | +} |
| 10 | +\beamertemplatenavigationsymbolsempty |
| 11 | +\usecolortheme[RGB={115,79,150}]{structure} |
| 12 | +%\usefonttheme{structurebold} |
| 13 | + |
| 14 | + |
| 15 | +\title{What's new in the Fortran standard library?} |
| 16 | +\author{Nathaniel Shaffer \\[1em] \small |
| 17 | + \and Gabriel Brown |
| 18 | + \and Ond\v{r}ej \v{C}ertik |
| 19 | + \and William Clodius \\ |
| 20 | + \and Milan Curcic |
| 21 | + \and Laurence Kedward |
| 22 | + \and Sebastian Ehlert \\ |
| 23 | + \and Gareth Davies |
| 24 | + \and Aman Godara |
| 25 | + \and Michael Hirsch \\ |
| 26 | + \and Jing |
| 27 | + \and Chetan Karwa |
| 28 | + \and Arjen Markus |
| 29 | + \and Ivan Pribec \\ |
| 30 | + \and Harris Snyder |
| 31 | + \and J\'er\'emie Vandenplas |
| 32 | + \and Evan Voyles} |
| 33 | +\date{FortranCon 2021 - 24 Sept 2021} |
| 34 | + |
| 35 | +\begin{document} |
| 36 | + |
| 37 | +\begin{frame} |
| 38 | + \titlepage |
| 39 | +\end{frame} |
| 40 | + |
| 41 | +\begin{frame} |
| 42 | + \frametitle{What is \sout{new in} stdlib?} |
| 43 | + |
| 44 | + \begin{itemize} |
| 45 | + \item Part of fortran-lang: https://github.com/fortran-lang/stdlib |
| 46 | + \item Bridge the gap between intrinsics and applications |
| 47 | + \begin{description}[Mathematics] |
| 48 | + \item[Utilities] strings, logging, filesystem interaction |
| 49 | + \item[Algorithms] searching, sorting |
| 50 | + \item[Mathematics] linear algebra, special functions, statistics |
| 51 | + \end{description} |
| 52 | + \item Somewhere between C++ stdlib \& Matlab/scipy |
| 53 | + \end{itemize} |
| 54 | + |
| 55 | + \note{ |
| 56 | + Before I can show off what's new in the standard library, let's have a few words about what it is. |
| 57 | + It's a volunteer effort maintained under the fortran-lang organization, with the code hosted on Github. |
| 58 | + The main goal is to bridge the gap between what's offered intrinsically in the language versus the high-level code one would like to write in applications. |
| 59 | + This makes the scope of the Fortran standard library quite wide. |
| 60 | + We want to offer general programming-type things like common algorithms a la C++, while also providing a good base of numerically-oriented functionality like what's found in Matlab or the Python scientific ecosystem. |
| 61 | + That's a tall order, but we've made good headway. |
| 62 | + } |
| 63 | +\end{frame} |
| 64 | + |
| 65 | + |
| 66 | +\begin{frame} |
| 67 | + \frametitle{stdlib has roughly doubled in size in the past year} |
| 68 | + |
| 69 | + \begin{block}{Modules one year ago vs today} |
| 70 | + \centering |
| 71 | + \begin{tabular}{ccc} |
| 72 | + ascii & |
| 73 | + \textcolor{red}{bitsets} & |
| 74 | + error \\ |
| 75 | + io & |
| 76 | + kinds & |
| 77 | + linalg \\ |
| 78 | + \textcolor{red}{logger} & |
| 79 | + \textcolor{red}{math} & |
| 80 | + optval \\ |
| 81 | + quadrature & |
| 82 | + \textcolor{red}{sorting} & |
| 83 | + \textcolor{red}{specialfunctions} \\ |
| 84 | + stats & |
| 85 | + \textcolor{red}{stats\_distribution\_PRNG} & |
| 86 | + \textcolor{red}{stringlist\_type} \\ |
| 87 | + \textcolor{red}{strings} & |
| 88 | + \textcolor{red}{string\_type} & |
| 89 | + system |
| 90 | + \end{tabular} |
| 91 | + \end{block} |
| 92 | + |
| 93 | + \note{ |
| 94 | + By raw count of modules included in stdlib, the project has roughly doubled in size in the past year. |
| 95 | + A year ago, stdlib looked more like a grab-bag of utilities than a standard library. |
| 96 | + Now, it looks much more deserving of its name, with lots of exciting development in general-purpose programming functionality like string handling, sorting, logging, and support for bitsets. |
| 97 | + Let's have a look at some examples. |
| 98 | + } |
| 99 | +\end{frame} |
| 100 | + |
| 101 | + |
| 102 | +\begin{frame}[fragile] |
| 103 | + \frametitle{Demo: stdlib\_logger} |
| 104 | + |
| 105 | + |
| 106 | + \begin{block}{ex\_logger.f90} |
| 107 | + \small |
| 108 | +\begin{verbatim} |
| 109 | +use stdlib_logger, only: global_logger |
| 110 | +implicit none |
| 111 | +call global_logger%add_log_file('log.txt') |
| 112 | +call global_logger%log_debug('I am invisible') |
| 113 | +call global_logger%log_information('Something informative') |
| 114 | +call global_logger%log_error('Oopsie daisy') |
| 115 | +end |
| 116 | +\end{verbatim} |
| 117 | + \end{block} |
| 118 | + \begin{block}{log.txt} |
| 119 | + \small |
| 120 | +\begin{verbatim} |
| 121 | +2021-09-13 23:31:30.346: INFO: Something informative |
| 122 | +2021-09-13 23:31:30.346: ERROR: Oopsie daisy |
| 123 | +\end{verbatim} |
| 124 | + \end{block} |
| 125 | + |
| 126 | + \note{ |
| 127 | + This first example is a quick demonstration of the new `stdlib_logger` module. |
| 128 | + This module defines a derived type for logging messages to a file. |
| 129 | + This logger type is highly configurable, with options to control which file (or files) the logger should write to, how to format time stamps, which types of messages to log, and lots more. |
| 130 | + For very basic needs, one can use the predefined `global_logger` instance, as done here. |
| 131 | + Here, we're just connecting the logger to a file on disk and writing messages to it. |
| 132 | + Note how the ``debug'' message was not written, since the global logger is configured by default to log ``info'', ``warnings'', and ``errors''. |
| 133 | + This is just scratching the surface; the design is flexible enough to set up fairly sophisticated logging infrastructure. |
| 134 | + For instance, in a coarray application, one might configure separate loggers for each image or team of images. |
| 135 | + stdlib now makes it easy to set that up. |
| 136 | + } |
| 137 | +\end{frame} |
| 138 | + |
| 139 | + |
| 140 | +\begin{frame}[fragile] |
| 141 | + \frametitle{Demo: stdlib\_bitsets} |
| 142 | + |
| 143 | + \begin{block}{ex\_bitsets.f90} |
| 144 | + \small |
| 145 | +\begin{verbatim} |
| 146 | +use stdlib_bitsets |
| 147 | +implicit none |
| 148 | +
|
| 149 | +integer :: i; type(bitset_64) :: b1, b2 |
| 150 | +
|
| 151 | +call b1%from_string('001100') ! S6B001110 |
| 152 | +b2 = [(.true., i=1,6)] ! S6B111111 |
| 153 | +
|
| 154 | +call xor(b1, b2) ! S6B110001, S6B111111 |
| 155 | +
|
| 156 | +call b1%set(2, 4) ! S6B111111 -- N.B. 0-based index |
| 157 | +print *, b1 == b2 ! T |
| 158 | +end |
| 159 | +\end{verbatim} |
| 160 | + \end{block} |
| 161 | + |
| 162 | + \note{ |
| 163 | + The second demo is of the bitsets module. |
| 164 | + This provides a feature that is often proposed for standardization: an abstract type for working with strings of bits. |
| 165 | + The basic bitset type uses a 64-bit integer internally, but it keeps track of the actual length of the bitset being represented. |
| 166 | + Here, I'm initializing two 6-bit sets, one from a string and one from an array of logicals. |
| 167 | + The comment shows a string representation of the bitset, which can be taken as a bitset 'literal' for the purposes of I/O. |
| 168 | + Here, the prefix 'S6B' means a set of 6 bits. |
| 169 | + Most operations with bitsets work in-place rather than creating new instances. |
| 170 | + For instance, all the usual boolean algebra operations -- like the exclusive-or here -- are implemented as subroutines that overwrite the first argument. |
| 171 | + Likewise, when one sets or clears single bits or contiguous ranges of bits, the data is modified without making a copy. |
| 172 | + } |
| 173 | +\end{frame} |
| 174 | + |
| 175 | + |
| 176 | +\begin{frame} |
| 177 | + \frametitle{New contributors have been key to stdlib's growth} |
| 178 | + |
| 179 | + \begin{itemize} |
| 180 | + \item From 16 committors to 34, including our 2 GSoC students |
| 181 | + \item Over 100 new Issues: bugs, workflow improvements, feature proposals |
| 182 | + \end{itemize} |
| 183 | + |
| 184 | + \begin{block}{Commits to stdlib since FortranCon 2020} |
| 185 | + \centering |
| 186 | + \includegraphics[width=\textwidth]{contrib.png} |
| 187 | + \end{block} |
| 188 | + |
| 189 | + \note{ |
| 190 | + So we got lots of great new functionality, and in large part that's thanks to an influx of new contributors to the stdlib project. |
| 191 | + Not only has the number of modules doubles but so has the number of people who've committed changes to stdlib. |
| 192 | + Included in that are two Google Summer of Code students Aman Godara and Chetan Karwa, who we will hear from shortly. |
| 193 | + What that figure doesn't include is contributions made in the form of Issues and reviews of Pull Requests. |
| 194 | + It's really great to see over 100 new Issues opened in the past year, since this not only includes bug reports but also discussion of workflow improvments and proposals for new features. |
| 195 | + And looking at the timeline of commits since last year's FortranCon, we see a nice sustained development with big rushes of new development at the end of last summer and throughout this summer. |
| 196 | + } |
| 197 | +\end{frame} |
| 198 | + |
| 199 | + |
| 200 | +\begin{frame} |
| 201 | + \frametitle{stdlib is now easier to install} |
| 202 | + |
| 203 | + \begin{itemize} |
| 204 | + \item Dependencies |
| 205 | + \begin{itemize} |
| 206 | + \item Fortran compiler (supporting at least F2008) |
| 207 | + \item CMake (or just make) |
| 208 | + \item fypp preprocessor (python script) |
| 209 | + \end{itemize} |
| 210 | + \item Install each separately or use conda package manager |
| 211 | + \item Exports both CMake package files \& pkg-config files |
| 212 | + \item Support for fpm-based workflow is in progress |
| 213 | + \end{itemize} |
| 214 | + |
| 215 | + \note{ |
| 216 | + Besides implementing and discussing new features, the other way in which stdlib has improve a lot this past year is in infrastructure. |
| 217 | + In particular, it's now quite straightforward to work with stdlib, whether as a developer or a user. |
| 218 | + So the has three dependencies: a reasonably modern Fortran compiler, a reasonably recent version of CMake (or just make if you prefer), and the fypp preprocessor, which is used mainly as a templating engine for writing generic procedures. |
| 219 | + These are individually not hard to install on most systems, but one might be worried about having conflicting versions of Fortran compilers or CMake on one system. |
| 220 | + So to address that concern and also to just serve as a very simple way to get started, there's now a conda package that will automatically install the prerequisites for stdlib. |
| 221 | + So then once you get the stdlib source code from Github, you can build stdlib and run its test suite with either make or CMake. |
| 222 | + Then when you isntall stdlib, you get not only a static or shared library but also a pkg-config file and a CMake package file, which makes it very simply to use stdlib in your own projects. |
| 223 | + The ideal situation of course is to distribute stdlib as an fpm package, and while that's still a work in progres, there's been good progress on the fpm side of things. |
| 224 | + } |
| 225 | +\end{frame} |
| 226 | + |
| 227 | + |
| 228 | +\begin{frame} |
| 229 | + \frametitle{Cross-platform support monitored with Github's CI workflow} |
| 230 | + |
| 231 | + \begin{block}{Patforms tested on every pull request} |
| 232 | + \begin{tabular}{llll} |
| 233 | + GNU & 9,10,11 & Ubuntu 20.04 & x86\_64 \\ |
| 234 | + GNU & 9,10,11 & macOS 10.15 & x86\_64 \\ |
| 235 | + GNU (MSYS) & 10 & Windows Server 2019 & x86\_64 \\ |
| 236 | + GNU (MinGW) & 10 & Windows Server 2019 & x86\_64, i686 \\ |
| 237 | + Intel classic & 2021.1 & Ubuntu 20.04 & x86\_64 \\ |
| 238 | + Intel classic & 2021.1 & macOS 10.15 & x86\_64 |
| 239 | + \end{tabular} |
| 240 | + \end{block} |
| 241 | + |
| 242 | + \begin{itemize} |
| 243 | + \item If your compiler supports F2008/F2018, stdlib should compile |
| 244 | + \item Some require minor workarounds (NAG, some older GNU versions) |
| 245 | + \end{itemize} |
| 246 | + |
| 247 | + \note{ |
| 248 | + The stdlib project is also leveraging Github's continuous integration workflows to check cross-platform support. |
| 249 | + Currently, on every pull request, the CI builds stdlib and runs its test suite on seven different platforms meaning different combinations of compiler, OS, and CPU architecture. |
| 250 | + However, just because your platform is not shown here doesn't mean stdlib won't work on your system. |
| 251 | + Anecdotally, I've built stdlib with several versions of ifort on a recent MacBook as well as several versions of gfortran on a 10-year-old netbook running 32-bit Linux. |
| 252 | + } |
| 253 | +\end{frame} |
| 254 | + |
| 255 | + |
| 256 | +\begin{frame} |
| 257 | + \frametitle{Room for improvement} |
| 258 | + |
| 259 | + \begin{itemize} |
| 260 | + \item Fill out numerical capabilities |
| 261 | + \begin{itemize} |
| 262 | + \item ``Simple'' functions are often not so simple (e.g., $cbrt$) |
| 263 | + \item Difficult to find reviewers with domain knowledge (see: Probability Distributions) |
| 264 | + \item What to put in stdlib versus create fpm package? |
| 265 | + \end{itemize} |
| 266 | + |
| 267 | + \item Improve consistency of documentation |
| 268 | + \begin{itemize} |
| 269 | + \item Lots of variability in style \& level of detail |
| 270 | + \item To be addressed with standardized tempates |
| 271 | + \end{itemize} |
| 272 | + \end{itemize} |
| 273 | + |
| 274 | + \note{ |
| 275 | + I've used this talk mainly to highlight the cool new developments and accomplishments of the stdlib project so far, but there is certainly room for improvement. |
| 276 | + For one, most of the big exciting new modules in stdlib serve general programming needs. |
| 277 | + There are a couple reasons that numerical functionality has been slower to come in. |
| 278 | + One reason is that when one starts discussing the API and possible implementations, many ``simple'' functions turn out to have lots of subtle difficulties. |
| 279 | + My first-hand experience with this was in a discussion of a possible cube-root function, where one has to consider all kinds of floating-point edge cases that one wouldn't bother with in personal code but which is important to get right in a ``standard'' library. |
| 280 | + Another issue is that many numerical algorithms should be reviewed by people with particular domain knowledge to ensure that the implementation and tests make sense. |
| 281 | + The prime example of this right now is a handful of pull requests for statistical distributions that have been waiting for a reviewer with an appropriate background in statistics. |
| 282 | + When discussing new feature proposals, a recurring question is, ``should this be in stdlib or should this be an fpm package?'' |
| 283 | + Really, this is a testament to the progress made with fpm, but the point is that this boundary is still being mapped out. |
| 284 | + The other area where the stdlib project is actively trying to improve things is in the documentation. |
| 285 | + Even though documentation is required for every new procedure or type, the style and rigor of this documentation varies quite a lot. |
| 286 | + The proposed solution right now is to establish a baseline template for specifications to follow. |
| 287 | + This will hopefully give the stdlib documentation a more uniform feel, as well as be a helpful starting point for new contributors. |
| 288 | + } |
| 289 | +\end{frame} |
| 290 | + |
| 291 | +\begin{frame} |
| 292 | + \frametitle{Summary} |
| 293 | + |
| 294 | + \begin{itemize} |
| 295 | + \item stdlib aims to be a de factor standard library of general-purpose and numerical facilities for Fortran |
| 296 | + \item Roughly doubled in size in the past year, both in terms of modules and contributors |
| 297 | + \item New modules include bitsets, logging, math utilities, sorting, special functions, RNG, and string handling |
| 298 | + \item Infrastructure and packaging improvments have made stdlib easier to install and use |
| 299 | + \end{itemize} |
| 300 | +\end{frame} |
| 301 | + |
| 302 | +\end{document} |
0 commit comments