Update Numba to 0.57 by guilhermeleobas · Pull Request #538 · heavyai/rbc

guilhermeleobas · 2023-04-28T19:05:29Z

~~Array tests are currently broken~~ Fixed

guilhermeleobas · 2023-05-03T01:09:28Z

~~Pending conda-forge/numba-feedstock#115~~ Switched to use Numba channel

guilhermeleobas · 2023-05-09T19:32:24Z

Blocked on HeavyDB 7.0 release on conda-forge as Numba 0.57 uses LLVM 14.

guilhermeleobas · 2023-05-10T00:11:06Z

rbc/irtools.py

+    # check LLVM version before compiling to LLVM
+    server_llvm_version = target_info.llvm_version
+    client_llvm_version = llvm.llvm_version_info
+
+    if (server_llvm_version[0], client_llvm_version[0]) == (11, 14):
+        c_llvm = '.'.join(map(str, client_llvm_version))
+        s_llvm = '.'.join(map(str, server_llvm_version))
+        flag = 'RBC_DISABLE_LLVM_MISMATCH_ERROR'
+        msg = (f'The client LLVM version ({c_llvm}) is greater than the server '
+               f'LLVM version ({s_llvm}). This is known to be unsupported. '
+               'Please, downgrade to a previous release of Numba that uses the '
+               'same LLVM version as the HeavyDB server. For more information, '
+               'see the table below:\n\n'
+               'https://github.com/numba/llvmlite#compatibility\n'
+               'https://github.com/heavyai/heavydb#dependencies\n\n'
+               f'To disable this error, run RBC with {flag}=1 flag enabled.')
+
+        DISABLE_LLVM_MISMATCH_ERROR = int(os.environ.get(flag, False))
+        if not DISABLE_LLVM_MISMATCH_ERROR:
+            raise LLVMVersionMismatchError(msg)


Would this be the most appropriated place to put this check?

Could you create a utility function that processes the llvm version mismatches?

I am not sure if raising an exception is an appropriate measure for avoiding possible problems from llvm version mismatches. We have had these mismatches in the past all the time and typically the mismatch of versions is not a problem except for certain use cases. The LLVM 11 vs llvmlite LLVM 14 is the first case where the problem is fatal for most cases (because llvm 14 generates LLVM IR containing features (attributes) that llvm 11 parser does not know how to handle, and even here we can implement a workaround). Here, in the case of 11 vs 14, raising an exception from rbc side is reasonable indeed but for the other cases, I think submitting a warning message with detailed instructions should be sufficient.

The llvm version check should be of the only-once kind and it could be carried out when rbc establishes the connection to the heavydb server. Checking it every time in compile_to_LLVM would be too much indeed.

Okay, I can change that. We only check for the LLVM 11/14 combination, which is known to be problematic.

environment.yml

pearu · 2023-05-10T07:46:28Z

rbc/irtools.py

+    # check LLVM version before compiling to LLVM
+    server_llvm_version = target_info.llvm_version
+    client_llvm_version = llvm.llvm_version_info
+
+    if (server_llvm_version[0], client_llvm_version[0]) == (11, 14):
+        c_llvm = '.'.join(map(str, client_llvm_version))
+        s_llvm = '.'.join(map(str, server_llvm_version))
+        flag = 'RBC_DISABLE_LLVM_MISMATCH_ERROR'
+        msg = (f'The client LLVM version ({c_llvm}) is greater than the server '
+               f'LLVM version ({s_llvm}). This is known to be unsupported. '
+               'Please, downgrade to a previous release of Numba that uses the '
+               'same LLVM version as the HeavyDB server. For more information, '
+               'see the table below:\n\n'
+               'https://github.com/numba/llvmlite#compatibility\n'
+               'https://github.com/heavyai/heavydb#dependencies\n\n'
+               f'To disable this error, run RBC with {flag}=1 flag enabled.')
+
+        DISABLE_LLVM_MISMATCH_ERROR = int(os.environ.get(flag, False))
+        if not DISABLE_LLVM_MISMATCH_ERROR:
+            raise LLVMVersionMismatchError(msg)


Could you create a utility function that processes the llvm version mismatches?

I am not sure if raising an exception is an appropriate measure for avoiding possible problems from llvm version mismatches. We have had these mismatches in the past all the time and typically the mismatch of versions is not a problem except for certain use cases. The LLVM 11 vs llvmlite LLVM 14 is the first case where the problem is fatal for most cases (because llvm 14 generates LLVM IR containing features (attributes) that llvm 11 parser does not know how to handle, and even here we can implement a workaround). Here, in the case of 11 vs 14, raising an exception from rbc side is reasonable indeed but for the other cases, I think submitting a warning message with detailed instructions should be sufficient.

The llvm version check should be of the only-once kind and it could be carried out when rbc establishes the connection to the heavydb server. Checking it every time in compile_to_LLVM would be too much indeed.

.github/workflows/rbc_test.yml

pearu

@guilhermeleobas since we don't know when heavydb 7 will be release (so merging this PR is blocked), could you move the alloc releated fixes to a separate PR that can be landed earlier?

rbc/heavydb/array.py

rbc/heavydb/buffer.py

rbc/heavydb/text_encoding_none.py

pearu

I have a couple of suggestions, otherwise looks good!
Thanks, @guilhermeleobas!

rbc/irtools.py

doc/envvars.rst

pearu · 2023-06-01T09:51:59Z

