World: r3wp

*mezzanine*

New release at https://github.com/Geomol/World

- The new routine spec is implemented.
- Compiling blocks should be fixed. I also added a test for this.

- system/version changed. Should be able to handle all future platforms/bits/processors/makers/etc.

- Added libs/version.w to help with deciding platform and version.
- Other fixes.

- Now cortex_alpha.pdf is updated too.
- And new version of cortex.w , where HELP can handle routines.

Defining routines is very flexible, a bit against my simplistic philosophy 
for World, but now it's done. Having e.g. libc (OS X example):

libc: load/library %/usr/lib/libc.dylib

Defining PUTS can be as simple as:

puts: make routine! [
	libc "puts" [
		[string!] pointer
	]
	sint
]

or as full of info and features as:

puts: make routine! [
	"Writes a string to stdout followed by a newline."
	[typecheck]
	libc "puts" [
		string [string!] pointer "String to write to stdout"
	]
	sint integer!
]

Compiling blocks is not 100%. Working on it.

Geomol: this is such nice stuff!

:)

My first experience with LLVM.


I tried to compile World with llvm-g++ under OS X. When compiling 
with gcc, I normally use -O2 option. I compared performance with 
the Mandelbrot test. Between compilations, I deleted all .o files 
and executable, so new compile started from scratch.

Compiling with llvm-g++:

With -O2 option, file size grow to 105% and execution time extend 
to 105% (slower).

With -O3 option, file size grow to 106% and execution time is the 
same.

With -O4 option (also Link Time Optimization), file size extend to 
122% and execution time grow to 107% (slower).


Then I tried to compile with gcc and -O3 option. Now file size grow 
to 105% and execution time shortened to 85% (faster).

Has anyone had similar experience with LLVM?

(And I thought, LLVM was much better, but maybe I do something wrong 
or miss some option!?)

Porting to LLVM took less than an hour. It's mainly changes, because 
LLVM is very strict about types, when checking e.g. unsigned against 
signed values. etc.

You mean porting to "clang"?

There is a /usr/bin/llvm-g++ command under OS X. The man page say:
llvm-gcc uses gcc front-end and gcc's command line interface.

So maybe it isn't "clang"!? I'm not sure. It's my first real experience 
with LLVM.

There also is a /usr/bin/clang
Maybe I should try compile with that.

By the way, why haven't you used LLVM for building World? As it is 
VM-based, LLVM would have been a good match.

Because I had no experience with LLVM, because I started World dev. 
on older MacBook, because LLVM was many MB download, because I wasn't 
sure, I could get LLVM on Windows and Linux easily.

I tried compile with clang. More results, first with gcc, then clang:

gcc -O2 option
size: 346136
time: 0:00:00.681560

clang -O2 option
size: 349976
time: 0:00:00.736821

clang -O3 option
size: 354072
time: 0:00:00.643053

clang -O4 option
size: 382888
time: 0:00:00.734845

And I notice, at least one of my tests don't finish with the LLVM 
and clang versions, which is disturbing. :/

So it seems, I made a good choise with gcc, because 1) it was easy 
to make World compile with LLVM and clang (if I choose that path 
now) and 2) it seems, some code doesn't work as intended with LLVM 
and clang.

gcc -O3 option
size: 362304
time: 0:00:00.579858


It seems, gcc beat LLVM and clang here on performance, if I use -O3 
option.

LLVM isn't really VM-based in the sense that bytecode VMs are. The 
VM is a compiler backend, but the code it requires tends to have 
to be specialized a little for the actual machine. As the developers 
of Portable NaCl have been discovering, it's not necessarily that 
good at being a portable VM.

You might also look into LuaJIT, as it is supposedly faster than 
most VMs, and smaller too.

Thanks, Brian (LuaJIT). Could be later, when World is stable and 
the hunt for performance really starts.

Sure, LLVM is not a "VM", it's a framework for building compilers, 
interpreters, VMs,...But for a VM-based language implementation, 
it makes sense to strongly consider the LLVM option.

Yeah, I've had it in the back of my head all the way with World. 
And then I just noticed, it was installed on this Mac.

llvm-gcc support has been dropped in the most recent LLVM release 
(3.0), so definitely use clang whenever you can.

I don't think that LLVM/Clang claims to be much better in runtime 
performance over GCC, at the moment.

The resulting binaries are, at the moment, generally comparable to 
GCC-generated ones. GCC is better in some areas, LLVM/Clang in others.

However, _build_ times with Clang should be superioer, but that won't 
matter much for World, I think. Error messages from Clang should 
also be much better. Esp. for C++, but also for C.

ok, I think, most believe, LLVM/Clang is about performance.

So it's more about portability and maybe better error messages?

For typical end-users, clang is about fast compilation and good error 
diagnostics (at the moment).

ok,thanks

Clang also explicitly aims at GCC compatibility, so switchting to 
it from GCC is generally rather easy.

I'm confused Geomol, you're not aiming LLVM to perform jit within 
#world  but to compile the VM of #world ?

Yes.

but...

what is the interest, I mean when compared with standard C compilation.

That is just standard C compilation :)

uh !

LLVM/Clang is actually the default toolchain in Xcode4, for example 
:)

IIUC, John tried LLVM to see if the resulting binaries would performan 
better than GCC-compiled ones.

ah ok, but is there any other motivation behind the scene like to 
be able to compile code on the fly instead of generationg bytecodes 
for the VM ?

I mean LLVM can support JIT or is that another toolchain ?

LLVM can also be used as a set of compilation libraries, yes. And 
you can implement a JIT that way, yes.

But they also provide a set of ready-built binaries which work as 
a nice AOT compiler for C/C++/ObjC. I.e. just like GCC or MSVC or 
ICC or ...

John, you may want to try -Os. Optimising for size often leads to 
best speed, too, on modern architectures due to caching efficiency. 
OS X is also compiled that way

Thanks, Kaj. I will try that.
Steeve, it was just to try another compiler.

World should accept REBOL [] as header to run R2, R3 scripts through 
it without editing these.

For now, it's possible to run REBOL scripts with this function:
do-rebol: func [file][do skip load file 2]

R3 scripts only require the REBOL header if they're modules/extensions.

Or when you want to put documentation before the header, or embed 
the script in a block in another type of file.