As you know, benchmarks are often fun but just as often meaningless. And premature optimization being the root of...anyway. ;)
It may come. JIT is planned. I don't know of any language that wants to be slow, and I can only speak for myself, but I think Red's goal is one of overall performance. In 1991, people told me I couldn't use VB, because it was too slow. I countered that my app would be 12-18 weeks faster than their C app. :) Still, this is 2017 and we have options.
Red won't be fast enough for everyone, or everything. But it will be faster than a lot of alternatives for many purposes. What kind of stuff do you need maximum performance for, how much of your work is that, and what are some of your real-world examples and performance criteria? I work best with concrete examples.
One of the things that initially excited me was being able to write code like Python for parsing and automating office tasks and then dropping down to RedSystem for numerical work like matrices and various algorithms and perhaps some embedded work like talking to an arduino. If it could truly do that, I'd give up needing to know 9 languages depending on what I'm doing.
Except for the embedding part, Julia is pretty good for all other purposes already, isn't it? And I say this as someone who is excited by both Red and Julia.
Julia is pretty cool,especially on the numerical side and it does have macros although I bet Red's are more powerful being homoiconic. Julia has a JIT using LLVM which is fast & neat, but it doesn't compile down to a binary exe to my knowledge.
Awesome. That's why I hope the System code is fairly fast, because compilation won't matter if it is still super slow. If y'all do a version on the JVM you get fast, but also a bloated dependency and then you're not much different than anything else with a JVM backend (Scala, Clojure, Groovy, Perl6, PicoLisp...etc). I really am excited by Red btw. Hopefully performance can be a thing at some point before 1.0. The Perl6 people released their 6.0c (basically 1.0) where the language is mostly frozen, and are now spending 90% of development time on optimizations (honestly I pulled that number out of my butt, but the ratio is in that favor) because it is so slow for most things currently. I'm not sure if that was smart as now people are thinking"I waited 15 years for this?". Overall another great language I'd happily throw away Python for, but it has some work to do before I can really use it. I hope Red doesn't fall into the same trap.
You might also want to look at ren-C (https://github.com/metaeducation/ren-c), a fork of the open sourced Rebol 3 (which isn't an active repo). It can be build with an embedded TCC so you can write C in-line for functions where you need a speed boost.
One of the nice things about Red is the low barrier of entry, for experimenting and getting a taste. If you can drop an EXE somewhere, you can run it and try things. If you can run "red -c ..." you can compile and include Red/System code.
It may come. JIT is planned. I don't know of any language that wants to be slow, and I can only speak for myself, but I think Red's goal is one of overall performance. In 1991, people told me I couldn't use VB, because it was too slow. I countered that my app would be 12-18 weeks faster than their C app. :) Still, this is 2017 and we have options.
Red won't be fast enough for everyone, or everything. But it will be faster than a lot of alternatives for many purposes. What kind of stuff do you need maximum performance for, how much of your work is that, and what are some of your real-world examples and performance criteria? I work best with concrete examples.