Dear IPMC:
I am sending this email to let you know that the Apache (incubating) TVM
community started a formal RFC for our first apache release.
Because this is our first ASF release, the community wanted to hold the
release to the highest standard possible, by starting an RFC to ask
everyone to
Dear Community,
This is an RFC for verifying whether v0.6.0rc0 is good to go. The release
candidate (release note, artifact and source code) can be find
[here](https://github.com/apache/incubator-tvm/releases/tag/0.6.0.rc0)
This is **not** an official vote. Please help us verifying,
* Incubati
> Hi @yangjunpro @hello-hzb ,
> This project has been suspended for several months. I won't continue my work
> on the original branch.
> However, the push for an auto-scheduler is still interesting to a lot of
> people. I might work on auto-scheduler again with some Berkeley students.
> We'd lik
To address @u99127 's concern, we could add an optional runtime_raw field. Note
we may not necessarily be able to get accurate measurement of exact runs, as
cases like GPU executions needs async execution and average over multiple runs,
so the statistics will be wrt to the number runs instead of
@tmoreau89 - I lean more towards storing the list of raw measurements.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4304#issuecomment-557749626
@u99127 do you lean more towards storing the list of measurements (e.g. over 10
runs) and letting the user implement their aggregation function? Or list
multiple ones? Or just agree to standardize towards one (e.g. mean).
--
You are receiving this because you are subscribed to this thread.
Repl
Thanks @tqchen , Ok, now the term "engine" makes sense.
My experience has been different. Some prefer median over mean, others min /
max and some other a geometric mean.
regards
Ramana
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
re @u99127 's comment about raw statistics, given that some executions have to
be run over multiple iterations to get a meaningful measurement, individual run
stats may not be as meaningful and accurate. We can still provide a runtime_raw
array which might be useful for future statistics calcula
After looking at the schema for a bit. I feel that it would be helpful to
categorize things into two categories:
- timestamp, schema, workload, engine, hardware, runtime_ms_mean,
runtime_ms_std (I think the runtime_mean_ms and std are important enough for
most cases that should be bought into
To pick up on a couple of topics from the Pull Request.
1. I've found that keeping the raw data allows one to process it in other ways
in terms of { iteration: 1 runtime: } instead of only storing the
statistics ?
Different folks would want to do different statistics with the data and we
Reopened #4403.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4403#event-2824935991
Closed #4403.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4403#event-2824935908
> Interesting, cc @nhynes regarding rust interface.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4403#issuecomment-557739982
> rust interface
The rust interface is currently only that of a TVM runtime, but that's
sufficient since the kernels are already memory safe. For maximum safety (but
slightly less flexibility from dynamic linking), one would use the
[non-bindings] runtime in `rust/runtime`. At least until TVM e
Interesting, cc @nhynes regarding rust interface.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4403#issuecomment-557733313
Cool, thanks @tqchen
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4304#issuecomment-557732023
To clarify, by in-complete i mean the three fields(model, engine, and hardware)
are incomplete. The additional information(engine_config, version,
runtime_config) are meant to fill in that gap and provide a complete
information.
--
You are receiving this because you are subscribed to this thre
>
>
> I think docker_tag under metadata as long as it is optional (the RFC said the
> field was required which confuses me).
>
> There are certainly cases when people want to limit the number of threads,
> e.g. use only the little cores on the phone to save power. While these could
> have bee
That's a sound argument; we should keep runtime config for the
`num_cpu_threads` then to store information on non-hardware, and non-software
metadata
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache
I think docker_tag under metadata as long as it is optional (the RFC said the
field was required which confuses me).
There are certainly cases when people want to limit the number of threads, e.g.
use only the little cores on the phone to save power. While these could have
been a nested field i
@tqchen `docker_tag` is under metadata; therefore it's mostly seen as optional
(and is here for example purposes)
Indeed `num_cpu_threads` is a tricky one and I thought long and hard about
this; it makes sense not to place it under `software_config`, and instead could
be considered a `hardware`
Some further comments wrt to the recently hardware_config change
- I still think it is important to keep the ```runtime_config```, which
includes fields like ```num_cpu_threads```. Now that software config mainly
specifies the environment dependencies, maybe it makes sense to move
num_cpu_threa
Some story
When I was writing Libra and it’s followup, @merrymercy come and asks “why are
you implementing this with a handwritten AVX2 code? It’s already the year 9012!
Try tvm instead.”
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view i
Significant progress has been made during recent years due to the development
of blockchain. However, these cryptography protocols are hard to implement
correctly and even more hard to parallelize. A lot of them can be efficiently
parallelized, and I will list some of them later. It shares a da
markdown has been updated to reflect removal of `runtime_config`.
`num_cpu_threads` can be optionally specified in `hardware_config`, which is
optionally json. Optional placement of `cudnn` and `cuda_driver` has been moved
to `software_config`.
`md5` has been added to `workload_metadata`
The
Other than that looks great 👍
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4304#issuecomment-557640388
And if possible the addition of an `md5` field under `workload_metadata` to
attest the integrity of the model.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4304#issuecomment-
@anwang2009 I'd like to suggest one last modification: the removal of the
`runtime_config` since many of the fields overlap with the `software_config`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apac
sounds good
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4259#issuecomment-557634947
@tqchen RFC after tag?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/4259#issuecomment-557630301
FYI, the common checklist used for release
- Incubating in name
- DISCLAIMER exists
- LICENSE and NOTICE are fine
- No unexpected binary files
- Checked PGP signatures
- Checked Checksums
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
@yzhliu can we start a RFC thread before vote on dev@? just like a discuss
thread that we can get feedbacks, before we open a vote, we can also invite ASF
mentors to help check
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
32 matches
Mail list logo
