home.social

#parallel — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #parallel, aggregated by home.social.

  1. 🎯 Supported models include #GPT-OSS-120B, #GPT-OSS-20B, #Llama4 Maverick, #Llama4 Scout, #Llama33-70B, #Llama31-8B, #KimiK2, #Qwen3-32B

    🔧 Key features: deterministic inference for faster tool-using agents, cost-effective scaling, approved tool use with clear allowlists, seamless migration capability

    📋 Ready-to-use cookbook tutorials with #BrowserBase #MCP, #BrowserUse #MCP, #Exa #MCP, #Firecrawl #MCP, #HuggingFace #MCP, #Parallel #MCP, #Stripe #MCP, #Tavily #MCP

  2. A #Slurm user just confirmed that "yay it works. Pretty sick!"

    Thanks to excellent feedback from several users, it'll soon be even easier to distribute #rstats code via #HPC job schedulers using future.batchtools

    future.batchtools.futureverse.

    #parallel #futureverse

  3. Thank you #user2025 and everyone who participated and contributed to this amazing conference! It was great to see you all <3

    My first talk ever on #future was at useR! 2016, which I ended with a wish for a

    plan(future.p2p::cluster)

    backend. It took nine years to get there. My useR! 2025 slides on:

    Futureverse P2P: Peer-to-Peer Parallelization in R (Share compute among friends across the world)

    are available via futureverse.org/talks.html

    #RStats #parallel #futureverse

    photo by @schloerke

  4. The future package celebrates ten years on CRAN as of June 19, 2025. I just posted the second in a series of blog posts highlighting recent improvements to the #futureverse ecosystem:

    * Setting Future Plans in R Functions - and Why You Probably Shouldn't

    available at jottr.org/2025/06/25/with-plan/

    You can now do:

    my_fcn <- function(...) {
    with(plan(multisession), local = TRUE)
    ...
    }

    but, as explained in the post, I recommend not doing any that, unless really needed

    #RStats #parallel

  5. The future package celebrates ten years on CRAN as of June 19, 2025. I just posted the first of a series of blog posts highlighting recent improvements to the #futureverse ecosystem:

    * Future got better at finding global variables

    available at jottr.org/2025/06/23/future-go

    #RStats #parallel

  6. The future package turns ten today 🥳 To celebrate, I’ll start a blog series covering recent improvements that set us up for new, exciting ways for writing concurrent #RStats - neater than what our trusty workhorses future.apply & furrr offer

    jottr.org/2025/06/19/futurever

    #parallel #futureverse

  7. Liberating the future!

    I'm happy to share that major progress has been made on the #Futureverse roadmap. Already the next release comes with new, exciting, frequently asked features, and more are ready to ship in following release.

    Release candidate #1 of the 'future' package is now available on R-universe;

    install.packages("future", repos = c("futureverse.r-universe.dev", "cloud.r-project.org'))

    Please give it a try🙏 As usual, these updates should be 100% backward.

    #rstats #parallel

  8. If you're interested in discussing #parallel processing in #RStats at #PositConf2023, please let me know or reply here. I'm hoping we can have an informal hangout during Monday, Tuesday, or Wednesday to discuss what's missing, what's new and what's on the roadmap for parallelization in R. It doesn't have to be on just #Futureverse

    (I'll arrive late Sunday Sept 17 and leave early Thursday Sept 21)

  9. CLEANUP:

    The 'multiprocess' backend has finally been removed from the future package.

    If you get something like "Error: object 'multiprocess' is not exported by 'namespace:future'", please use plan(multisession) instead.

    It was deprecated in Oct 2020, it produced *lots* of annoying warnings since May 2022, it reverted to sequential processing in Feb 2023 with warnings, it became defunct in March 2023, and has now been removed.

    #RStats #parallel #futureverse

  10. Hey, I'm now recommending using %dofuture% instead of %dopar% when parallelizing with foreach(), e.g.

    library(doFuture)

    y <- foreach(x=X, .export="slow_fcn") %dofuture% {
    slow_fcn(x)
    }

    See jottr.org/2023/06/26/dofuture/ for why

    #RStats #parallel #futureverse

  11. doFuture 1.0.0 on CRAN with a new %dofuture% operator replacing %dopar%:

    y <- foreach(…) %dofuture% { … }

    Avoids the need for registerDoFuture(), avoids some %dopar% potholes, has built-in RNG support, and better error handling

    dofuture.futureverse.org/

    #RStats #futureverse #parallel

  12. Next version of doFuture starts taking shape. Can you spot what's new?

    library(doFuture)
    plan(multisession)

    y <- foreach(x = 1:4, y = 1:10) %dofuture% {
    z <- x + y
    slow_sqrt(z)
    }

    #RStats #parallel #futureverse

  13. @gdbassett
    Not built-in in #futureverse or the other #parallel frameworks/backends

    There have been different #RStats attempts/proof-of-concepts to provide such an "object", but AFAIK, nothing took off. It's a hard problem to solve robustly (race conditions & deadlocks) and be cross-platform

    A database engine is probably the most off-the-shelf solution, but not all of them support concurrent writes (e.g. don't know where file-based SQLite is on this)

    Always better to return values, if you can

  14. future 1.31.0 on CRAN. Mainly cleaning up legacy code blocking me from adding new, exciting features.

    Now, if you still rely on

    plan(multiprocess)

    , which has been deprecated since Oct 2020 (sic!), for parallelization, it'll now run in sequential mode, and you'll get heaps of deprecation warnings. If that doesn't do it, and you keep using 'multiprocess', I've got more aces up my sleeve. Just saying 🤠

    future.futureverse.org/

    #RStats #futureverse #parallel

  15. I'm working on an update to {doFuture} and a new %dofuture% infix operator:

    y <- foreach(x = 1:3) %dofuture% {
    something something
    }

    which removes the need for %dopar% (which btw comes with a few hidden bugs) and registerDoFuture().

    %dofuture% will give you a consistent #futureverse behavior, just like when you use {future.apply} and {furrr}. Same for random number generation (RNG), which will be built-in, so no need for %dorng%

    #RStats #parallel #HPC #RNG

    futureverse.org/