How to make EvoTrees.jl more performant?

General Usage Performance
#7

There is a version of the code you are running here, which also includes a set of environment files Project.tom and Manifest.toml, for reproducing the same environment. (If you just run the script there as is, in the same folder as these files, it should use that environment automatically). I’m unable to reproduce your problems with that script/env. I also updated the environment there with using Pkg.update() and again, no problems. In this case I have these versions installed:

Pkg.status()
      Status `~/Google Drive/Julia/MLJ/MLJ/examples/lightning_tour/Project.toml`
  [f6006082] EvoTrees v0.8.3
  [98b081ad] Literate v2.9.1
  [add582a8] MLJ v0.16.7
  [614be32b] MLJIteration v0.3.1

Does this match your status?

Also, is your stack trace complete? It does not appear to be.

BTW, You may want to drop the acceleration=... option to simplify diagnosis.

#8

Hello Dr. Blaom:

The full log reads:

image
image887×553 41.1 KB

Currently testing without the acceleration parameter and different
workspace combinations. Will post results soon.

#9

Hello: This is the full error log:

image
image1438×1544 156 KB

1 Like
#10

Can you please report the output of using Pkg; Pkg.status()?

#11

From the REPL or with in a Pluto process?

#12

should they be the same? wherever you’re running this. The point is to know the versions of packages that lead you to this error

#14

@ablaom and @jling

First,
image

Second,
image

Third,
image
image

Fourth: I resolved the packages

Fifth: I instantiated all the changes

#15

EvoTrees is not the only package in play here is it? Are you not using MLJ? Please list all the package versions

#16

Also note that if you use the current Pluto version, the package versions in your notebook might be different from those in your default (or any other) environment, as Pluto’s built-in package manager will create a notebook-specific environment once you put using somewhere in your notebook.

#17

not confusing at all… yeah

#18

I think it’s nice for reproducibility and mitigates compat issues especially for new users which might not use environments otherwise, but I agree it can be surprising for people that do ] st or other package operations in the REPL to find that they have no effect on the code in their notebooks…

More details here: 🎁 Package management · fonsp/Pluto.jl Wiki · GitHub

1 Like
#19

image

image

image

image

image

#20

By the way, it’s usually more convenient if you can copy and paste code snippets into code blocks, rather than posting screenshots. See here for more info:

2 Likes
#21

Thanks Cameron.

The original post had the format that was convenient for you.
The follow-up posts had screen shots simply for QA not
reproducibility.

#22

Ok, well I still think that printed output and stacktraces are easier to read when they are in code blocks than when they are presented as screenshots. :slight_smile:

2 Likes
#23

Noted. Thank you for the resource
and I will consider this for future
posts.

#24

Don’t

pkg> resolve

and

pkg> instantiate

mitigate potential package
versioning issues?

#25

No, I think you misunderstood my point. Any command you type after pkg> is run in the environment pkg, and therefore will not affect the Pluto notebook, which generates its own environment. E.g. if you did

pkg> add DataFrames@1.0

in the REPL, then

julia> using Pluto; Pluto.run()

and then put

using DataFrames

at the top of your notebook, Pluto will automatically install the latest DataFrames version (1.2) in your notebook environment, and you will be using that version in the notebook, not the version in your pkg environment from which you started Pluto.

#26

Okay – thanks for clarifying.

So there is no benefit to adding
the packages in the REPL if one
is using Pluto and calling the
packages with ‘using ’?

#27

Correct. You can do using Pkg, Pkg.activate("/path/to/pkg") in your Pluto notebook to manage your own environment and disable Pluto’s built-in package manager, but if you don’t do that there’s no point doing any package operations in the REPL prior to starting Pluto (except for changing the version of Pluto itself, obviously).