How to load and read the .params in big endian system?

:smile:

we need to make the tool, I could make one may be by tomorrow.
I don’t have a big endian environment to check now. I will share it and you can help to verify.

Hope it’s ‘float32’ all across the model you are using, pls confirm.

Just changing compiler flags doesn’t do the job for us. We need to add the data conversion logic while save params.

Many thanks for your assistant!!!

The model was generated under generation guidance and deployed under deploy steps with the default opinion, i didn’t change them. So I think it keeps ‘float32’ all the time.

Back to the second way, you said

need to add the data conversion logic while save params

Does it mean I should add some functions (guess just like htol or ltoh) to convert the data in my code and then compile it?

Thanks a lot.

I wonder how it pass the execution (even with wrong result) only by changing above macros.

Params byte stream parsing has many other values which need endian conversion (like the number of params, DLTensor internal fileds …etc.).

Understand your confusion, I thought it should not be passed.

But I’m sure the executable passed (printed the added logs) and got the abnormal result [-nan -nan -nan] as I said. So the order of weights or other parameters were wrong. Due to some privacy policy, I cannot put the screenshots here. Sorry about that.

Aiming at getting the executable in ARM machine. I followed the way in cross compile guidance. Focusing on graph_runtime.cc, either closing the check macros or keeping them open, the executable could be generated and it ran well without any breaks (both in X86 and ARM machine). Sounds weird, but it happens.

My compiling environment is Ubuntu, x86_64, little-endian. The cross compiler is armeb-linux-gnueabi-g++.

Is both target host and target on arm are llvm ?

Hope no GPU there?

Definitely no GPU here.

Back to the first question. I just follow the target opinion to get the .params, .json and .so. To be honest, I’m not sure about target host. What I can tell you is the target on arm is not llvm.

No probs, looks like its llvm all over.

https://github.com/srkreddy1238/nnvm/commit/edf917865a79ca823f5bcdcc7f318524cd84304c

Check if this patch works.

Many thanks!

The training has to cost about 50 mins. I will reply the result here. You can check it when you are free. Just don’t want to waste your time : ).

1 Like

Any luck with this patch ?

Sorry for late reply. A busy day today ; (

Sadly, it didn’t work. the result was still -nan -nan -nan. And I’m a little confused about two points:

The first one is, the position of the patch. The code was added in graph_runtime.cc in nnvm instead of tvm. I guess what your idea is to convert the byte order during writing the parameters, not the loading part.

The second one is, I didn’t use the graph_runtime.cc (in nnvm) either in generating model (so params and json files using python) or loading the model (only tvm using C++). Maybe we should move the patch into somewhere in tvm? Or just edit the patch in python?

Thanks.

(I tried to reply you many times but my network got crushed,I could not send message. Apologize for late reply again.)

Don’t bother, I was just exited to check the results !!

You could try the same byte swap here and recompile the tvm runtime and give a try,

Ref. https://github.com/dmlc/dmlc-core/commit/9b3f9753ae81d657743c555e0cacc4e43f0bed2d

Patch to support endianess from @tqchen

Thanks for bring this issue up, the model saving of existing tvm and runtime is not endian aware, I am working on a patch to enable big endian support. https://github.com/dmlc/tvm/issues/1202

Try out https://github.com/dmlc/tvm/pull/1206 to see if it works. This is a change that requires careful rework of all part of the serialization so I take a stab on this.

As a bonus, you can now directly use RPC server on your arm side and cross compile from your x86 host

1 Like

Got it! Thanks a lot!

So glad for contributing TVM better and better.

After updating the code and compiling, some error occurred.

my/path/to/tvm/dmlc-core/include/dmlc/./serializer.h:63:5: error: ‘Write’ is not a member of 'dmlc::serializer::UndefinedSerializerFor’

my/path/to/tvm/dmlc-core/include/dmlc/./serializer.h:66:33: error: ‘Read’ is not a member of 'dmlc::serializer::UndefinedSerializerFor’

I’m not sure the reason why Write and Read were not members.

try git submodule update —recursive

Then rebuild your tvm from scratch

My fault. Forgot to update it. Sorry about that.

Good news is it worked very well ; ). Thanks very much for the byte-order conversion patch.

1 Like

Appreciate @tqchen and @srkreddy1238 for this conversion job again!!!

It looks like compiling on big endian system has been pulled out by a later commit 72fa4c1d93df2e85f89052c72905c3fe67f62a34 so now tvm fails to compile on big endian system. Any reason why? Is there any plan to support big endian again? Thanks.