[refactor] Make taichi/common self contained

[k-ye]

Related issue = #2196

The goal of this PR is to make taichi/common self-contained and not depend on any other part of the codebase. There are a few problems before:

1. Logger's impl used to be in taichi/util, this creates a circular include between taichi/common and taichi/util.

logging.cpp gets moved to taichi/common.

2. Logger itself is coupled with both signal handlers and pybind11.

Create a HackedSignalHandler, which takes care of these procedures in its constructor. We then instantiate a global HackedSignalHandler instead. The name "hacked" is mostly because I'm not sure if this is the best practice to invoke some initialization code in a shared library. There is a __attribute((constructor)) attribute, but it's a GCC specific extension..

3. Remove the global logger, and switches to the singleton Logger::get_instance(). This is because global variables in different translation units are unspecified.

[Click here for the format server]

---

[k-ye]

Sorry for the large change. This is mostly shuffling code around.

[yuanming-hu]

Looks great to me!

Btw, do you expect the compilation/linking time to also improve after this series of refactoring, given we re-compile fewer headers? If that is the case, does it makes sense to set up a quantitative build time benchmark? (so that we can tell a more precise and quantitative story to future developers? Something like "after Ye's refactoring not only the code is more readable but also the compilation time is improved by 20%" :-)

[yuanming-hu]

One more trap: the current build.py file only copies the libtaichi_core.pyd to the package. Before we release it may need fixing:

taichi/python/build.py

Lines 60 to 67 in dee35f4

	if get_os_name() == 'linux':
	shutil.copy('../build/libtaichi_core.so', 'taichi/lib/taichi_core.so')
	elif get_os_name() == 'osx':
	shutil.copy('../build/libtaichi_core.dylib',
	'taichi/lib/taichi_core.so')
	else:
	shutil.copy('../runtimes/RelWithDebInfo/taichi_core.dll',
	'taichi/lib/taichi_core.pyd')

[xumingkuan]

Looks great to me!

[xumingkuan]

Shall we write namespace taichi as-is or use this one?

taichi/taichi/common/core.h

Line 154 in dee35f4

#define TI_NAMESPACE_BEGIN namespace taichi {

[k-ye]

Yeah, I think both are fine. At some point we should do a batch change from TI_NAMESPACE_BEGIN to namespace taichi { anyway.. Do you have a preference?

[xumingkuan]

Yeah I also prefer namespace taichi {... It took me one more click in the IDE to know what TI_NAMESPACE_BEGIN was.

[k-ye]

Looks great to me!

Btw, do you expect the compilation/linking time to also improve after this series of refactoring, given we re-compile fewer headers? If that is the case, does it makes sense to set up a quantitative build time benchmark? (so that we can tell a more precise and quantitative story to future developers? Something like "after Ye's refactoring not only the code is more readable but also the compilation time is improved by 20%" :-)

LOL, TBH I haven't really looked to much into the compilation duration problem in Taichi. To me it was slow but not unbearable. I think it's great to have a build perf benchmark, but maybe not that urgent? Also we should confirm whether the slowness comes from compilation (parallelizable) or linking (single-threaded), or both.. If the reprocessing of the headers is a major source of slowness, maybe we can try things like https://clang.llvm.org/docs/PCHInternals.html#using-precompiled-headers-with-clang. Anyhow, compilation optimization itself is a huge topic... :)

[k-ye]

One more trap: the current build.py file only copies the libtaichi_core.pyd to the package. Before we release it may need fixing:

taichi/python/build.py

Lines 60 to 67 in dee35f4

	if get_os_name() == 'linux':
	shutil.copy('../build/libtaichi_core.so', 'taichi/lib/taichi_core.so')
	elif get_os_name() == 'osx':
	shutil.copy('../build/libtaichi_core.dylib',
	'taichi/lib/taichi_core.so')
	else:
	shutil.copy('../runtimes/RelWithDebInfo/taichi_core.dll',
	'taichi/lib/taichi_core.pyd')

Good point! But note that the newly added lib is what CMake calls an OBJECT library. IIUC, this is not a real static/shared library, but just a logical concept. Under the hood, it's just a bunch of .o files, which can then be included into other targets. See e.g. https://cmake.org/cmake/help/latest/command/add_library.html#object-libraries and https://gitlab.kitware.com/cmake/community/-/wikis/doc/tutorials/Object-Library

[yuanming-hu]

Looks great to me!
Btw, do you expect the compilation/linking time to also improve after this series of refactoring, given we re-compile fewer headers? If that is the case, does it makes sense to set up a quantitative build time benchmark? (so that we can tell a more precise and quantitative story to future developers? Something like "after Ye's refactoring not only the code is more readable but also the compilation time is improved by 20%" :-)

LOL, TBH I haven't really looked to much into the compilation duration problem in Taichi. To me it was slow but not unbearable. I think it's great to have a build perf benchmark, but maybe not that urgent? Also we should confirm whether the slowness comes from compilation (parallelizable) or linking (single-threaded), or both.. If the reprocessing of the headers is a major source of slowness, maybe we can try things like https://clang.llvm.org/docs/PCHInternals.html#using-precompiled-headers-with-clang. Anyhow, compilation optimization itself is a huge topic... :)

Sounds good. Improving compilation speed always makes development more enjoyable and make CI cost less but I agree with you that it is not urgent.

One more trap: the current build.py file only copies the libtaichi_core.pyd to the package. Before we release it may need fixing:

taichi/python/build.py

Lines 60 to 67 in dee35f4

	if get_os_name() == 'linux':
	shutil.copy('../build/libtaichi_core.so', 'taichi/lib/taichi_core.so')
	elif get_os_name() == 'osx':
	shutil.copy('../build/libtaichi_core.dylib',
	'taichi/lib/taichi_core.so')
	else:
	shutil.copy('../runtimes/RelWithDebInfo/taichi_core.dll',
	'taichi/lib/taichi_core.pyd')

Good point! But note that the newly added lib is what CMake calls an OBJECT library. IIUC, this is not a real static/shared library, but just a logical concept. Under the hood, it's just a bunch of .o files, which can then be included into other targets. See e.g. https://cmake.org/cmake/help/latest/command/add_library.html#object-libraries and https://gitlab.kitware.com/cmake/community/-/wikis/doc/tutorials/Object-Library

I see! I misunderstood. I thought an extra shared obj was created.