Introduce a real logging library

[joelsmithTT]

Issue

Follow on from #176
#160
#140

Description

• Adds a real logging library spdlog to replace the homegrown logger.hpp
• Lazy initializes
• Supports logging to console (stderr) and/or disk
• Not integrated yet (does not yet replace logger.hpp) -- want feedback from the team prior to replacing existing log statements

List of the changes

• Introduces new logging API
• Adds tests and performance characterization code

Testing

• Unit tests

API Changes

There are no public API changes in this PR.

[pjanevskiTT]

Nice changes in general. I don't have strong opinions on what logger we are using, I just have 3 things that I would like to see in order to consider this as an improvement or at least not a regression

• Consistency across repos
• Logging performance
• Build performance

I have left separate comments for all of this in the review, so we can discuss it in a thread. Let me know how those sound to you

[pjanevskiTT]

One more thing I forgot to mention that would be extremely nice to have is env variable to control the level of log that is supported. Basically just control the Option for logging level

[blozano-tt]

One more thing I forgot to mention that would be extremely nice to have is env variable to control the level of log that is supported. Basically just control the Option for logging level

IE something that a logging library would give us for free?

https://github.com/gabime/spdlog/blob/v1.x/include/spdlog/cfg/env.h

[pjanevskiTT]

Looks good, I think we should just ping someone from tt-metal and other repos that are using existing logger to weigh in on this as well. @blozano-tt you have worked cross-repos the most from us, maybe you could do it?

[joelsmithTT]

For cross-project consistency, there's a design decision around log identification.
current behavior in this implementation is:
[2024-11-14 11:00:48.045] [info] [test_logger.cpp:184] Test message

If this becomes a shared solution across projects, we'd want to distinguish the source:
[2024-11-14 11:00:48.045] [UMD] [info] [test_logger.cpp:184] Test message
[2024-11-14 11:00:48.045] [METAL] [info] [somewhere_else.cpp:123] Other message

This would affect macro naming/use and initialization.

I suggest we focus on establishing robust logging into UMD first -- this will directly improve UMD developer experience by:

• eliminating conditional compilation affecting UMD logger behavior
• providing compile-time checks for string formatting in log messages
• showing source location in log messages

Later on, after we've lived with the spdlog for a while and have had opportunity to adjust how we are using it -- then consider how to achieve consistency across projects. Thoughts?

[broskoTT]

Seems like we'll feel benefits by using external well established logging library.
As long as this is not going in some opposite direction (which doesn't seem like it is the case) to other repos, I'm all for it.

[blozano-tt]

Yayy! Thanks @joelsmithTT !