rbc/heavydb/remoteheavydb.py

+                s_llvm = '.'.join(map(str, server_llvm_version))
+                msg = (
+                    f'The client LLVM version ({c_llvm}) is greater than the server '
+                    f'LLVM version ({s_llvm}). This is known to be unsupported. '


With #551, I believe this statement has become out-of-date. Could you rephrase the message along the lines of "If you experience any issues that could be due to the discrepancy of LLVM versions, please try to downgrade/update Numba that uses LLVM version ({s_llvm}).". Also, this statement can be generalized to all LLVM version combinations, not just (11, 14).

I now see that the purpose is to warn only about the problematic LLVM version combinations. Since 11 and 14 are not problematic anymore, this function is essentially a no-op? What do you think?

In fact, the combination of 14 and 11 might be more problematic as a newer client-side LLVM version may use features (such as LLVM attributes or similar) that the server LLVM IR parser cannot handle.

pearu · 2023-06-01T09:56:11Z

rbc/heavydb/remoteheavydb.py

+        # check LLVM version before compiling to LLVM
+        flag_name = 'RBC_DISABLE_LLVM_MISMATCH_WARN'
+        flag = int(os.environ.get(flag_name, False))
+


We should check the LLVM version and possibly warn only once. One possible approach is as follows:

Suggested change

os.environ[flag_name] = 1

…eplace llvm alloca by allocate_varlen_buffer

…ate-numba

guilhermeleobas added the enhancement New feature or request label Apr 28, 2023

guilhermeleobas self-assigned this Apr 28, 2023

guilhermeleobas force-pushed the guilhermeleobas/update-numba branch from f027248 to 1e31af4 Compare May 3, 2023 00:16

guilhermeleobas force-pushed the guilhermeleobas/update-numba branch 2 times, most recently from 5078638 to 50fc2f2 Compare May 9, 2023 19:01

guilhermeleobas added the blocked Blocked label May 9, 2023

guilhermeleobas mentioned this pull request May 9, 2023

Attempt to fix LLVM version mismatch #539

Closed

guilhermeleobas commented May 10, 2023

View reviewed changes

pearu suggested changes May 10, 2023

View reviewed changes

guilhermeleobas marked this pull request as ready for review May 10, 2023 15:34

pearu suggested changes May 12, 2023

View reviewed changes

rbc/heavydb/array.py Show resolved Hide resolved

rbc/heavydb/buffer.py Show resolved Hide resolved

rbc/heavydb/text_encoding_none.py Show resolved Hide resolved

guilhermeleobas mentioned this pull request May 12, 2023

Replace "builder.alloca" by "allocate_varlen_buffer" #546

Merged

guilhermeleobas force-pushed the guilhermeleobas/update-numba branch from 31d82dd to 958678c Compare May 12, 2023 16:43

guilhermeleobas force-pushed the guilhermeleobas/update-numba branch from e9f6eab to 17f2e70 Compare May 23, 2023 02:16

pearu suggested changes Jun 1, 2023

View reviewed changes

guilhermeleobas and others added 13 commits June 12, 2023 12:12

Update Numba to 0.57

2abf0d5

Fix a bug where returned structs were being allocated on the stack. R…

84d2ca2

…eplace llvm alloca by allocate_varlen_buffer

undo changes

be0833d

Install llvm-14 with Numba 0.57 and llvm 11 with Numba 0.56

f88caea

exclude numba 0.56 / python 3.11 from the matrix

738da48

refactor matrix

157a97c

fix rbc_test.yaml

048a921

attempt to install numba from numba channel

b7286cb

add numba channel

700e953

replace strict priority by flexible

935bebf

remove features

2f01d50

raise error on LLVM version mismatch

8a47435

add test for numba/heavydb llvm mismatch

3648591

guilhermeleobas added 13 commits June 12, 2023 12:12

add CI job for LLVM mismatch

ea6f679

flake8

30b550e

retrieve target info from heavydb.targets

bdcf176

add llvm_version to remote jit target info

31ab121

use string quotes to specify python version

40b5d75

undo change

5337fe1

document DISABLE_LLVM_MISMATCH_ERROR on envvars.rst

4717732

replace exception by warning

11fe42a

update test and environment.yml

1f73a5c

isort

6c8ee44

add heavyai 7.0.0 from docker

a910461

address reviewer comments

3f12d8f

flake8

89f1b2f

guilhermeleobas force-pushed the guilhermeleobas/update-numba branch from f95190a to 89f1b2f Compare June 12, 2023 15:12

Merge remote-tracking branch 'upstream/main' into guilhermeleobas/upd…

c3fd246

…ate-numba

Conversation

guilhermeleobas commented Apr 28, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

guilhermeleobas commented May 3, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

guilhermeleobas commented May 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

guilhermeleobas May 10, 2023

Choose a reason for hiding this comment

Uh oh!

pearu May 10, 2023

Choose a reason for hiding this comment

Uh oh!

guilhermeleobas May 10, 2023

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pearu May 10, 2023

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pearu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pearu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

pearu Jun 1, 2023

Choose a reason for hiding this comment

Uh oh!

pearu Jun 1, 2023

Choose a reason for hiding this comment

Uh oh!

pearu Jun 1, 2023

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

guilhermeleobas commented Apr 28, 2023 •

edited

Loading

guilhermeleobas commented May 3, 2023 •

edited

Loading

guilhermeleobas commented May 9, 2023 •

edited

Loading