

        <cite>Jared Hoberock</cite>
      <time>0:00</time>
      <p>
          This   is   such   a   C   programmer   thing   to   worry   about.   Because   I   used   to   worry   about   what   to   name   things.   Because   in   C   ⁇   C   ⁇   is   a   very   paranoid   language.   Because   you   you   have   to   think   about   all   the   things   that   could   go   wrong   on   any   given   line   of   code.   Like   you   could   call   the   wrong   function   or   the   type   the   thing   gets   instantiated   with   is   will   will   be   missing   something   or   will   have   the   wrong   thing   in   it.   And   so   you   have   to   take   this   very   defensive   stance   when   writing   any   C   code.   Now   that   I&#39;ve   been   using   Rust   for   a   while   now,   I   don&#39;t   worry   about   these   things   at   all.   I   don&#39;t   worry   about   what   to   call   things.   I   don&#39;t   worry   about   uh   how   the   code   looks,   because   I&#39;m   I   can   be   confident   that   it   works.   I   don&#39;t   have   like   these   problems   just   don&#39;t   exist   in   Rust,   I   guess   is   what   I&#39;m   saying.
      </p>

        <cite>Conor</cite>
      <time>1:00</time>
      <p>
          Welcome   to   ADSP   the   Podcast,   episode   240,   recorded   on   May   21st,   2025.   My   name   is   Connor,   and   today   with   my   co-host   Bryce,   we   interview   Jared   Hobrok.   This   is   part   two   of   a   four-part   interview.   In   this   episode,   we   continue   our   conversation   about   thrust,   Rust   versus   C,   Python,   NumPy,   Numba,   and   more.   I   believe   Bryce   and   I   have   a   ton   more   questions   to   ask   you   on   the   roots   of   thrust.   I   mean,   I&#39;ve   been   holding   on   to   this   question   for   a   long   time.   Uh   the   last   time   I   was   in   New   York,   which   was   in   April,   we&#39;re   recording   this   tail   end   of   May,   we   got   into   a   discussion   of   the   different   names   for   uh   the   OG   name   is   IOTA   from   the,   I   guess   technically   it   was   the   C11   standard,   but   it   comes   from   APL.   IOTA   is   a   uh   integer   sequence   where   you   increment   by   one,   one,   two,   three,   four,   five,   six.   In   Thrust,   there   are   two   different   names   for   this.   There   is   the   counting   iterator,   and   there   is   also   the   thrust   sequence.   And   this   has   been   up   for   much   debate   between   Bryce   and   I   of   what   is   the   correct   name.   But   our   our   first   question   is   do   you   recall,   Jared,   where   the   names   for   both   thrust   sequence   as   an   algorithm   and   thrust   counting   iterator   as   a   fancy   iterator   do   you   recall   where   those   came   from?   Sequence   in   particular,   because   it   stands   out.
      </p>

        <cite>Jared Hoberock</cite>
      <time>2:35</time>
      <p>
          Uh   I   think   we   were   aware   of   IOTA   and   just   like   we   couldn&#39;t   name   it.   We   couldn&#39;t   give   it   that   name.   That   was   ridiculous.   We   were   gonna,   you   know.   It&#39;s   gonna   be   used   in   every   uh   example.   We   can&#39;t   use   this   stupid   name   that   doesn&#39;t   mean   anything.   So   I   think   that&#39;s   where   uh   sequence   came   from,   and   maybe   we   sort   of   justified   it   by   saying,   well,   the   the   interface   isn&#39;t   exactly   the   same,   so   we   have   to   change   the   name.   We   can&#39;t   use   iota.   And   counting   iterator,   I   think,   just   came   straight   from   Boost.   I   think   Boost   was   uh   I   think   there   was   a   Boost   counting   iterator   that   we   just   took.   If   you   want   to   talk   about   names,   I   can   tell   you   the   story   of   how   Thrust   got   its   name.   Yeah,   yes.
      </p>

        <cite>Conor</cite>
      <time>3:23</time>
      <p>
          Ooh,   I   would   love   that   story.   Yes.
      </p>

        <cite>Jared Hoberock</cite>
      <time>3:26</time>
      <p>
          So   uh   I   think   when   I   was   working   on   it   in   grad   school,   maybe   its   its   name   was   STD   CUDA,   like   std   CUDA.   Just   as   like   a   I   don&#39;t   know,   a   placeholder   name.   When   I   got   to   NVIDIA,   you   know,   maybe   someone   made   the   comment   it&#39;s   not   standard   and   it&#39;s   not   CUDA,   so   this   is   not   a   good   name.   So   we   said,   okay,   fine.   And   Nathan   had   just   gotten   back   from   uh   a   tour   of   Asia.   So   he   had   spent   a   few   weeks   touring   Asia   and   touring   like   post-Soviet   communist   countries.   And   he   had   this   picture   of   uh   you   know,   a   Soviet   worker   uh   from   a   mural   or   something   like   that.   And   I   don&#39;t   know,   for   some   reason   it   it   appealed   to   him,   and   he   decided   we   gotta   call   this   library   Comrade   with   a   K.   K-O-M-R-A-D-E.   And   we&#39;re   gonna   use   this   this   picture   I   took   as   the   avatar   uh   when   we   release   it.   I   didn&#39;t   really   have   a   strong   opinion   about   it,   and   I   I   believe   the   so   for   some   reason   he   wanted   to   give   the   library   a   a   communist   theme,   and   he&#39;s   not   like   a   left-wing   or   anything   like   that.   He   just   thought   it   was   funny.   And   I   remember   the   uh   so   we   released   it   on   Google   Code   under   the   name   Comrad,   and   the   uh   the   tagline   was   own   the   means   of   computation.   And   uh   we   were   really   proud   of   ourselves.   We   just   released   this   library   that   uh   we   were   really   proud   of.   We   gave   it   a   hilarious   name,   or   so   we   thought.   And   then   like   the   next   day,   we   after   announcing   that   we&#39;d   released   this   this   library,   you   know,   to   some   mailing   list   at   work,   uh,   we   get   a   response   from   someone   who   was   very   important   and   influential   uh   at   the   time   at   NVIDIA,   saying   that,   you   know,   communism   isn&#39;t   cute,   it   isn&#39;t   funny,   you   can&#39;t   name   it   this.   And   so   we   were   sort   of   shitting   our   pants   because   this   guy   is   very   important.   So   we   couldn&#39;t   we   had   to,   you   know,   save   face   somehow   and   think   about   a   different   name.   So   it   was   my   task   to   come   up   with   a   new   name   after   Nathan   had   had   failed   and   you   know   gotten   us   in   trouble.   So   what   I   did   was   I   I   looked   through   every   English   word   between   four   and   six   letters   ending   in   ST.   You   know,   since   we   we   were   stealing   everything   else   from   Boost,   we   thought   we   would   steal   the   name   as   as   well.   So   I   saw   Thrust   and   I   said,   How   about   Thrust?   And   you   know,   originally   I   think   people   were   like,   you   know,   we   were   going   from   this,   you   know,   uh   left   wing   tinged   name   to   some   sort   of   sexual   innuendo   for   a   name,   but   uh   we   stuck   with   it   and   somehow   the   the   name   is   stuck,   and   now   it&#39;s   you   know   it&#39;s   just   firmly   firmly   means   this   that   this   library&#39;s   name   and   and   nothing   else,   but   um   that&#39;s   where   the   name   came   from.   Just   another   thing   we   stole   from   Boost.
      </p>

        <cite>Conor</cite>
      <time>6:27</time>
      <p>
          I   was   gonna   say   is   I   always   thought   that   Thrust   and   Boost,   like   they   share   the   same   one-syllable   ST   ending,   and   that   was   intentional,   and   it   turns   out   that   is   the   case.
      </p>

        <cite>Bryce</cite>
      <time>6:39</time>
      <p>
          I   I   had   no   idea.   I   had   no   idea   that   that   was   intentional.   I   knew   about   the   comments.
      </p>

        <cite>Conor</cite>
      <time>6:44</time>
      <p>
          There&#39;s   the   guy   wearing   the   thrust   t-shirt,   which   we   haven&#39;t   mentioned   until   now.   At   one   point,   Bright   Bryce   left   the   uh   Microsoft   Teams   meeting   to   go   and   disappear,   and   he   came   back   with   a   thrust   t-shirt.
      </p>

        <cite>Bryce</cite>
      <time>6:57</time>
      <p>
          I&#39;ve   had   I   I   I   shouldn&#39;t   I   should   not   uh   I   say   this   for   a   variety   of   reasons,   but   I   had   these   t-shirts   made   like   right   when   I   first   started   NVIDIA,   and   I   believe   that   the   only   other   person   who   has   a   thrust   t-shirt   is   Jared,   because   I   think   I   gave   you   one   at   like   a   committee   meeting   in   2018   or   something.   But   I   I   I   had   like   five   of   them   made,   and   I   think   like   one   of   them   got   like   faded   in   the   wash,   and   so   I   tossed   it,   and   then   I   think   I   gave   one   to   Jared,   and   I   I   guess   I   must   have   misplaced   one   because   this   is   the   only   one   that   I   have   left.
      </p>

        <cite>Jared Hoberock</cite>
      <time>7:37</time>
      <p>
          Yeah,   they&#39;re   collector&#39;s   items   now.   Yeah.
      </p>

        <cite>Conor</cite>
      <time>7:41</time>
      <p>
          It   is   very   sad   because   I   can   my   my   my   what   is   it,   autistic   tendencies   or   OCD   can   sh   tell   me   that   it   is   the   same   logo   that   is   misaligned.   The   left,   or   I   guess   Bryce&#39;s   right   side   of   the   logo   is   slightly   thinner   than   the   left   side   of   the   logo.
      </p>

        <cite>Bryce</cite>
      <time>8:00</time>
      <p>
          So   in   uh   as   one   of   the   other   painful   things,   uh   so   the   painful   things   I   did   with   Thrust   was   one,   deal   with   the   version   control,   two,   revitalize   the   docs   uh   twice,   and   then   three,   I   had   to   reconstruct   this   uh   this   logo,   and   I   don&#39;t   remember   if   I   eventually   I   think   I   may   have   gotten   uh   like   some   form   of   source   image   from   Jared.   Uh,   but   I   remember   there   was   something   where   like   the   fonts   or   something   were   missing,   and   I   ended   up   having   to   like   like   I   spent   like   a   week   on   getting   the   the   remade   logo   a   little   bit   more   correct.   But   then   you   know   what   I   realized   the   other   day   was   why   didn&#39;t   I   fix   it   so   that   the   thrust   part   fits   all   the   way   in   the   box?   Like   I   got   this   S   and   this   T   out   here,   like   even   on   the   updated   one,   it&#39;s   not   all   the   way   in   there.   So   I&#39;m   so   bummed   at   myself   because   I   don&#39;t   think   I   can   I   don&#39;t   think   I   can   push   through   another   logo   change.
      </p>

        <cite>Conor</cite>
      <time>8:58</time>
      <p>
          The   real   question   is,   I   mean,   Thrust   has   within   the   name   of   it   a   programming   language,   aka   Rust,   I   mean,   which   is   our   our   a   fantastic   transition   point   to   what   is   the   future   of   parallel   programming,   parallel   algorithm   libraries?   I   mean,   if   you   could   restart   today   knowing   everything   you   know   now.   I   mean,   back   when   you   were   in   the   the   genesis   of   what   became   Thrust,   you   didn&#39;t   know   about   reductions,   you   grew   into   it,   and   it&#39;s   like   looking   back   on   it,   it   it   seems   obvious   that   you   would   know   that   stuff,   but   you   didn&#39;t   at   the   time.   And   and   that   is   so   true   of   like   so   many   things   that   they   teach   in   not   just   computer   science   but   mathematics,   it&#39;s   like   they   teach   you   the   artifact,   but   they   don&#39;t   teach   you   the   path   to   it.   And   the   path   is   very   nonlinear.   How   would   you,   if   you   were   starting   today,   uh   like   redesign   a   thrust   library?   Because   you&#39;ve   mentioned   a   couple   times   that,   you   know,   it&#39;s   kind   of   messy,   the   internals,   and   uh   you   don&#39;t   need   to   divulge   anything   about   your   current   work,   but   if   if   you   were   doing   thrust   2.0,   maybe   with   a   better   name,   with   a   better   implementation,   uh,   what   would   you   do?   Would   it   be   in   Rust?   Would   it   be   in   C?   Uh   tell   all.
      </p>

        <cite>Jared Hoberock</cite>
      <time>10:17</time>
      <p>
          I   know   what   I   what   I   would   do.   Uh   there&#39;s   not   a   langu,   there&#39;s   not   a   language,   there&#39;s   no   current   language   that&#39;s   uh   I   I   think   is   sufficient,   unfortunately.   But   um   sort   of   three   things   that   uh   a   language   would   need   to   do   something   like   uh   thrust   or   just   you   know   GPU   parallelism   really   well.   One   is   uh   asynchrony,   thrust   thrust   just   fails   at   asynchrony   for   various   reasons,   but   um   it   would   I&#39;d   start   you   know   start   with   um   a   model   for   asynchrony.   Um   heterogeneity   is   important,   uh   by   which   I   mean   uh   you   really   have   to   care   about   the   fact   that   you&#39;re   targeting   more   than   one   um   machine   and   they   have   different   architectures,   and   um   the   differences   in   the   architectures   matter.   Um   even   CUDA   doesn&#39;t   really   have   a   good   way   to   deal   with   this,   um   unfortunately.   And   um   I&#39;d   base   it   all   around   tensors,   not   uh   one-dimensional   sequences.   Um   tensors   and   multidimensionality   is   sort   of   really   important   for   uh   parallelism,   and   it&#39;s   important   for   uh   sort   of   vital   to   everything   that   people   do   with   uh   GPUs,   maybe   aside   from   video   games.   I   don&#39;t   know   how   much   tensors   are   important   for   video   games,   but   everything   else   you   do   with   a   GPU   involves   tensors   in   some   way.   Um   the   implementation   of   thrust   today   implicitly   uh   revolves   around   uh   tensors   because   you   have   these.
      </p>

        <cite>Bryce</cite>
      <time>11:57</time>
      <p>
          I&#39;m   pretty   sure   the   video   games   are   just   like,   you   know,   one   out   of   every   ten   frame   is   real   and   the   other   nine   are   AI.   So   I   think   it&#39;s   all   just   tensors   these   days.
      </p>

        <cite>Jared Hoberock</cite>
      <time>12:09</time>
      <p>
          Yeah,   I   I   agree.   But   um   I   think   a   good   language   for   doing   something   uh   with   uh   for   doing   GPU   parallelism   really   well   would   have   to   tackle   at   least   those   those   three   things.   And   um,   I   as   I   was   saying,   uh   whenever   you   write   a   ACUDA   kernel,   uh   you&#39;re   implicitly   doing   tensor   stuff   because   um   every   GPU   is   sort   of   shaped   uh   like   a   tensor   in   the   architecture.   So   if   you&#39;re   doing   something   like   a   thrust   reduce,   whether   you   know   it   you&#39;re   or   not,   when   you   take   that   uh   input   sequence,   you   have   to   sort   of   fold   it   into   a   shape   that   matches   the   shape   of   the   hardware,   and   um   inevitably   that&#39;s   some   sort   of   multi-dimensional   shape.   Um   so   having   a   language   where   that   was   more   explicit   and   can   be   taken   advantage   of   would   be   really   valuable   for   implementing   um   libraries   like   Thrust.   So   th   those   are   the   some   of   the   things   I   would   do   um   differently.   I   mean   there&#39;s   a   whole   lot   of   there&#39;s   a   whole   lot   of   like   problems   with   Thrust   that   um   are   there   because   of   for   C   ⁇   reasons.   Um   and   you   know   people   have   various   different   opinions   on   how   to   solve   C   ⁇   pro   uh   problems,   but   um   really   a   better   language   would   be   uh   would   be   uh   better   to   work   with.   Unfortunately   Rust   is   not   that   language.   Rust   uh   I   write   in   Rust   every   day.   I   really   like   it.   Um   it&#39;s   good   for   uh   single-threaded   code,   but   I   don&#39;t   think   it   handles   parallelism   um   that   well,   and   it   I   don&#39;t   think   it   knows   what   to   do   with   GPU   parallelism   at   all.   It&#39;s   sort   of   uh   at   odds   with   GPU   parallelism,   unfortunately.   Interesting.   Like   the   way   that   borrow   checking   works   sort   of   assumes   that   you&#39;ve   got   uh   a   single   thread   and   it&#39;s   going   to   call   functions   in   uh   sequential   order,   and   the   borrow   checker   works   really   well   when   you&#39;re   doing   that.   But   on   a   GPU   we   have   a   group   of   threads   and   they   want   to   communicate   and   they   maybe   they   want   to   mutate   different   parts   of   uh   a   shared   array,   and   uh   no   one   knows   how   to   make   that   work   with   uh   with   bar   borrow   checking.
      </p>

        <cite>Bryce</cite>
      <time>14:27</time>
      <p>
          Um   what   if   what   if   you   don&#39;t   program   the   threads   in   the   parallelism   directly?   What   if   um   the   way   that   you   express   the   parallelism   is   by   uh   like   performing   operations   on   arrays   that   get   paralyzed?   Um   and   and   they   so   what   if   you   just   threw   out   mutation?   Uh   that&#39;s   something   that&#39;s   the   other   way   to   do   it.   Yeah.
      </p>

        <cite>Jared Hoberock</cite>
      <time>14:54</time>
      <p>
          Let&#39;s   just   not   mutate   the   data   or   you   know,   let&#39;s   let&#39;s   let&#39;s   let   the   compiler   decide   how   to   parallelize   uh   collective   operations   on   tensors   or   something   like   that.   Um   that&#39;s   great.   You   don&#39;t   need   Rust   for   that.   I   mean   that&#39;s   sort   of   uh   Rust   assumes   you&#39;re   gonna   mutate   very   carefully   and   you&#39;re   going   to   think   very   carefully   about   sharing,   but   if   there&#39;s   no   sharing   and   there&#39;s   no   mutation,   you   don&#39;t   need   a   borrow   checker   at   all.
      </p>

        <cite>Bryce</cite>
      <time>15:25</time>
      <p>
          Ah,   that&#39;s   an   interesting   point.   Um   that&#39;s   a   very   interesting   point.   I   had   not   considered   that.   Um   that   if   you&#39;re   in   a   purely   value-based   world,   like   why   why   use   Rust?   Why   not   just   there&#39;s   like   dozens   of   options   for   that?   Yeah.
      </p>

        <cite>Jared Hoberock</cite>
      <time>15:40</time>
      <p>
          Well,   we&#39;ve   got   uh   armies   of   people   working   on   different   MLIR   dialects,   right?   Yes.   Um   so   we   need   to   leverage   those   armies   um   in   a   way   that   makes   sense   uh   in   a   high-level   language,   at   least   that&#39;s   my   opinion.   And   I   would   definitely   start   with   just   value   semantics,   just   uh   um   not   necessarily   functional,   but   um   like   SSA   sort   of   semantics.   That&#39;s   what   MLIR   gives   you   anyway.   Um   I   think   you   could   get   really   far   with   that,   um   especially   for   the   kinds   of   algorithms   that   are   in   thrust.   If   you   sort   of   assume   that   you   have   at   your   disposal   uh   operations   that   might   look   similar   to   what   you   would   see   in   Cub,   but   they&#39;re   sort   of   um   instead   of   mutating   uh   arrays   in   shared   shared   memory,   you&#39;re   instead   just   uh   performing   collective   operations   on   values.   Um   you   could   you   could   easily   build   uh   a   thrust   library   uh   or   a   thrust   like   algorithms   uh   like   that.   Uh   you   just   need   a   language   to   uh   express   it   in.   I   guess   another   thing   we   need,   one   really   bad   thing   about   uh   libraries   like   Thrust   or   Cub   or   Cutlass   is   that   they   are   locked   in   CUDA   C   templates,   right?   Uh   so   to   get   access   to   them   and   reuse   those   implementations,   you   need   to   generate   C   code   and   then   you   need   to   find   a   C   compiler   to   instantiate   that   code.   Like   think   about   what   we   do   from   you   know   Python   libraries   that   want   to   use   the   GPU.   Inevitably   they   generate   some   C   code   at   runtime,   compile   it,   and   uh   execute   it.   But   what   if   you   know   they   didn&#39;t   have   to   do   that?   What   if   those   implementations   were   um   in   a   more   portable   form   than   um   C   templates?   Um   what   if   you   didn&#39;t   need   a   C   compiler   to   use   uh   to   get   access   to   fast   algorithms   like   um   like   RinCub,   for   example?   That&#39;s   something   we   need.
      </p>

        <cite>Conor</cite>
      <time>17:47</time>
      <p>
          So   I   guess   the   question   is   what   is   preventing   us   from   having   the   world   that   you   are   describing   right   now   today?   Obviously,   Python,   I   think   the   three   of   us   in   this   meeting   can   agree,   and   the   folks   that   have   the   prerequisite   knowledge   to   also   agree   with   us   can   agree   that   Python   is   the   non-ideal   language   for   targeting   GPUs.   It&#39;s   dynamic.
      </p>

        <cite>Bryce</cite>
      <time>18:13</time>
      <p>
          Oh   no,   I   think   I   think   I   think   Py   I   I&#39;ll   take   a   contrary   uh   perspective   here.   I   think   Python&#39;s   great.   I   I   I   made   this   I   was   uh   for   the   first   time   ever,   I&#39;ve   been   on   another   podcast,   the   Talk   Python   to   Me   podcast,   and   I   made   this   point   that   I   I   will   claim   that   Python   is   actually   a   performance-oriented   language.   And   the   reason   for   this   is   that   Python   has   very   loosey-goosey   semantics.   It&#39;s   a   very   flexible   uh   language,   and   it   does   not   have   um   a   ton   of   uh   rigorous   protocol   when   interfacing   with   other   languages.   And   uh   it&#39;s   very   easy   to   build   a   DSL   in   Python.   It&#39;s   very   easy   to   build   something   that   takes   Python   syntax   and   kind   of   Python   semantics   and   lower   it   down   to   native   code.   And   it&#39;s   also   very   easy   for   Python   to   call   into   uh   native   uh   code.   I   remember   a   few   years   ago   I   went   to   this   like   conference   at   uh   Facebook.   That   this   was   back   when   I   was   in   California,   and   there   was   this   fellow   who   was   a   very   senior   uh   like   JVM   engineer,   and   he   was   talking   about,   he   gave   like   a   uh   a   30-minute   talk   solely   on   all   the   work   that   they   had   to   do   to   make   JVM   native   calls   fast.   And   the   reason   that   they   had   to   do   all   this   work,   it   was   like   the   calling   convention   for   JVM   to   call   native   code   was   like   at   minimum   a   hundred   instructions   because   the   JVM   had   these   very,   very   specific   protocols   for   like   you   know,   relating   to   like   object   semantics,   and   you   had   to   you   had   to   follow   all   these   rules.   Whereas   like   in   Python,   it   can   just   be   like,   oh,   you   just   you   just   call   this   function.   You   just   call   this   function,   you   know,   and   like   yeah,   maybe   the   like   if   you   want   to   have   like   two-way   interrupt,   like   maybe   the   function   needs   to   like   use   some   of   the   Python   APIs,   but   like   it&#39;s   super   simple   in   Python   to   just   call   a   C   function.   Um   and   that   makes   it   easy   for   Python   to   call   into   fast   things.   And   then   also   on   top   of   that,   it&#39;s   easy   to   extend   Python   to   build   DSLs   for   Python.   Um   and   so   because   of   that,   I   think   of   Python   as   being   more   a   performance-oriented   language.   I   think   Python&#39;s   more   similar   to   C   and   Rust   in   that   it   is   used,   uh,   I   would   say,   oh   maybe   not   predominantly,   but   certainly   it&#39;s   getting   closer   and   closer   to   that   point   where   Python   is   predominantly   used   for   performance-oriented   tasks   like   machine   learning   and   data   science.
      </p>

        <cite>Conor</cite>
      <time>20:40</time>
      <p>
          I&#39;ve   heard   you   say   this   three   times   now,   that   Python   is   performance-oriented.   And   I   I   literally   thought   the   first   time   you   said   it,   I   was   gonna   be   like,   oh,   he   said   it   one   time,   I   won&#39;t   be   able   to   call   him   out   on   it.   You   said   that   three   times.   Are   you   serious?
      </p>

        <cite>Bryce</cite>
      <time>20:54</time>
      <p>
          I   am   serious.   Hey,   we   have   free   threading   now.   It&#39;s   all   gonna   be   fast.   It&#39;s   gonna   be   very   fast.
      </p>

        <cite>Conor</cite>
      <time>21:00</time>
      <p>
          Jared,   do   you   can   you   back   me   up?   What   are   we   talking   about   here?   A   non-compiled,   dynamic,   interpreted   language   that   treats   integers   as   objects?   What   are   we   talking   about   here,   Bryce?   What   are   we   talking   about   here?
      </p>

        <cite>Bryce</cite>
      <time>21:15</time>
      <p>
          But   but   the   but   the   point   is   that   that   in   the   places   where   you   care   about   performance,   you   can   use   it   JIT.
      </p>

        <cite>Conor</cite>
      <time>21:21</time>
      <p>
          Like   if   you   if   you   write   Wait,   wait,   wait,   you   just   said   it   was   performance   oriented,   and   now   you&#39;re   saying   in   the   places   where   you   care   you   can   use   it?   It   treats   integers   as   ob   in   the   base   language,   like   if   you   want   performance,   it&#39;s   better   to   use   NumPy   instead   of   the   baked-in   lists   to   Python.   Like   as   soon   as   you&#39;re   over   a   thousand.
      </p>

        <cite>Bryce</cite>
      <time>21:43</time>
      <p>
          One   second,   one   second.
      </p>

        <cite>Jared Hoberock</cite>
      <time>21:44</time>
      <p>
          I&#39;m   pulling   up   I&#39;m   pulling   up   some   uh   The   reason   Bryce   can   say   this   is   because   Python   has   had   Python   is   backed   by   Google   and   has   been   for   the   past   twenty   years,   and   Google   is   the   you   know,   the   ones   that   have   been   Paying   to   make   all   of   these   libraries   fast   uh   through   Python,   right?   Um   but   as   soon   as   you   need   to   do   something   that   one   of   these   libraries   doesn&#39;t   have   a   C   API   for,   you&#39;re   screwed,   right?
      </p>

        <cite>Conor</cite>
      <time>22:13</time>
      <p>
          Um   that&#39;s   the   thing   is   that   like   in   general,   if   you   I   I&#39;ve   said   this   before   on   the   podcast   that   like   if   you   want   performant   code   in   Python,   you   shouldn&#39;t   use   Python,   you   should   use   NumPy.   Because   NumPy   is   implemented   in   C,   and   as   soon   as   you&#39;re   doing   anything   serious,   and   by   serious   I   mean   greater   than   a   thousand   elements   in   a   list,   it&#39;s   faster   just   in   any   library   that&#39;s   dispatching   to   C   code,   which   means   how   is   Python   performance   oriented?   That   means   that   Python   is   a   language   that   facilitates   fast   libraries   that   are   not   actually   in   Python.
      </p>

        <cite>Bryce</cite>
      <time>22:51</time>
      <p>
          Yes,   it   that   that   that   is   true,   but   also   Python   has   a   number   of   different   JIT   options   that   are   very   good.   So   this   is   this   is   uh   like   we   use   Numba   uh   uh   as   the   the   basis   of   our   like   CUDA   Python   device   code   authoring.   And   so   you   can   write   uh   uh   kernels   in   CUDA   Python   that   will   c   compile   down   to   the   same   machine   code   that   you   would   get   if   you   wrote   them   in   CUDA   C.   And   you   can   use   abstractions   like   lists,   like   you   can   use   all   the   Pythonic   things   in   the   in   this   code   because   it&#39;s   it&#39;s   just   this   like   little   DSL   that   is   Numba&#39;s   gonna   kind   of   violate   some   of   the   object   semantics,   you&#39;re   not   gonna   have   an   interpreter,   you&#39;re   not   gonna   have   object   lifetimes,   it&#39;s   gonna   map   everything   down   to   value   semantic   things   in   the   C   machine   model,   and   you&#39;ll   get   the   same   perf.   And   now   you   can   even   use   our   device-side   libraries   in   something   like   Numbakuda.   Uh   so   like,   yeah,   like   like   Python   on   its   face   is   like,   you   know,   can   be   pretty   slow.   But   Python   gives   you   all   the   tools   to   make   it   very,   very   fast.
      </p>

        <cite>Jared Hoberock</cite>
      <time>24:00</time>
      <p>
          Bryce,   are   you   talking   about   uh   publicly   about   how   it   works?
      </p>

        <cite>Bryce</cite>
      <time>24:04</time>
      <p>
          Uh   is   that   uh   not   publicly   knowledge?   No,   it&#39;s   it&#39;s   all   open   source.   It&#39;s   all   open   source   because   numba   is   just   an   open   source   JIT   compiler.   Um   so   what   Numba   does   is   it   just   takes   uh   either   Python   bytecode   or   AST   and   then   it   lowers   it   down   to   this   IR   called   Numba   IR.   And   then   all   that   numba   IR   is   used   for   is   to   do   type   inference,   to   figure   out,   hey,   you&#39;re   you&#39;re   calling   this   function   here,   you   know,   what   are   all   the   types?   And   then   once   you   have   all   the   types   resolved,   you   lower   it   down   to   either   LVMIR   or   MLIR.   And   then   it   compiles   just   like   it   would   native   code.   And   there&#39;s   like   two   or   three   like   major   JIT   solutions   like   this   for   Python.   Um   and   you   know,   the   the   the   best   analogy   I   can   give   is   like   JavaScript.   So   JavaScript   is   another   language   which   JITs   very,   very   well.   You   can   write   code   in   JavaScript   which   after   like   after   it&#39;s   been   JIT   has   performance   that   is   close   to   the   performance   of   native   code.   You   you   can&#39;t   do   that   with   a   language   like   Java,   um,   which   has   a   very   rigorous   object   model   that   makes   it   very   challenging   to   really   be   able   to   do   that.   But   with   languages   like   JavaScript   and   Python,   uh   their   object   models   are   a   really   good   fit.   Um   and   in   particular,   if   you&#39;re   writing   lists   like   NumPy   type   code,   if   it   like   Numba,   when   it   lowers   things   down,   if   it   sees   lists,   lists   get   lowered   down   to   just   like   a   uh   you   know   an   aggregate   type,   uh   the   equivalent   of   like   a   std   tuple.   Um   you   know,   integers,   floats,   etc.,   when   they   get   jit   compiled,   they&#39;re   just   gonna   be   lowered   down   to   the   equivalent,   you   know,   uh   native   uh   processor   types.   And   something   like   a   numpy   array,   it&#39;s   just   gonna   be   lowered   down   to   like   a   pointer   plus   some   metadata,   you   know,   the   equivalent   of   like   an   MD   span.   Um   but   yeah,   like   like   Numba,   it   just   it   just   goes,   takes   your   DSL,   takes   your   your   Python   AST   or   your   Python   bytecode,   turns   it   into   um   uh   uh   this   intermediate   IR   and   it   does   the   typing   and   then   it   becomes   LVM   IR   or   MLIR.   And   Numba   is   like   the   heaviest   weight   of   the   Python   DSL   compilers.   There&#39;s   also   a   lot   of   other   DSL   compilers.   There&#39;s   some   that   do   transpilation,   so   they   take   Python   code,   they   turn   it   into   C.   This   is   actually   what   Coupy   does.   Coupy   takes   your   Python   code   and   it   turns   it   into   like   it&#39;ll   it&#39;ll   spit   out   like   thrust   or   cub   code   and   then   it&#39;ll   jit   compile   that   code.   Um   and   then   there&#39;s   other   compilers   that   will   use   an   approach   called   tracing,   where   um   instead   of   like   parsing   the   Python   AST,   they   essentially   just   inject   mock   objects   into   your   code,   and   then   as   your   code   executes,   instead   of   doing   whatever   your   code   was   supposed   to   do,   it   captures   a   trace,   and   it   builds   up   uh   like   from   your   actual   code   execution,   it   builds   up   a   representation   of   your   program,   and   then   they   transform   that   and   they   lower   it   down   in   whatever   way.   Uh   this   is   how   like   things   like   Triton   used   to   work,   although   I   think   they   now   have   a   more   proper   compiler   framework,   but   there&#39;s   a   ton   of   these   different   uh   like   tracing   frameworks.   Like   one   problem   that   we   have   at   NVIDIA   is   that   it&#39;s   so   easy   to   make   DSLs   in   Python   that   we   have   like   20   DSLs   in   Python.   Like   every   two   to   three   weeks,   somebody&#39;s   creating   a   new   Python   DSL.
      </p>

        <cite>Jared Hoberock</cite>
      <time>27:21</time>
      <p>
          Yeah,   but   what   if   you   need   to   write   a   kernel?   Like   none   of   these   none   of   these   approaches   uh   have   anything   to   offer.
      </p>

        <cite>Bryce</cite>
      <time>27:29</time>
      <p>
          Yeah,   yeah,   they   do.   You   can   you   can   totally   write   kernels   in   uh   uh   you   can&#39;t   write   kernels   really   in   Python.   Yeah,   yeah.   You   can   you   can   you   have   access   to   all   the   tools   that   you   have   in   Access.
      </p>

        <cite>Jared Hoberock</cite>
      <time>27:40</time>
      <p>
          No   one&#39;s   serious,   no   one   no   one   serious   is   writing   kernels   in   Python.   I&#39;m   telling   you,   then   why   isn&#39;t   Thrust   written   in   Python?
      </p>

        <cite>Bryce</cite>
      <time>27:48</time>
      <p>
          Uh   yeah,   we   we   could   get   there.   So   like   this   is   this   is   a   uh   this   is   like   a   speed   of   light   softmax   kernel   written   in   like   native   uh   uh   native   Python.   You   can   allocate   shared   memory,   you   can   allocate   register   memory,   you   can   use   Cub,   uh   you   can   use   like   other   libraries   too.   Like   people   people   are   starting   to   use   this.   People   are   starting   to   write   like   serious   kernels.
      </p>

        <cite>Jared Hoberock</cite>
      <time>28:12</time>
      <p>
          Why   is   it   good   for   a   kernel   to   look   like   that?
      </p>

        <cite>Bryce</cite>
      <time>28:15</time>
      <p>
          Um   because   one   you   get   to   do   you   get   to   use   numpy   style   arrays.   Like   like   the   the   Python   has   like   de   facto   uh   uh   very   nice   rank   polymorphism.   Uh   would   you   care   to   elaborate   on   that,   sir?
      </p>

        <cite>Conor</cite>
      <time>28:33</time>
      <p>
          You&#39;re   saying   numpy   like   arrays,   but   the   word   is   rank   polymorphism,   like   that&#39;s   the   thing   that   Jared   was   saying   is   if   he   was   gonna   do   it   over   again,   he   would   implement   it   in   terms   of   tensors.   When   you&#39;re   implementing   something   in   terms   of   tensors,   it   means   you   if   you   have   a   two-dimensional   or   three-dimensional   array,   you   don&#39;t   have   to   spell   map,   map,   map   in   order   to   do   an   element-wise   operation   over   your   arbitrarily   ranked   array.   NumPy   semantics   is   array   language   semantics.   It   means   that   if   you   want   to   do   some   element-wise   operation,   it&#39;s   just   a   single   character   plus   a   scalar   or   something   like   that.   So   like   that   is   that   is   one   of   the   benefits   of   NumPy,   which   is   a   poorly   implemented   array   language,   is   ranked   polymorphism   or   broadcasting.
      </p>

        <cite>Bryce</cite>
      <time>29:20</time>
      <p>
          And   this   isn&#39;t   even   to   mention   the   very   cool   thing   that   we   announced   at   GTC   this   year,   which   is   Qtile,   which   is   uh   a   new   higher-level   programming   model   for   CUDA   that&#39;s   entirely   array-based,   um,   where   you   don&#39;t   explicitly   program   uh   threads.   And   uh   and   like   this   is   what   the   speed   of   light   softmax   looks   like   in   Qtile.   Uh   and   on   like   on   the   left   you&#39;re   seeing   the   NumPy   code,   and   on   the   right   you&#39;re   seeing   the   Qtile   code,   and   they&#39;re   very   close.   And   it&#39;s   usually   taking   advantage   of   the   rank   polymorphism   that   Connor&#39;s   talking   about.   But   to   get   to   the   question,   why   would   you   want   to   write   a   kernel   from   Python?   Well,   it   there&#39;s   a   very   simple   answer   to   that   question,   which   is   if   you   can   write   the   kernel   in   Python,   then   you   don&#39;t   have   to   deal   with   having   to   support   both   C   and   Python   in   your   application.   Then   you   don&#39;t   have   to   you   don&#39;t   have   to   deal   with   having   a   C   build   system,   and   it   solves   a   bunch   of   packaging   problems   for   for   you   because   instead   of   having   to   build   a   Python   extension   or   a   shared   library   that   Python   loads,   you   can   just   ship   Python   source   code,   uh,   which   is   what   most   pi   most   Python   projects   do.   So   like   it   saves   like   a   lot   of   headache   that   people   have   to   do   things.   I&#39;m   not   here   to   defend   the   language.
      </p>

        <cite>Jared Hoberock</cite>
      <time>30:33</time>
      <p>
          I&#39;m   just   like   uh   defending   the   idea   of   an   ideal   what   what   is   the   platonic   ideal   of   uh   GPU   programming   language?   I   I   wouldn&#39;t   begin   with   Python,   I   guess   is   what   I&#39;m   saying.   I   understand   people   have   people   like   Python   and   they   have   requirements   to   use   Python.   I   just   like   to   imagine   what   the   perfect   GPU   language   would   look   like.
      </p>

        <cite>Bryce</cite>
      <time>30:55</time>
      <p>
          I   would   agree,   and   the   reason   I   would   agree   is   that   um   there   are,   while   I   think   that   the   numpy   ecosystem   and   its   prevalence   in   Python   is   a   huge   improvement   over   C.   Having   these   like   rank   polymorphic   uh   arrays   that   are   that   are   it&#39;s   a   vocabulary   type.   It&#39;s   it&#39;s   not   like   part   of   the   language,   but   it&#39;s   so   it&#39;s   in   such   wide   usage   that   like   every   library   that   does   anything   with   tensors   supports   the   numpy   semantics.   And   that&#39;s   great.   However,   numpy   is   a   little   bit   old,   20,   30   years   old,   and   uh   it   does   have   like   a   number   of   words   to   it.
      </p>

        <cite>Conor</cite>
      <time>31:28</time>
      <p>
          One   of   the   things   Whoa,   whoa,   whoa,   whoa,   whoa,   let&#39;s   back   up.   Python   is   30   years   old,   not   NumPy.   You&#39;re   getting   your   languages   and   your   libraries   confused.   Python   was   created   in   1993   or   94.   NumPy   was   not.   When   was   NumPy   created?   NumPy,   I   think   it   became   popular   around   2010.   And   I   I   I   I   I   agree   completely   with   Jared.   Like,   if   if   I&#39;m   designing   a   GPU   language   from   scratch,   I&#39;m   not   starting   anywhere   close   to   Python.   The   fact   that   Python   has   become   the   lingua   franqua   of   in   2005,   by   yeah,   Travis   Oliphant.   It   was   2000.
      </p>

        <cite>Bryce</cite>
      <time>32:06</time>
      <p>
          It   was   20   years   ago.   I   said   20   years.   That   is   50.
      </p>

        <cite>Conor</cite>
      <time>32:09</time>
      <p>
          No,   no,   no.   You   said   30.   30   was   the   genesis   of   Python.
      </p>

        <cite>Bryce</cite>
      <time>32:13</time>
      <p>
          I   had   dinner   with   uh   or   we   were   at   the   same   the   same   dinner   table   uh   uh   at   the   uh   Py   Ladies   charity   auction   with   with   Travis   Oliphant   last   week.   Very   nice   fellow.
      </p>

        <cite>Conor</cite>
      <time>32:23</time>
      <p>
          Fantastic,   fantastic.   My   point   being   is   that   I   agree   with   Jared.   Python   was   created   30   years   ago,   NumPy   halfway   through   the   lifetime   of   Python,   and   a   dynamically   quasi-strongly   typed   language   with   all   this,   you   know,   uh   great   you   know,   FFI.   That&#39;s   not   the   reason   that   Python   today   is   the   language   that   folks   use   to   target   GPUs   is   not   because   it&#39;s   a   good   language   for   targeting   GPUs.   It   is   okay,   but   it&#39;s   not   where   I   would   start.   And   that&#39;s   I   think   that&#39;s   what   Jared   was   trying   to   say,   is   that   it   I   I   think   Python   uh   gets   in   the   way   of   what   we   would   like   from   a   language   in   terms   of   trying   to   eke   out   max   efficiency   and   performance   from   GPUs,   uh   and   it&#39;s   just   an   artifact   of   history   that   it&#39;s   become   the   lingua   franca   of   data   science   and   machine   learning   and   deep   learning,   etc.   I   don&#39;t   know.   Maybe   Jared,   you   could   you   could   add   if   if   you   disagree   with   what   I   just   said.
      </p>

        <cite>Jared Hoberock</cite>
      <time>33:22</time>
      <p>
          When   I   when   I   uh   so   I   picked   up   Python   recently   because   I   was   a   uh   I   was   considering   using   it   for   a   project.   And   whenever   I   use   Python,   I   feel   like   I&#39;ve   lost   like   I&#39;ve   gone   blind,   like   I&#39;ve   lost   a   sense   because   there   are   no   types.   And   even   when   there   are   types,   they&#39;re   not   really   there,   right?   Like   they   don&#39;t   do   anything   for   you.   So   I   feel   like   uh   I   mean   even   if   you   use   the   type   descriptions,   they   don&#39;t   they&#39;re   not   helpful.   Um   I   don&#39;t   know,   I   just   feel   like   I   have   brain   damage   or   something   when   I&#39;m   writing   or   reading   or   writing   uh   Python   code.   Uh   I   like   Rust   because   once   uh   cargo   check   is   happy   with   the   program,   I&#39;m   confident   it&#39;s   gonna   work.   I   can   do   enormous   refactors   to   a   code   base   and   be   confident   that   um   they   were   correct.   And   nothing   like   that   is   possible   with   Python.   Um   I   know   it&#39;s   important.   I   know   it&#39;s   probably   the   most   important   programming   language,   but   there   are   some   things   that   Python   is   uh   inadequate   for.
      </p>

        <cite>Bryce</cite>
      <time>34:28</time>
      <p>
          So   there&#39;s   a   particular   wart   of   NumPy   that   uh   that   I   want   to   highlight.   But   if   I   highlight   that   wart,   it   rapidly   leads   into   the   really   cool   algorithm   that   I   want   to   show   you.   And   I   suspect   that   that   Connor   may   have   a   couple   a   couple   topics   he   wants   to   discuss   with   Jared   before   we   get   there.
      </p>

        <cite>Conor</cite>
      <time>34:51</time>
      <p>
          So   no,   no.   I   mean   we   we   can   go   down   this   rabbit   hole.   I   would   just   like   to   go   on   record   saying   that   Python   is   the   most   popular   language   in   the   world   at   the   time   that   LLMs   have   come   of   age,   which   makes   you   think   that   the   rich   are   just   gonna   get   richer.   I   am   willing   to   bet   my   life   on   the   fact   that   Python   will   not   be   the   actual   language   that   LLMs   target   because   it&#39;s   it&#39;s   not   like   a   language   like   Rust   that   is   statically   typed,   has   more   linting,   etc.,   is   better   to   target   than   a   dynamically   typed   language.   And   and   so,   anyways,   I&#39;m   just   going   on   record   saying   Python   is   popular   now   and   will   die   before   I   die.   And   uh   that&#39;s   also   keeping   in   mind   that   I   will   upload   my   brain   to   the   cloud   and   live   forever,   uh   at   which   point   we   will   now   transition   to   Bryce&#39;s   segue   into   his   algorithm   that   he   wants   to   talk   about.
      </p>

        <cite>Bryce</cite>
      <time>35:46</time>
      <p>
          So   before   we   get   there,   uh   a   quick   quick   thing   on   LLMs.   Um   so   I&#39;ve   been   thinking   a   little   bit   recently   about   this   question   about   like   what   um   what   language   will   the   LLMs   write   code   in?   And   one   thing   that&#39;s   come   up   is   this   question   of   coding   conventions.   Uh   uh   in   particular,   what   coding   conventions   should   we   as   programmers   follow   to   make   it   easier   to   use   LLMs   in   our   code   bases?   And   one   particular   piece   of   this   that&#39;s   come   to   mind   to   me   has   been   around   naming   conventions.   I   think   typically,   at   least   me,   I   tend   to   prefer   I   earlier   in   my   career   I   would   use   very   long   and   verbose   names.   Um   but   now   I   primarily   write   code   for   slides.   And   I   got   a   limited   number   of   characters   that   I   can   use   in   the   slide.   And   so   I   found   myself   using   shorter   and   shorter   names   as   my   career   goes   on.   But   it   seems   to   me   like   you   probably   want   to   use   quite   descriptive   names   in   your   code   base   if   you&#39;re   planning   on   using   LLMs   to   help   you   write   your   code.   Uh   maybe   even   you   want   to   use   um   names   that   are   you   know   more   verbose   than   would   be   comfortable   for   a   human.   Uh   because   that&#39;s   like   if   you   use   very   short   names   that   could   be   ambiguous   or   misinterpreted,   it   might   be   more   confusing   to   the   LLM.   Whereas   if   you   use   very   clear   and   concise   names   that   uh   are   unambiguous,   that&#39;s   gonna   probably   give   you   better   better   results   with   using   LLMs.
      </p>

        <cite>Jared Hoberock</cite>
      <time>37:25</time>
      <p>
          This   is   such   a   C   programmer   thing   to   worry   about.   Uh   because   I   used   to   worry   about   whatn   what   to   name   things.   Because   in   C   is   a   very   paranoid   language   because   you   you   have   to   think   about   all   the   things   that   can   go   wrong   on   any   given   line   of   code.   Like   you   could   call   the   wrong   function   or   the   type   the   thing   gets   instantiated   with   is   will   will   be   missing   something   or   will   have   the   wrong   thing   in   it.   And   so   you   have   to   take   this   very   defensive   stance   when   writing   any   C   code.   Now   that   I&#39;ve   been   using   Rust   for   a   while   now,   I   don&#39;t   worry   about   these   things   at   all.   I   don&#39;t   worry   about   what   to   call   things,   I   don&#39;t   worry   about   uh   how   the   code   looks,   because   um   I&#39;m   I   can   be   confident   that   it   works.   I   don&#39;t   have   to   like   these   problems   just   don&#39;t   exist   in   Rust,   I   guess,   is   what   I&#39;m   saying.   Uh   these   things   I   used   to   get   uh   paranoid   about   uh   in   my   C   ⁇   template   codes.   Um   there&#39;s   usually   only   one   right   way   to   write   you   know   the   Rust   uh   function   um   you   know   according   to   some   LLM   and   if   it   compiles   then   it&#39;s   and   it&#39;s   correct   and   you   know   and   you   move   on.   Um   these   these   ambiguities   just   simply   don&#39;t   exist.   It&#39;s   a   very   relaxing   way   to   to   write   code.
      </p>

        <cite>Conor</cite>
      <time>38:50</time>
      <p>
          And   and   I   I   can   echo   that.   It&#39;s   when   you   write   Rust   code,   I   like   I   am   more   of   an   expert   in   C   than   I   am   in   Rust   by   uh   two   orders   of   magnitude.   Like   I&#39;ve   written   a   couple   thousand   lines   of   Rust.   That   doesn&#39;t   make   me   an   expert,   but   like   I   know   the   inner   details   of   the   special   member   functions   and   all   this   stuff,   and   I   I   I   have   so   much   like   cognitive   weight   in   my   brain   when   I   program   C,   and   I&#39;m   like,   oh   I   gotta   am   I   using   an   initializer   list?   Well,   I&#39;ve   got   a   special   set   of   rules   for   that.   And   it&#39;s   just   like   I   have   all   these   voices   talking   in   my   head   when   I   program   in   C.   When   I   go   to   Rust,   I&#39;m   kind   of   just   like,   I   don&#39;t   really   know   what&#39;s   happening   here.   But   the   compiler   like   holds   your   hand   and   is   like,   don&#39;t   worry,   I&#39;ll   be   the   expert.   You   just   program   the   way   you   want   to   program.   And   I   all   I&#39;m   saying   is   the   future   of   generated   code   targets   a   language   like   that.   Not   like   C,   where   you   have   a   matrix   of   special   member   functions   where   depending   on   the   subset   that   you   implemented,   you   will   get   a   certain   other   set   generated.   It&#39;s   anyway,   so   I   mean,   and   that&#39;s   C.   You&#39;re   trying   to   say   that   Python,   a   dynamically   typed,   etc.   etc.   language   is   gonna   be   the   No.   It&#39;s   it&#39;s   in   the   short   term,   that&#39;s   what&#39;s   gonna   happen.   In   the   long   term,   the   more   compiler   upfront   static   analysis   guarantees   that   uh   you   can   get,   that&#39;s   what&#39;s   gonna   be   the   future,   in   my   opinion.   But   Bryce   has   a   story   to   tell   us   about   some   algorithm   and   uh   potentially   refuting   everything   we&#39;re   saying   here.   So   we&#39;ll   let   we&#39;ll   let   Bryce   speak   now   and   uh   convince   us.   Be   sure   to   check   these   show   notes   either   in   your   podcast   app   or   at   adspthepodcast.com   for   links   to   anything   we   mentioned   in   today&#39;s   episode,   as   well   as   a   link   to   a   GitHub   discussion   where   you   can   leave   thoughts,   comments,   and   questions.   Thanks   for   listening.   We   hope   you   enjoyed   and   have   a   great   day.
      </p>

        <cite>Bryce</cite>
      <time>40:52</time>
      <p>
          Low   quality,   high   quality,   that   is   the   tagline   of   our   podcast.
      </p>

        <cite>Conor</cite>
      <time>40:57</time>
      <p>
          That&#39;s   not   the   tagline.   Our   tagline   is   chaos   with   sprinkles   of   information.
      </p>