Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A step that runs seq2seq LMs in inference mode #119

Merged
merged 75 commits into from
Jan 20, 2022
Merged

A step that runs seq2seq LMs in inference mode #119

merged 75 commits into from
Jan 20, 2022

Conversation

dirkgr
Copy link
Member

@dirkgr dirkgr commented Dec 16, 2021

There is so much stuff in here, it's probably easiest to look at the changelog: https://github.com/allenai/tango/pull/119/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4ed

@dirkgr dirkgr self-assigned this Dec 16, 2021
examples/eval_p3/config.jsonnet Show resolved Hide resolved
@@ -0,0 +1 @@
rouge-score
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll need to add this requirement to dev-requirements.txt.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's helpful for CI so we can install everything with one command. For example, pip install -e [dev,examples]. Speaking of, it would be great to have tests for this example just like we have for the train_gpt2 example.

- name: GPT2 example
extras: dev,examples,datasets,torch
run: |
cd examples/train_gpt2
pytest -v --color=yes test.py

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I will switch this to torchmetrics. It's not a new dependency, because it's part of PTL. And as of today, it has Rouge.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

87bfc53

But, to make this work, I had to make "examples" into an integration. torchmetrics is installed with lightning, but I want to guarantee the correct version. Since 0.7.0 came out today, it does not yet get installed by default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does "examples" have to be an integration? Why not put this new dependency in dev-requirements.txt along with other dependencies for examples?

##################################################
###### Extra dev dependencies for examples #######
##################################################
transformers # needed by: examples

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put it there.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -114,3 +116,78 @@ def initialize_logging(
FILE_FRIENDLY_LOGGING = True
os.environ["FILE_FRIENDLY_LOGGING"] = "true"
click_logger.disabled = True


def logging_tqdm(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from our Tqdm wrapper with FILE_FRIENDLY_LOGGING on?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. You don't have to set an environment variable. It's always on.
  2. It does not redirect stderr in a dodgy way.
  3. Log messages get written to your logger, not the global "tqdm" logger.
  4. It does not depend on implementation details of the original tqdm.
  5. It is less code.

Copy link
Member

@epwalsh epwalsh Jan 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me rephrase. What I'm really asking is this: (A) why not implement this using our existing Tqdm wrapper, and (B) why have two separate approaches for file friendly progress bars?

For (A), your 2nd point is still valid, but your approach of implementing a new tqdm from scratch adds more code that looks fairly tricky. We should at least have some test coverage here.

But to emphasize (B) again, it seems like there is a lot of overlap in use-cases here for your logging_tqdm and the existing Tqdm wrapper with FILE_FRIENDLY_LOGGING on. I'd rather go with one or the other. Maybe our file-friendly version of the Tqdm wrapper uses your logging_tqdm code instead of tqdm internals.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to write tests for it, but only if we decide to actually use it.

I looked at our current usage of TQDM, and the only feature that logging_tqdm is missing is wrapattr(). There are a few others, but those only apply to rendering visual progress bars, so we don't have to care about them.

Overall I think logging_tqdm() is the superior solution, but there is a lot to do, and the success of Tango won't hinge on the quality of the progress bars. So I'll take this thing out and replace it with FILE_FRIENDLY_LOGGING.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

examples/eval_p3/eval.py Outdated Show resolved Hide resolved
tango/common/util.py Show resolved Hide resolved
@@ -153,3 +153,34 @@ def could_be_class_name(name: str) -> bool:

def _is_valid_python_name(name: str) -> bool:
return bool(name and name[0].isalpha() and name.isalnum())


def threaded_generator(g, queue_size: int = 16):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want this in the API docs you can import it in tango/common/__init__.py.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CHANGELOG.md Show resolved Hide resolved
@dirkgr dirkgr mentioned this pull request Jan 19, 2022
@dirkgr
Copy link
Member Author

dirkgr commented Jan 19, 2022

I think the last thing in here is the issue with how to select GPUs. I see how you did it in afade92. There, you made the evaluation step completely automatic, while the training step takes the device_count parameter. If we decide to do that here, this PR is done. Sound good @epwalsh?

@epwalsh
Copy link
Member

epwalsh commented Jan 19, 2022

There, you made the evaluation step completely automatic, while the training step takes the device_count parameter. If we decide to do that here, this PR is done. Sound good @epwalsh?

Yes, I mean, the only reason the TorchEvalStep doesn't take a device_count parameter at the moment is because it only works on a single device (for now).

@dirkgr
Copy link
Member Author

dirkgr commented Jan 19, 2022

Same is true for this step. But even if it could run on multiple devices, it would not alter the results. We could still put in a device_count parameter, but it would be a SKIP_ID parameter.

@dirkgr
Copy link
Member Author

dirkgr commented Jan 19, 2022

Is this good to go then?

@dirkgr
Copy link
Member Author

dirkgr commented Jan 19, 2022

Ah, I have to call resolve_device() as soon as #120 is merged.

Copy link
Member

@epwalsh epwalsh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeup, this looks good other than the merge conflicts and using resolve_device()

@dirkgr dirkgr merged commit df301ef into main Jan 20, 2022
@dirkgr dirkgr deleted the RunGeneration branch January 20, 2022 01:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants