136 karma · joined August 25, 2010
Name: Robert G. Jakabosky
Location: Guangzhou, China
Remote: Yes
Willing to relocate: Maybe
Technologies: Rust, C/C++, Lua, Java, Node.js, Javascript/HTML/CSS, Substrate,
MySQL/Postgres/MongoDB, JIT/Compilers, FIX protocol, ZeroMQ,
FreeSwitch/Asterisk, Docker
Résumé/CV: https://cn.linkedin.com/in/neopallium
Other profiles: https://github.com/Neopallium,
http://stackoverflow.com/cv/neopallium-34934
Email: rjakabosky@sharedrealm.com
Wechat: robert2051
Full-stack developer. Worked with stock market datafeeds (BridgeFeed,FIX,Activ Financial) for about 7 years. IVRS/VOIP using FreeSwitch/Asterisk. Implemented a JIT/static compiler for Lua [0][1].I am a Canadian who moved to China about 3 years ago. Anyone else around Guangzhou/Shenzhen/Hong Kong? I am interested in meeting others around here.
0. https://github.com/Neopallium/llvm-lua
1. https://github.com/Neopallium/slua
[ my public key: https://keybase.io/neopallium; my proof: https://keybase.io/neopallium/sigs/jvP68uqQEiNiYP6NcRz8Ps8axbNXG62Pv94A3KIww04 ]
It was easy to get the Rust code compiled and working as a drop-in-replacement for the C Library. This has been a big help with refactoring the unsafe Rust code into safe Rust (manual work). OpenJpeg has a great testsuite that has allowed testing that each refactor step doesn't add new bugs (has happened at least 3 times).
The original run of c2rust generated 96,842 lines of Rust code (about 1 year ago), now it is down to 46,873 lines code. A lot of the extra 50k lines of code were from C macros that got expanded and from constant lookup tables (C code had 10-30 values per line, Rust 1 value 1 line).
For anyone looking to use c2rust to port C code to Rust, I recommend the following:
1. Setup some automated testing if it doesn't exist already.
2. Do refactoring in small amounts, run the tests and commit the changes before doing more refactoring.
3. Use "search/replace" tools (`sed`) to help with rewriting common patterns. Make sure to follow #2 when doing this.
4. Don't re-organize the code until after most of the unsafe code has been rewritten. This will allow easier side-by-side comparison with the original C code.
5. c2rust expands macros and constants from `#define`. Being able to do side-by-side comparison of the C code will help with adding constants back in and removing expanded code with Rust macros or just normal Rust functions.
[0] https://github.com/Neopallium/openjpeg/tree/master/openjp2-r...c2rust also has a refactor command that helps with refactoring the generated Rust code.
This blog post shows how to write simple idiomatic Rust code that will allow the compiler to auto-vectorize:
It is a great example of how the Rust compiler can auto-vectorize code.
From what I have read so far is seems that AMD CPUs have had the fewest vulnerabilities/slowdowns? But I can't be sure since I haven't seen a complete comparison (including these new vulnerabilities).
The comment in the article was "…email about that 'thing'". I would immediately think "what thing?", then everything else goes down the drain.
Found that accidentally because of autocomplete on my phone changed "-ef" to "get".
I didn't really need the JIT feature. But I did add support for it because Lua code can dynamically generate/load more Lua code.
I just found that the runtime overhead (memory and stack space) of LLVM was too high for my needs.
That answer is about typed languages. The issue is with dealing with dynamic types. There is a lot more code generated for the JIT to compile.
Thanks for the heads up.
The main issues I had with LLVM was the partly do to the memory usage. It can product very good machine code, but the time needed to JIT a block of code was sometimes longer then just running the it in the interpreter.
One of the features I like about Lua the most is the low resource overhead. LLVM was just too big for what I was looking for.
Usage LLVM to JIT/AOT compile Lua code was really just an experiment, something I wanted to try out.
I re-wrote [0] the llvm-lua project with a simple C code-gen backend for compiling Lua code to native code. Which is a bit more useful, since it is easier to cross-compile pure C code, then LLVM bitcode. A lot of the people that tried using llvm-lua wanted to cross-compile Lua code and embed it into an iOS application.
Others [2] have also found LLVM to be unsuitable as a JIT.
0. https://github.com/Neopallium/llvm-lua
1. http://stackoverflow.com/questions/4077396/llvm-jit-speed-up...
I have seen and heard about so much fake advertising, that I don't really even care what the label says anymore.
How hard would it be to create easy to use testing kits? (like home water tests for heavy metals)
If we could create test kits to help identify heavy metals, peanut oil, or other bad additives. Then that would help consumers to identify fake food.
I don't know how hard it would be to make kits like this, but it seems there is a market for it.
0. http://www.freelists.org/post/luajit/Looking-for-new-LuaJIT-...
With how much traffic the NSA was collecting and archiving during that time, it is very likely that they had captured traffic that they thought might contain messages to/from Snowden.
If DDOS filtering modules can be written in P4, then they could be used on software switches and maybe even compiled into packet filters that run before packets are processed by the Linux kernel (or compiled into a kernel-bypass module for embedding in an application).
I think we really need to have better support for low-level high performance packet filtering (i.e. before the packet gets to higher levels in the kernel).
With multi-gigabit networking becoming cheaper, we really should have better support for dropping bad traffic.
How about a switch layer that runs in the kernel? Physical NICs and virtual NICs could be handled by the switch layer (programmed using P4 or eBPF). The kernel would only have to handle packets it receives from the virtual NICs. This would allow packet filtering and even some routing to happen without having to go through the kernels network-stack. The software switch layer would work like a data-plane with the kernel as the control-plane (like a lot of hardware routers/switches). If the computer has specialized hardware (smart NICs, co-processors), then the switch logic (P4 code) could be handled in that hardware instead of on the CPU.
The cache can be bypassed when doing a lot of writes. See section "Bypassing the cache" of [0].
That article says that memset() already uses cache bypassing instructions for large blocks.
I think a language like P4 will be great for sharing switching logic. I hope we will see re-usable modules written in P4 that can be shared.
0. https://github.com/esbullington/snabbp4 1. https://github.com/snabbco/snabb
Crypto libraries can be fixed to prevent side-channel attacks like this. The article says that libgcrypt has already been patched.
package main
func main() {
println("Hello, world")
}
That compiles to 1.1M using go 1.5.