Nice! I wish creating Lua executables were this easy. With Lua you have to create a wrapper C file, use squishy to combine multiple lua files into one, and finally a script to turn the lua script into a C byte array. I have a boilerplate project that I use so that I just have to run `make`, that avoids the need to ever touch C for the most part. But it would be nicer if luac and luajit did this automatically.
SQLite style: The amalgamation is a single C code file, that contains all C code for the core. With one big unit, the compiler can perform several smart optimizations that cannot be done if the source code was split between different C files.
I was curious why they did that. Just looked at the source and came across this :
This file is an amalgamation of many separate C source files from PH7 version 2.1.
By combining all the individual C code files into this single large file, the entire code
can be compiled as a single translation unit.This allows many compilers to do optimization's
that would not be possible if the files were compiled separately.Performance improvements
are commonly seen when PH7 is compiled as a single translation unit.
The target does say for embedded so I guess that's from experience running this on very small resources.
But the glueing together destroys any modularization they had going on, making the code way harder for anyone else to understand and read.
The "typical" solution to that very valid problem is to use the preprocessor, i.e. create a "ph7-master.c" file that simply includes all the real C files.
The comparative overhead of should be negligble, but then the modularization survives.
You mean so you can distribute a standalone binary that is actually just a bunch of lua? Do you do this so that the users have a harder time modifying the code (just curious)? I'm supposing that this is the case otherwise it would work pretty well with by using the lua or luajit interpreter and some wrapper bash/cmd.exe script to run your lua file(s).
> You mean so you can distribute a standalone binary that is actually just a bunch of lua?
No, I'm saying that you can't. You create a wrapper main.c file that loads and executes the lua. I use a script that tranlates the lua into a C byte array so that I can avoid loading the external lua scripts.
> Do you do this so that the users have a harder time modifying the code (just curious)? I'm supposing that this is the case otherwise it would work pretty well with by using the lua or luajit interpreter and some wrapper bash/cmd.exe script to run your lua file(s).
No, I do it to avoid having to worry about where the .lua scripts are located. Having a single binary is nicety, not required of course.
>No, I'm saying that you can't. You create a wrapper main.c file that loads and executes the lua. I use a script that tranlates the lua into a C byte array so that I can avoid loading the external lua scripts.
I think that's what he meant -- that ignoring the small wrapper part --which is boilerplate--, you can deliver a binary that's basically lua.
ld has a -e argument [−4] (and MSVC's link has /ENTRY [37]). Otherwise, if there is a function with the expected name, calling convention and arguments in the object file I doubt the linker will complain.
2 - create a main() in c.. use "extern" to reference the external symbol in the .o files and call it from main.
The symbols in the object files produced by luajit or whatever need to be exported/ visible.. (are they mangled?)
3 - create a object file for main.c
4 - link the .o created from luajit(or whatever, dart?) and main.o together
If the linker cant find the external symbol it wont link to a binary (so you need to know how, in what names they are exported.. use objdump to lookup for symbols)
That is one big C file. Curious if you've ran against any of the Zend tests in the original implementation [1][2]. I do not see anything on http://ph7.symisc.net/.
I've been looking for something like this. Originally I had planned to do it with Python, but Python only seems to allow one interpreter at a time.
Does anybody know if it's easy to make new functions available to PHP that would call into the C main program?
It says "Built with more 470 function" how does that compare with standard PHP? If I take some PHP I've previously written or a library, is it going to run with minor modifications? Or is this a subset of PHP?
My first thought on seeing this project was wondering how hard it would be to hook up to nginx, or similar. I don't really "do" PHP, so I'd probably not attempt it myself, but I get the feeling from having written nginx modules in the past that this doesn't look too hard - the PH7 API seems decent enough.
Interesting, please write a blog post if you investigate this. It could be like OpenResty (Lua + Nginx): http://openresty.org
I am using HHVM (Facebook's HipHop PHP w/JIT) with Nginx. that works great... but it requires a 64-bit server. So for smaller servers or embedded systems Ph7 sounds interesting.
Curious, what do people who work with embedded systems usually use to get a web interface for their device? Routers, for as long as I can remember have had a web UI though I'm not really sure what sort of a back end runs it.
Lua is pretty widely used. C is also favoured but it's pretty easy to misuse so there are teams that shy away from it. I've seen Perl, Python and PHP, too, as well as some obscure languages. I distinctly remember seeing Tcl, but I don't remember the context so I might be bullshitting here.
It greatly depends on flash and RAM though. Past a certain point, Python or PHP are just too large.
Normally I wouldn't touch PHP due to the long history of security issues. Would this do anything to improve it? Love the idea of an embeddable interpreter.
If insecurities are part of PHP, no, not unless they deviate from the standard implementation. And there are most likely a bunch of undiscovered stack overflow type insecurities in this new interpreter as well.
This seems like madness to me. It's "PHP", so it inherits everything that's bad about that language. But it's also incompatible with PHP, so you don't even get the power of being able to reuse the world's existing PHP code and expertise.
* PH7 is case-sensitive unlike the standard PHP engine
* Unlike the zend engine which passes arrays by copy, PH7 pass arrays by reference exactly like PHP5 does with objects (class instances).
I'm not saying the extensions and changes they've made aren't for the better, but they mean this language is effectively not PHP. And, if you're going to use a language that's not PHP, why not use one that's significantly cleaner and simpler?
I'd normally agree, but "embedded device" in this situation means "network router" (which are reasonably powerful computers in their own rights), and the application is not mission critical with hard deadlines and strict memory requirements, but just a web interface that is rarely active and can take as long as it wants running in the background. It doesn't seem unreasonable to me to set aside some portion of memory for the web interface, give the PH7 process low priority, and hire some PHP web devs that actually know what they're doing to make the interface for them. More sense than letting the firmware developers hack something together in C anyway.
I'm not a web developer, but that sounds pretty sane to me. However, the important part of their decision, I'm guessing, was not so much the PHP part, but the "get people who actually know about the web to do this for us." Someone has to build the site either way, and I'm guessing the embedded engineers they had working on it didn't really know how to go about that.
EDIT: Another possibility is that they already had PHP devs working on their corporate site or whatever, and they wanted to use them instead of hiring another team.
it's obvious isn't it? it's like "if you can't learn calculous I'm pretty sure you haven't the skills to do rocket propulsion calculations"
Someone with only one language or a "main language" is someone who just simply has a lower level of skill than is needed for embedded programming- which requires lots of different skills and languages. Being able to learn more than one thing is a prerequisite.
if your natural response to something like embedded php is "Oh how convenient, I can use my main language!" then that would imply the answer is "yes", since, if you do know other languages your natural impulse would be to use pretty much any other language if you have a choice.
This is pretty cool. First I was wondering what for, but its great for their use case (embedded devices). Why not use a language for the web interface the developer is familiar with.
Unfortunately, they're a bit late. Nowadays it would probably be cooler to use JS, if language popularity is the focus. Or maybe python.
(Aside: I learned web development in the good old LAMP times. My silly gut feeling is still that PHP is pretty fast and flexible compared to Python which seems slow (on the server), and JS which is way too slow and fragile. I know it's completely backwards nowadays, but funny how what you've learned sticks. When I hear "JS on a Arduino" I always think "yeah sure....", but it's actually a clever idea, just like this.)
In my experience the difference in performance of the languages is negligible (assuming you have a solid PHP config). I run sites written in each, and I can't say one has caused me more performance problems than the other; it just depends on what you're doing with them.
This sentence doesnt mean anything. What Python task? What library ? what framework ? on what server? with which version ? ect... I can say PHP is slow too, just look at any PHP framework, lowest scores according to techempower benchmarks :
I usually see arguments like this about language performance, but do people also argue about the difference from having a server process launch, configure itself, and stay open handling requests, like Ruby or Node.js, versus re-running initialization on each request like PHP?
A lot of that initialization code is hooking together objects, reading misc config flags, and setting up request routing. But what about ORM? Ruby's ActiveRecord has to query the database for a schema, right? In PHP that query would be done every request rather than just once when the server restarts.
Could this architecture issue have a larger performance impact than the minor differences in Python / PHP / Javascript / Ruby performance?
(There were also plenty of discussions about event-based programming versus blocking + multi-threading back when Node was becoming popular. That is another example of architecture being more important than execution speed.)
67 comments
[ 3.1 ms ] story [ 125 ms ] threadNice! I wish creating Lua executables were this easy. With Lua you have to create a wrapper C file, use squishy to combine multiple lua files into one, and finally a script to turn the lua script into a C byte array. I have a boilerplate project that I use so that I just have to run `make`, that avoids the need to ever touch C for the most part. But it would be nicer if luac and luajit did this automatically.
The "typical" solution to that very valid problem is to use the preprocessor, i.e. create a "ph7-master.c" file that simply includes all the real C files.
The comparative overhead of should be negligble, but then the modularization survives.
No, I'm saying that you can't. You create a wrapper main.c file that loads and executes the lua. I use a script that tranlates the lua into a C byte array so that I can avoid loading the external lua scripts.
> Do you do this so that the users have a harder time modifying the code (just curious)? I'm supposing that this is the case otherwise it would work pretty well with by using the lua or luajit interpreter and some wrapper bash/cmd.exe script to run your lua file(s).
No, I do it to avoid having to worry about where the .lua scripts are located. Having a single binary is nicety, not required of course.
I think that's what he meant -- that ignoring the small wrapper part --which is boilerplate--, you can deliver a binary that's basically lua.
With a little search I found out UPX and it seems to be working with many unix binary formats too.. http://upx.sourceforge.net/
edit: If so I've been doing it wrong for years.
[−4] ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_24.html
[37] http://msdn.microsoft.com/library/f9t8842e.aspx
1 - create the object files (with luajit?)
2 - create a main() in c.. use "extern" to reference the external symbol in the .o files and call it from main.
The symbols in the object files produced by luajit or whatever need to be exported/ visible.. (are they mangled?)
3 - create a object file for main.c
4 - link the .o created from luajit(or whatever, dart?) and main.o together
If the linker cant find the external symbol it wont link to a binary (so you need to know how, in what names they are exported.. use objdump to lookup for symbols)
1 - https://github.com/php/php-src/tree/master/tests 2 - https://github.com/php/php-src/tree/master/Zend/tests
Does anybody know if it's easy to make new functions available to PHP that would call into the C main program?
It says "Built with more 470 function" how does that compare with standard PHP? If I take some PHP I've previously written or a library, is it going to run with minor modifications? Or is this a subset of PHP?
My first thought on seeing this project was wondering how hard it would be to hook up to nginx, or similar. I don't really "do" PHP, so I'd probably not attempt it myself, but I get the feeling from having written nginx modules in the past that this doesn't look too hard - the PH7 API seems decent enough.
I am using HHVM (Facebook's HipHop PHP w/JIT) with Nginx. that works great... but it requires a 64-bit server. So for smaller servers or embedded systems Ph7 sounds interesting.
https://wiki.strongswan.org/projects/strongswan/wiki/Libfast + http://www.clearsilver.net/
http://appwebserver.org/products/appweb/server-side-javascri...
http://duda.io/
http://luci.subsignal.org/
It greatly depends on flash and RAM though. Past a certain point, Python or PHP are just too large.
There is your problem.If you cant learn anything else pretty sure you havent the skills to program any "embedded device".
That way you can get a clean separation of the front and back ends, and the web developers get to work with exactly the tech they are used to.
EDIT: Another possibility is that they already had PHP devs working on their corporate site or whatever, and they wanted to use them instead of hiring another team.
How did you arrive at this conclusion?
Someone with only one language or a "main language" is someone who just simply has a lower level of skill than is needed for embedded programming- which requires lots of different skills and languages. Being able to learn more than one thing is a prerequisite.
Unfortunately, they're a bit late. Nowadays it would probably be cooler to use JS, if language popularity is the focus. Or maybe python.
(Aside: I learned web development in the good old LAMP times. My silly gut feeling is still that PHP is pretty fast and flexible compared to Python which seems slow (on the server), and JS which is way too slow and fragile. I know it's completely backwards nowadays, but funny how what you've learned sticks. When I hear "JS on a Arduino" I always think "yeah sure....", but it's actually a clever idea, just like this.)
This sentence doesnt mean anything. What Python task? What library ? what framework ? on what server? with which version ? ect... I can say PHP is slow too, just look at any PHP framework, lowest scores according to techempower benchmarks :
http://www.techempower.com/benchmarks/#section=data-r8&hw=ec...
A lot of that initialization code is hooking together objects, reading misc config flags, and setting up request routing. But what about ORM? Ruby's ActiveRecord has to query the database for a schema, right? In PHP that query would be done every request rather than just once when the server restarts.
Could this architecture issue have a larger performance impact than the minor differences in Python / PHP / Javascript / Ruby performance?
(There were also plenty of discussions about event-based programming versus blocking + multi-threading back when Node was becoming popular. That is another example of architecture being more important than execution speed.)
* jx9 - programming language based on JSON (like Lua with a JS syntax): http://jx9.symisc.net/
* unQLite - NoSQL database engine (like SQLite but NoSQL): http://unqlite.org/
No reason. ;)