• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

kensingleton
1-Oct-2012
[2439]
Wow! the Mandelbrot is fast - elapsed time 0, process time 0.22
Kaj
1-Oct-2012
[2440]
There's reward at the end of the tunnel :-)
kensingleton
1-Oct-2012
[2441x2]
Rebol 2 elapsed time: 17.473 seconds - yawn!
Sorry - I tell a lie - that last elapsed time for R2 was for the 
fib - the mandelbrot is 4.436 seconds - still very slow comapared 
to Red/System - this is cool!
Steeve
1-Oct-2012
[2443]
20 times faster ? I would expect more :-)
Kaj
1-Oct-2012
[2444]
Timing on Windows is inaccurate. For the Mandelbrot, it probably 
includes a significant share of printing the result, instead of computing 
it
kensingleton
1-Oct-2012
[2445]
Elapsed time for fib on Reds is 0, process time is 0.103 - so fib 
is hundreds of times faster on Reds compared to R2 - so I guess it 
depends on the program as to the speed difference
Kaj
1-Oct-2012
[2446]
That's consistent with my laptop that I used for this month's recordings, 
about a factor hundred
kensingleton
1-Oct-2012
[2447]
It's impressive - Reds will open a whole new world for us C haters 
:)
Kaj
1-Oct-2012
[2448]
Yep
kensingleton
1-Oct-2012
[2449]
What is really exciting is the concept of creating an OS which is 
completely red/red/system - the control, power and speed of that 
woulod be phenomenal
DocKimbel
1-Oct-2012
[2450x3]
Red/System v2 will be faster, it will benefit from a lot of optimization 
stages that do not exist in the current version. I expect a raw speed 
improvement of between x2 and x4. Maybe more if we can use some SIMD 
to speed up some processing (but that will probably require new datatypes, 
and/or new looping functions).
Ken: full Red stack, yep, that's the long term goal. ;-)
Carl though about it (Lava/MagmaOS), we will make it real! ;-)
kensingleton
1-Oct-2012
[2453]
Yes - it could truly revolutionise computing - a single high level 
language which enables you to program everything - fantastic concept!
Maxim
1-Oct-2012
[2454]
it used to be called  language  C   ;-)
Pekr
1-Oct-2012
[2455x2]
Well, one day, Carl sees the light at the end of the tunnel, and 
joins Red ;-)
Doc - will we have something like Rebin?
kensingleton
1-Oct-2012
[2457]
I hope that a lot more Rebol coders get on-board with Red to help 
Doc and speed development - Red is the future I think, not interpreted 
Rebol, as brilliant as that has been in the past.
Pekr
1-Oct-2012
[2458]
For me the difference is elsewhere - Red has a momentum, which Carl 
almost/mostly killed by the 18 months of information embargo. Red 
has a lead - DocKimbel, who is dedicated to the matter, whereas R3 
looses its main lead - Carl.
DocKimbel
1-Oct-2012
[2459x2]
it would be nice to formalise, e.g. to have /bindings subdir, where 
partricular systems would be represented by subdirs, etc.


We already have some place for that since many months (it's the /library 
folder): https://github.com/dockimbel/Red/tree/master/red-system/library
Got my raspi board! :-) Any advice on the type of SD card that works 
the best with it?
Kaj
1-Oct-2012
[2461]
Haven't got power for mine yet
Andreas
1-Oct-2012
[2462x2]
SD card: a slow and not too big one :)
Have a look at http://elinux.org/RPi_VerifiedPeripherals#SD_cards
DocKimbel
1-Oct-2012
[2464x2]
64GB SDXC Class 10 Extreme (45 MB/s UHS-I) (SDSDX-064G-X46) - works 
with 2012-07-15-wheezy-raspbian

:-)
SanDisk cards seems the most tested ones.
Andreas
1-Oct-2012
[2466x2]
I think most SD problems are solved with recent boot loaders, anyway.
I have a few SanDisk Class 10 Extreme myself, which didn't work initially 
when I got my first RPi, but work just fine now.
Gerard
1-Oct-2012
[2468]
http://uk.farnell.com/raspberry-pi-accessories#operatingsystem
has some more SD cards and accessories - as described in my new book 
: The Raspberry Pi - a quick start guide - by Maik Schmidt pubished 
by pragmatic programmers
DocKimbel
1-Oct-2012
[2469x2]
Thanks Gerard!
Implemented IF and EITHER, I just wanted to share their implementation 
with you (extract from Red compiler source)::

	comp-if: does [
		comp-expression		
		emit compose [	
			if (logic-true?)
		]
		comp-sub-block
	]
	
	comp-either: does [
		comp-expression		
		emit compose [	
			either (logic-true?)
		]
		comp-sub-block
		comp-sub-block
	]

Shouldn't be more complex than that, no? ;-)
Kaj
1-Oct-2012
[2471]
Turing is calling
GrahamC
1-Oct-2012
[2472]
forth computers are single stack .. they haven't conquered the world
Kaj
1-Oct-2012
[2473]
Are you sure?
Steeve
1-Oct-2012
[2474]
I wonder for some time why you give long c-like prefix names to every 
functions. 
Is the context not enough? like rebol style does prefer.
Or is that you fear to forget what's doing your own code ? ;-)
Or maybe there is a technical reason behind it I missed.

No offense intedended here Doc, just a genuine question about your 
prefered coding style.
DocKimbel
1-Oct-2012
[2475]
I'm not sure what you mean by "long c-like prefix names to every 
functions."?
Steeve
1-Oct-2012
[2476]
comp-*
DocKimbel
1-Oct-2012
[2477]
You talk about the "comp-" prefixes I use in the compiler code?
Steeve
1-Oct-2012
[2478x4]
yep
is the context not enough ? I mean you use a dffierent context when 
compiling.
Well I'm not sure if what I'm saying makes sense even for me, sorry 
;-)
I should go read some manga and relax
DocKimbel
1-Oct-2012
[2482]
It adheres to REBOL convention for naming functions (starting with 
a verb) but it also serves other purposes:


- as a way to classify the compiler internal functions by category 
or compilation stages, e.g., comp-* functions do the translation 
+ code generation, fetch-* just fetch source code, check-* perform 
type or spec verifications, emit-* just generate target code, etc...


- as a way to stratify the code in compiler context. As I want to 
keep the compiler internal code in one piece (because of too many 
common dependencies). It helps me navigate quickly in the code when 
searching for a bug for example.
Steeve
1-Oct-2012
[2483]
Ok I see your point with the depedencies, different contexts could 
be annoying.
DocKimbel
1-Oct-2012
[2484x2]
They might do more harm than good.
(in this specific use case)
Steeve
1-Oct-2012
[2486x3]
The model you're using to compile is nested functions which in the 
end emit code.

Don't you think several well separated stages which emit their own 
dialect would avoid to much depedencies in your code ?

Another benefit of stages is that you can easly add/remove specific 
phase like optimization ones
In return it would be slower
but more flexible