Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

Decouple the conv data format from the input feature layout #974

Open
tommadams opened this issue Mar 12, 2020 · 8 comments
Open

Decouple the conv data format from the input feature layout #974

tommadams opened this issue Mar 12, 2020 · 8 comments

Comments

@tommadams
Copy link
Contributor

On the one hand, it's more efficient for the CPU to generate NCHW input features.
On the other, TensorFlow supports NHWC convolutions on a wider variety of platforms.

When I added support for NHWC, I coupled the conv data format to the input feature layout.

We should add another option to support different tensor layouts for input features and convolutions, inserting transpose operations as necessary.

@brilee
Copy link
Contributor

brilee commented Mar 12, 2020 via email

@tommadams
Copy link
Contributor Author

TPU apparently doesn't support NCHW conv at all...

@SHKD13
Copy link

SHKD13 commented Mar 12, 2020

Is it purely theoretical topic or the part of MiniGo v18 building process?

@tommadams
Copy link
Contributor Author

This is more for MLPerf, which uses smaller models and has a much higher CPU:GPU compute load than a regular Minigo run.

@SHKD13
Copy link

SHKD13 commented Mar 13, 2020

MLPerf is a kind of a "lab", where you can try some algorithm's changes and improvements on a smaller Networks before implement it for a regular full sized run? Sorry, if I get something wrong :)

@tommadams
Copy link
Contributor Author

MLPerf is a suite of machine learning benchmarks that many major tech companies collaborate on. Minigo is the reinforcement learning benchmark for MLPerf.

@tommadams
Copy link
Contributor Author

See https://github.com/tensorflow/minigo/tree/master/ml_perf for the implementation. It's basically a smaller & simplified version of the full pipeline

@SHKD13
Copy link

SHKD13 commented Mar 13, 2020

Thanks for clarification and links! Now I can see that I didn't know about the MLPerf background of MiniGo.
I thought, MG is enthusiastic and independent Go project like LZ or KataGo. But missed the point about something bigger behind, which drives the MiniGo team

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants