On leg 2 of my winter break journey across the US, I made a prototype of a new LLVM code generator using llvm-rs. Three major changes:

1. Code generation through builders. Instead of generating LLVM code strings, builders provide a more type-safe (both at compile time and runtime) and concise means of creating an IR.
2. New code execution runtime. The llvm-rs JitEngine is pretty comparable to what's already implemented in easy_ll, except it integrates well with the code builders instead of relying on a string intermediary.
3. Revamped the REPL to actually produce output and use a command line parser.

1. Removes the make commands from build.rs that were used to build the convertor dylib.
2. Change the package name grizzly to pygrizzly
3. Added a binary extension for libweld in pyweld/setup.py which somehow allowed auditwheel to stop complaining about libweld.so being part of the python wheel. I could run auditwheel successfully and it changed the platform tag which allowed me to upload to pypi.

Am attempting in baloo to encode strings to Weld for e.g. sr[sr != 'abc'] to work, however there seems to be a bug somewhere. Are vec[i8] <comparison> vec[i8] expected to work correctly at the Weld level?

For example:

// _inp2 here is the index associated with the _inp0 strings data
|_inp0: vec[vec[i8]], _inp1: vec[i8], _inp2: vec[i64]| let obj100 = (_inp0);
let obj101 = (map(
    obj100,
    |a: vec[i8]| 
        a != _inp1
));
result(
    for(
        zip(_inp2, obj101),
        appender[i64],
        |b: appender[i64], i: i64, e: {i64, bool}| 
            if (e.$1, 
                merge(b, e.$0), 
                b)
    )
)

This only seems to work when _inp1 is of length 1. So for:

sr = Series(np.array(['abc', 'Burgermeister', 'b'], dtype=np.bytes_))
sr[sr != 'b']  # will correctly return the first 2 elements
sr[sr != 'abc']  # does not; (returns all elements)

The most likely culprit is the encoding with Python3. The only changes I made are essentially moving from PyString_AsString and PyString_Size to the PyBytes_* equivalents (in the .cpp file) and encoding the str to utf-8, e.g. abc.encode('utf-8') (in the encoders.py file):

extern "C"
weld::vec<uint8_t> str_to_weld_char_arr(PyObject* in) {
  int64_t dimension = (int64_t) PyBytes_Size(in);
  weld::vec<uint8_t> t;
  t.size = dimension;
  t.ptr = (uint8_t*) PyBytes_AsString(in);
  return t;
}

...
if isinstance(obj, str):
        numpy_to_weld = self.utils.str_to_weld_char_arr
        numpy_to_weld.restype = WeldVec(WeldChar()).ctype_class
        numpy_to_weld.argtypes = [py_object]

        return numpy_to_weld(obj.encode('utf-8'))

Note that

1. En-/decoding numpy arrays of bytes works fine with the grizzly encoders (and using PyBytes_FromStringAndSize instead of PyString_FromStringAndSize).
2. Also toyed around with modifying WeldChar.ctype_class to c_char_p as opposed to c_wchar_p which seemed more appropriate yet produces the same result.
3. Encoding as ascii would probably be more appropriate, since Weld can't handle unicode from what I can tell. Nevertheless, the tested data is ascii.
4. This is with the master branch Weld.

Any feedback/idea on what the issue might be?

@sppalkia: just as an FYI, not ready to merge.

Major issues right now:

• Some benchmarks don't yet work correctly
• Encoder / decoder much slower than C++ encoder / decoder

Fixes #473 when using Weld with an LLVM 6.0 distribution that has LLVM_ENABLE_ASSERTIONS enabled.

Also fixes some README issues.

The issue was that some places in the code generation used an i64 0 literal as a substitute for null, which was okay with LLVM's module verifier but caused certain debug assertions to complain.

System: Ubuntu 16.04 Rust: stable-x86_64-unknown-linux-gnu (1.28.0)

I can successfully compile the Weld library. I write client application with Rust. Similar to the example application at https://www.weld.rs/docs/weld/, it is

extern crate weld;

use weld::*;

#[repr(C)]
struct MyArgs {
    a: i32,
    b: i32,
}

fn main() {
    set_log_level(WeldLogLevel::Trace);
    let code = "|a: i32, b: i32| a + b";
    let ref mut conf = WeldConf::new();
    conf.set("weld.compile.dumpCode", "true");
    conf.set("weld.compile.dumpCodeDir", "/tmp");
    let mut module = WeldModule::compile(code, conf).unwrap();

    // Weld accept packed C structs as an argument.
    let ref args = MyArgs { a: 1, b: 50 };
    let ref input = WeldValue::new_from_data(args as *const _ as Data);

    // Running a Weld module and reading a value out of it is unsafe!
    unsafe {
        // Run the module, which returns a wrapper `WeldValue`.
        let result = module.run(conf, input).unwrap();
        // The data is just a pointer: cast it to the expected type
        let data = result.data() as *const i32;

        let result = (*data).clone();
        assert_eq!(args.a + args.b, result);
    }
}

However, the program terminated with the following output

[debug] 23:56:48.124: Started compiling LLVM
[debug] 23:56:48.124: Done creating LLVM context
[debug] 23:56:48.124: Done parsing module
[debug] 23:56:48.124: Done parsing bytecode file
[debug] 23:56:48.125: Done linking bytecode file
[debug] 23:56:48.125: Done validating module
[debug] 23:56:48.128: Done optimizing module
[debug] 23:56:48.128: Done creating execution engine
[debug] 23:56:48.128: Before Calling FindFunction
LLVM ERROR: Program used external function 'weld_rt_get_run_id' which could not be resolved!

I try to investigate into Weld source code, and find that it called llvm::execution_engine::LLVMGetFunctionAddress and it is LLVM that terminates the whole program forcefully. What's going wrong?

This implements sequential loops using the iterate(initial_value, update_func) construct, where initial_value is of some type T and update_func is of type T => {T, bool}. It works the same way as the sequential loop in NVL. We call update_func repeatedly on values starting from initial_value and stop when the bool it returns is false. Then the final value of the expression is the last T it produced.

I made this work slightly differently if the loop body is sequential vs parallel: in the sequential case, it just adds basic blocks in the current function, while in the parallel case, it adds new functions for the continuation, etc. This is the same way If generates code.

Modifying the Weld program here https://github.com/weld-project/weld/blob/b6ef6748cec3f2740032df164fbeff0aeb0b236a/examples/cpp/udfs_from_library/udfs.cpp#L24 into |x:i64| cudf[add_five,i64](x) + cudf[add_five,i64](x) returns the expected result (2*x + 10) but only calls add_five once.

The main structural changes involves adding a new kind, NdIter, to IterKind: pub enum IterKind { ScalarIter, // A standard scalar iterator. SimdIter, // A vector iterator. FringeIter, // A fringe iterator, handling the fringe of a vector iter. NdIter, // multi-dimensional nd-iter }

and a couple of fields relevant to NdIter in struct Iter, and struct ParallelForIter, e.g,: pub struct ParallelForIter { pub data: Symbol, pub start: Option, pub end: Option, pub stride: Option, pub kind: IterKind, // NdIter specific fields pub strides: Option, pub shapes: Option, }

The code follows the same path as for other IterKinds, and the main changes are in the code to generate the index of the next element in llvm.rs (gen_loop_iteration_start, and gen_loop_iteration_end). And changing the bounds/num_iterations based on the shapes parameter also in llvm.rs (gen_loop_bounds_check, and gen_num_iters_and_fringe_start).

Besides this, I added a struct in llvm.rs (not sure if this was the best place for this?): pub struct VecLLVMInfo { pub ty_str: String, pub arr_str: String, pub prefix: String, pub len_str: String, pub el_ty_str: String, } which was useful for many of the llvm routines I had.

I have only added two tests for it (testing with zip, and a basic op (log)), but I did test it further using the numpy API where it was more natural as I could compare different outputs of non-contig arrays with results numpy produces. Here, I had a simple case that simulates a non-contiguous array using a 1-d rust array.

One issue that still remains is how to set the size of the array correctly: right now it is being done in transforms.rs --> infer_size using the formula: len = end-start / stride; Instead, the new formula should be shapes[0]shapes[1]...*shapes[n-1], but I wasn't sure how to emit weld code for this using exprs...in weld it should be something like:

for(shapes, merger[i64, *], |b, i, e| merge(b, e));

And using exprs, as in infer_size, I thought it would be something like: let b = exprs::newbuilder_expr(Merger(Scalar(I64), BinOpKind::Multiply))?; let m = exprs::merge_expr(b, ???); exprs::for_expr(iters[0].data.clone(), b, m, false)?

but I wasn't sure how to do the merge_expr --> in weld code I guess we have access to element "e", but how do we get it here?

If this is resolved, then we won't need to pass in "end", and "stride" to nditer. So far, I was just using stride=1, and end = start + real_len, which is functionally correct, but adds too many parameters to nditer...

1. increase outer loop grain size to 4096
2. eliminate bounds checks for simple single-iter (no explicit start and end) cases
3. minimize thread ID retrievals
4. local stack-based mergers with lazy creation of global mergers

performance on a worst-case loop like this

merger[+] m
for v in vs {
  merger[+] n
  for e in v { // only one iteration
    merge(n, e)
  }
  merge(m, result(n))
}
result(m)

is still 4x off the C version ... used to be 500x though

Compile times may have gone up ... tests seem to take a bit longer to run. @mateiz maybe you can measure this?

weld_module_free and weld_module_mem_free are now used to free memory (they free all memory allocated by the module, which is what weld_value_free did before), and weld_module_memory_usage is used to determine a module's total memory usage. weld_value_free and weld_value_memory_usage now do nothing. I think we should implement these later once we figure out how to correctly free and determine the memory usage of a single value.

Hello,

I tried to run "movielens_grizzly.py" but I got the following error:

weld_type = grizzly_impl.numpy_to_weld_type_mapping[dtype] KeyError: '|S1'

Is this a known issue?

Thanks in advance.

Bumps numpy from 1.18.1 to 1.22.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello,

I want to implement the grizzly_impl.unique() function using weld-capi.

After looking at the grizzly_impl.py code I found out that this is the code for unique()

map(
         tovec(
           result(
             for(
               map(
                 obj_id,
                 |p: vec[i8]| {p,0}
               ),
               dictmerger[vec[i8],i32,+],
               |b, i, e| merge(b,e)
             )
           )
         ),
         |p: {vec[i8], i32}| p.$0
       )

However, obj_id is retrieved during runtime and I do not know how to do what using weld-capi. Basically my question is how to write a unique() function using weld-ir that can be compiled and called using weld-capi.

Thanks in advance!

I am trying to run a UDF pipeline on a dataset using Weld (or grizzly, I suppose).

Grizzly, however, (as far as I know) does not offer an optimized function to apply for example a scalar UDF on a specific column of the dataset.

I found that one way to do it is to access the internal data using to_pandas() which has a function called “apply” and use this function to run a Python UDF on a column.

The problem is that I want to measure Weld’s performance on UDFs and by accessing the internal data and applying the functions just like a normal python program would do is not a fair way to measure Weld’s performance regarding (Python) UDF execution.

How can I apply a python UDF on a column of the dataset in an optimized way using Weld?

Thanks in advance!

When I try to build the example udfs and run it , I got error: LLVM ERROR: Program used external function 'add_five' which could not be resolved! I figure that should be lack the -rdynamic in the gcc flags. I want to submit a PR to fix that. But I found that still exist 2 unmerge PR. I want to know who is maintaining this project and what is the PR standard?