Another crazy new language effort - Language #42

[xyzzybill]

I've got this crazy idea: I'll write the world's most completely
awesome computer language, and naturally get rich, famous, and
attacked by hordes of crazed hot chicks.

The language is called 42, and has the following insane goals:

- Run faster than C
- Foster extreme code reuse
- Compile to both hardware and software
- Run faster on reconfigurable computers than Wintel boxes
- Allow users to extend the language however they like

I need a few of you super-geeks out there to tell me flat out it's
impossible. For some reason, that always motivates me. I've created
a Google group (http://groups.google.com/group/language-42) where
detailed discussions can take place without spamming this group. I
describe the language in more detail there.

 

[James Harris]

On 2 Jan, 09:59, (e-mail address removed) wrote:
....

I need a few of you super-geeks out there to tell me flat out it's
impossible.  For some reason, that always motivates me.  I've created
a Google group (http://groups.google.com/group/language-42) where
detailed discussions can take place without spamming this group.  I
describe the language in more detail there.

You may want to post about language-42 on comp.lang.misc. That
newsgroup is used by a lot of people who are designing or have
designed their own programming languages.

James

 

[jacob navia]

I've got this crazy idea: I'll write the world's most completely
awesome computer language, and naturally get rich, famous, and
attacked by hordes of crazed hot chicks.

The language is called 42, and has the following insane goals:

- Run faster than C

Any ideas on how would you achieve this?
I looked at your discussion group but it does not
suffice to say what you wish but maybe you should give
some vague hints as to HOW you want to accomplish those
goals...

- Foster extreme code reuse

Yes, everybody says that.

- Compile to both hardware and software

This is quite impossible. Hardware compilers are completely
different and have completely other goals as a software
compiler. Here, you just show your ignorance.

- Run faster on reconfigurable computers than Wintel boxes

Any recongirable FPGA will be faster at its specific
task than any other software since it is hard wired to do
a single task.

- Allow users to extend the language however they like

This is nonsense, since it will provoke a language full of contradictory
features. It is not enough to just add a syntax rule. You have to check
that th new rule doesn't stay in the way of other rules. Actually that
is the most difficult part!

I need a few of you super-geeks out there to tell me flat out it's
impossible.

Yes it is.

For some reason, that always motivates me. I've created

a Google group (http://groups.google.com/group/language-42) where
detailed discussions can take place without spamming this group. I
describe the language in more detail there.

There is no information there, just statements of vague intentions

 

[Bill Cox]

Any ideas on how would you achieve this?

I already demonstrated how to do this with DataDraw, which has tons of
documentation at http://datadraw.sf.net. In short, slow programs that
take minutes to days to run typically thrash memory. DataDraw backed
C has a far more optimized memory organization for cache performance
than standard C programs. Check out the benchmarks on the datadraw
page. For graph traversal, the DataDraw backed code ran 7X faster.

Yes, everybody says that.

Well... yes, we do. Check out how the doubly-linked-list module
reuses code from the linked list and tail-linked list modules, and how
they embed the next pointer in the child class, and even take care of
cleanup on object destruction. You can see example 42 code at
https://graillang.svn.sourceforge.net/svnroot/graillang/trunk/examples.

This is quite impossible. Hardware compilers are completely
different and have completely other goals as a software
compiler. Here, you just show your ignorance.

Actually, several companies already do compile C into Verilog. Here's
a list of some of the players:

ImpulseC (www.impulsec.com)
Synfora (www.synfora.com)
CebaTech: http://www.cebatech.com/
Celoxica : http://www.celoxica.com/
CacheQ: (no website... Xilinx "spinout")
Nallatech: http://www.nallatech.com

I'm actually far from ignorant about hardware synthesis. I usually
work on low-level technology mapping, but I've been doing hardware
synthesis related work for fifteen years.

Any recongirable FPGA will be faster at its specific
task than any other software since it is hard wired to do
a single task.

Oh, how I wish that were true. In reality, the reason reconfigurable
computing doesn't take off is that reconfigurable computers tend to
run generic programs slower than Intel boxes. That's because we focus
on the wrong problem: instead compiling hardware capable of performing
1000 multiplies in parallel, we need hardware than can access 10 to
100 parallel memory interfaces. Reconfigurable computing today just
amplifies the Von Neumann bottleneck, but it's good for signal
processing.

This is nonsense, since it will provoke a language full of contradictory
features. It is not enough to just add a syntax rule. You have to check
that th new rule doesn't stay in the way of other rules. Actually that
is the most difficult part!

Most languages embed a concept that the author of a library is all-
knowing, while users are dorks. C++ private/public and const
declaratoins are part of this. I say it's bunk. Many users know how
to extend yacc grammars, and fix shift/reduce and reduce/reduce
conflicts. They will have ideas we will never think of, and many of
them will be excellent. By saying "This is the langauge, for now and
forever", you close the door on user innovation.

Yes it is.

Thanks.

 

[Bartc]

I've got this crazy idea: I'll write the world's most completely
awesome computer language, and naturally get rich, famous,

and attacked by hordes of crazed hot chicks.

Somehow I don't think hot chicks are crazy about programming languages or
their designers.

The language is called 42, and has the following insane goals:

- Run faster than C

Running on standard hardware, that's going to be challenging, when
programming in low-level anyway.

- Compile to both hardware and software

A lot of programmers (I bet) don't even know what it means to compile to
hardware. You mean the same syntax can be used as a hardware description
language? Or that you can write any application and it can magically design
a dedicated circuit to run it instead of using a cpu?

- Run faster on reconfigurable computers than Wintel boxes

- Foster extreme code reuse
- Allow users to extend the language however they like

These seem contradictory aims. You want to encourage code reuse, but not
reuse of syntax?

If you haven't created a language before, I would say this project was a
little over-ambitious. But good luck. Especially with the hot chicks.

 

[Flash Gordon]

(e-mail address removed) wrote:


This is quite impossible. Hardware compilers are completely
different and have completely other goals as a software
compiler. Here, you just show your ignorance.

Here you show your ignorance. I once had an interview with a company
that was using a C based language to compile to HW. Parallel C IIRC.
They showed me some real HW that had been built using FPGA's programmed
using it, kit that was actually for sale, so it does work.

I suggest you go looking round the HW groups if you want to discus what
can be done.

 

[jacob navia]

Actually, several companies already do compile C into Verilog. Here's
a list of some of the players:

There are some tools that allow you to design an FPGA. Those
tools are far from automatic however!

ImpulseC (www.impulsec.com)

In this site we find:

<quote>
Profile and partition between the processor and the FPGA accelerator.
Use multiple parallel processes for increased performance.

Verify and debug using familiar C-language development tools. Use the
Impulse Application Monitor to analyze parallel dataflow.

Compile and optimize using interactive, graphical tools. Automatically
parallelize and pipeline your critical C code.

Automatically generate FPGA hardware ready for use with your selected
FPGA-based platform.

Automatically generate host-FPGA interfaces for selected platforms.
<end quote>

As you can see from the above description, this is not an automatic
process!

SOME of it is automated, most it is not!

 

[jacob navia]

Here you show your ignorance. I once had an interview with a company
that was using a C based language to compile to HW.

So. You had once (no date specified) an "interview" with a
company (no name specified, nor a hint of what that
company was doing or where) that was using a "C based language" to
compile to HW.

This is as vague as it can possible get.

Parallel C IIRC.

"Parallel C" according to the wiki is:

<quote>
an extension of the C programming language designed for high-performance
computing on large-scale parallel machines
<end quote>

What parallel C has to do with hardware and FPGAs is anyone guess.

They showed me some real HW that had been built using FPGA's programmed
using it, kit that was actually for sale, so it does work.

Yes, there are kits that can program an FPGA, and they could possibly
use a syntax for their input language that looks like C. So what?

Does that mean that I can feed it the definition of strcmp and it will
produce a circuit that does it in hardware???

I suggest you go looking round the HW groups if you want to discus what
can be done.

Yes, many things can be done. But compiling software transparently into
a circuit is a pipe dream. Sorry.

 

[Flash Gordon]

So. You had once (no date specified) an "interview" with a
company (no name specified, nor a hint of what that
company was doing or where) that was using a "C based language" to
compile to HW.

This is as vague as it can possible get.

I've been in the industry for over 20 years, I've done a lot and come
across a lot more. Do you expect me to remember the details of everything?

Oh, and the date would have been late 1999 or early 2000.

"Parallel C" according to the wiki is:

<quote>
an extension of the C programming language designed for high-performance
computing on large-scale parallel machines
<end quote>

What parallel C has to do with hardware and FPGAs is anyone guess.

If I recall correctly it was the language used as I said above. So
having complained about not enough detail you are complaining that I do
provide some detail.

Well, they had a few more extensions, such as a way to map variables to
pins.

Yes, there are kits that can program an FPGA, and they could possibly
use a syntax for their input language that looks like C. So what?

Actually the syntax was C with some extensions. Just like your compiler
is for C + extensions.

Does that mean that I can feed it the definition of strcmp and it will
produce a circuit that does it in hardware???

It produces the design for the FPGA. Actually, they also had libraries,
just as Unix does and your compiler does to deal with some of it. strcmp
will be one of them. However, they did have rather more complex programs
compiled in to FPGAs.

Yes, many things can be done. But compiling software transparently into
a circuit is a pipe dream. Sorry.

For something that is a pip-dream there are a lot of implementations!
That you can do optimisation after the compilation is no different from
being able to get assembler output from a normal compiler and then
hand-optimise the assembler. Some of them do more than others. Some
allow you to do some of the FPGA in a C like language and then link it
to other parts of the FPGA design, some let you do more.

As I say, take it up on a HW group.

 

[Bill Cox]

Somehow I don't think hot chicks are crazy about programming languages or
their designers.

Err... well then, how about the fame and the fortune

Running on standard hardware, that's going to be challenging, when
programming in low-level anyway.

The class of applications where 42 will beat C is most programs that
use a lot of memory. If you use DataDraw (http://datadraw.sf.net) to
program in C using a semi-OO style, your code typically speeds up
dramatically. It's because of better cache hit rates. If you have
typical objects in memory that are larger than a cache line, then on
an L2 cache miss, you typically load a whole line of crud you don't
need. DataDraw by default causes the cache line to be loaded with
like-properties from objects of the same type, with much higher chance
of being useful in most cases. Benchmarks have proved this out many
times.

A lot of programmers (I bet) don't even know what it means to compile to
hardware. You mean the same syntax can be used as a hardware description
language? Or that you can write any application and it can magically design
a dedicated circuit to run it instead of using a cpu?

I should be more specific here. Core 42 syntax will directly borrow a
lot from Verilog. There will be signals that communicate between
processes. It will seem very natural to HDL designers. This is the
main problem with compiling C into Verilog: there's no mechanism in C
to specify a lot about the hardware, so you have to provide extra
information as hacks in comments, and some things, like describing
pipelining, are downright frightful. I say forget that, it's time to
merge real HDL support into a good programming language.

By simply borrowing some of the best concepts from VHDL and Verilog,
42 will be both a software and hardware design language. As a side-
benefit, parallel programming is part of the language as in Intel
BLOCKs, and C++ CSP2. You can instantiate as many processes as you
like, and the event scheduler will assign them to a properly sized set
of threads, like Intel blocks. Processes communicating through
signals is similar to CSP2.

These seem contradictory aims. You want to encourage code reuse, but not
reuse of syntax?

Good point. The goal here isn't really to encourage every programmer
go write custom syntax extensions. That would confuse all his co-
workers. However, in even small teams at individual companies, there
are often specific coding challenges they face that aren't well
supported in any specific language. For example, should imaginary
numbers be supported directly with custom syntax? I think there are
hundreds of application specific areas where custom syntax would be
nice, and if doable in libraries, it doesn't hurt to support them.

If you haven't created a language before, I would say this project was a
little over-ambitious. But good luck. Especially with the hot chicks.

Thanks for the feedback. Writing any new language can be fun, but you
have to be a huge optimist. I'll keep out some hope for the hot
chicks.

I've written several compilers and interpreters, but most never got
much use. I really enjoy it, and I realize the odds of any new
language being useful to very many people is exceedingly low. My
first computer language I wrote with a friend in 1983 on an Apple-II
e, which was similar to Forth, but jsr-linked as they say. I also
wrote a Prolog interpreter which convinced me never to program in
Prolog, and a Scheme interpreter which was great fun until all our
users refused to learn Scheme and started asking me to write all their
code. The scheme interpreter had list rewriting rules that allowed
most of the pretty syntax to be defined in terms of a core Scheme
language. This greatly simplified the language while adding power. I
didn't invent that - it's fairly standard for Scheme, but still very
cool. I thought it'd be fun to try that text rewriting trick in a
higher-level language using interpreted lex/yacc rules.

In the last few years, I chimed in on the D language forum and offered
some ideas to help Walter with his language. He's done a great job,
and D is a language near the top of those that I like, but D has
terrible memory layout (similar to C++ and Java), and further trashes
speed with garbage collection and wastes memory using 64-bit
pointers. I'm a speed-freak, so I'm not satisfied. I came to realize
that we programmers have too divers needs to be satisfied with any
single language, which is one reason C has such staying power. With
user-extensions in libraries, I hope to cover a lot more. For
example, if you really want garbage collection, go ahead. Put it in a
library and keep that crap away from me. Not a fan of object-oriented
programming? Then don't import the class module.

 

[Spiro Trikaliotis]

Hello,

although it gets OT:

<ot>


What is *the* wiki?

[...]

If I recall correctly it was the language used as I said above.

Are you sure you do not confuse it with SystemC?

http://en.wikipedia.org/wiki/SystemC

But this is more C, not C++.

</ot>

Regards,
Spiro.

 

[Bill Cox]

That's easy.
The speed of C is unspecified.
All you have to do,
is implement a slow C for comparison purposes.

Actually, the output of the 42 compiler (at least initially) will be C
and/or Verilog/VHDL. To compare, write the same program in C, then in
42, and use the same C compiler for both programs. The datadraw
benchmarks already prove that 42 can be faster than C.

 

[jameskuyper]

....
Actually, the output of the 42 compiler (at least initially) will be C
and/or Verilog/VHDL. To compare, write the same program in C, then in
42, and use the same C compiler for both programs. The datadraw
benchmarks already prove that 42 can be faster than C.

if 42 were indeed faster than C, that would mean that if I take the C
code generated by the 42 compiler, translate it back into equivalent
code for the "42" language, and compile it again, the result will be
even faster than the original. You can't achieve a higher speed than C
while using C as an intermediate step in the process. Your compiler
might make it easier to generate fast C code, but it is still fast C
code, not something that is "faster than C".

It's nonsense to claim that you can use

 

[JC]

Here you show your ignorance. I once had an interview with a company
that was using a C based language to compile to HW. Parallel C IIRC.
They showed me some real HW that had been built using FPGA's programmed
using it, kit that was actually for sale, so it does work.

Prototyping FPGA circuitry is typically done on an FPGA emulator
running on a more traditional multiprocessor (e.g. the CPU in your
desktop). Once it's proven that it works, circuitry is programmed into
a real FPGA. It's faster on the FPGA because it's actual hardware
designed to perform a task, not hardware designed to interpret byte
code to emulate hardware to perform a task. An FPGA is not a
microprocessor (although it can be if you program it as such).

Hopefully you are not using the speed difference between an emulated
FPGA and a real FPGA as evidence that you can write a language that
compiles to code that runs faster than C on a PC's multiprocessor. The
two platforms are entirely different.

On the other hand, if you stuck a bunch of FPGAs on a PCI card (e.g.),
you could probably design some sort of compiler for your language that
allowed a developer to offload various bits of logic to hardware.
However, I'd guess that most PCs have powerful enough hardware in them
already that such a project wouldn't really be practical, although it
might be interesting. Still, that is a feature of the target hardware,
not of the language itself.

Jason

 

[JC]

I already demonstrated how to do this with DataDraw, which has tons of
documentation athttp://datadraw.sf.net.  In short, slow programs that
take minutes to days to run typically thrash memory.  DataDraw backed
C has a far more optimized memory organization for cache performance
than standard C programs.  Check out the benchmarks on the datadraw
page.  For graph traversal, the DataDraw backed code ran 7X faster.

I see that claim on your site as well:

"DataDraw has been extensively benchmarked against the #1 rival for
EDA software development: C++ using the Standard Template Library. In
short DataDraw smokes C++/STL. In simple depth-first graph traversal,
the graph_benchmark example shows DataDraw based code runs over 15X
faster than the C++/STL version."

This, and the statistics in the table below it, are fairly vague and
unconvincing, as none of the implementation details are mentioned and
there is insufficient evidence to show that you used comparable
algorithms and techniques in all the test cases. I once saw a C vs. C+
+ "speed" comparison that compared a hash table implemented in C with
an RB-tree implemented in C++. Needless to say, it said nothing about
the languages themselves (the author was honest about that, however).

Also, are you claiming that DataDraw is "7x faster" than <language x>
for all tasks, or for traversing some sort of graph? DataDraw claims
to be "an ultra-fast persistent database for high performance programs
written in C", and so your comparison to the STL seems like apples and
oranges, as the STL does not provide persistent database services.

Anyways, I haven't actually seen or tried the benchmarks for myself.
I'm reserving judgment until I can find the test code used to perform
the benchmarks. I can't seem to find it (or I skipped right over it)
in the 'examples' directory. Where is the source for the three
implementations you compared in the benchmark table on the web site?

Jason

 

[Bill Cox]

if 42 were indeed faster than C, that would mean that if I take the C
code generated by the 42 compiler, translate it back into equivalent
code for the "42" language, and compile it again, the result will be
even faster than the original. You can't achieve a higher speed than C
while using C as an intermediate step in the process. Your compiler
might make it easier to generate fast C code, but it is still fast C
code, not something that is "faster than C".

It's nonsense to claim that you can use

To get the speed of DataDraw backed C in raw C, you have to give up
pointers and structures. If you can write a large complex data-
structure driven program with those limitations, you can match the
speed of DataDraw. Otherwise, it makes more sense to use DataDraw or
the wishfully thinking upcoming 42 compiler to help you write all that
indexed based access to individual arrays of properties without losing
your mind.

Just check out the benchmarks. Really. DataDraw backed C is way
faster than pointers-to-structures based code. http://datadraw.sf.net.

 

[Bill Cox]

I see that claim on your site as well:

"DataDraw has been extensively benchmarked against the #1 rival for
EDA software development: C++ using the Standard Template Library. In
short DataDraw smokes C++/STL. In simple depth-first graph traversal,
the graph_benchmark example shows DataDraw based code runs over 15X
faster than the C++/STL version."

This, and the statistics in the table below it, are fairly vague and
unconvincing, as none of the implementation details are mentioned and
there is insufficient evidence to show that you used comparable
algorithms and techniques in all the test cases. I once saw a C vs. C+
+ "speed" comparison that compared a hash table implemented in C with
an RB-tree implemented in C++. Needless to say, it said nothing about
the languages themselves (the author was honest about that, however).

Also, are you claiming that DataDraw is "7x faster" than <language x>
for all tasks, or for traversing some sort of graph? DataDraw claims
to be "an ultra-fast persistent database for high performance programs
written in C", and so your comparison to the STL seems like apples and
oranges, as the STL does not provide persistent database services.

Anyways, I haven't actually seen or tried the benchmarks for myself.
I'm reserving judgment until I can find the test code used to perform
the benchmarks. I can't seem to find it (or I skipped right over it)
in the 'examples' directory. Where is the source for the three
implementations you compared in the benchmark table on the web site?

Jason

Hi, Jason.

I challenge you to download DataDraw using:

svn co https://datadraw.svn.sourceforge.net/svnroot/datadraw/trunk
datadraw

Then, go to examples/graph_benchmark. There are other benchmarks you
can check as well. Type "make", and then:

[graph_benchmark] time ./c_graph
Process completed in 0:00:08
Used 972.37 MB of memory

real 0m8.673s
user 0m7.900s
sys 0m0.772s
[graph_benchmark]

I simply don't know how to argue about speed other than running
benchmarks. You can continue to deny all you like, but the memory
layout for C sucks. If you don't like to hear it, continue to pretend
that the benchmarks don't exist.

Bill

 

[Bill Cox]

I see that claim on your site as well:

"DataDraw has been extensively benchmarked against the #1 rival for
EDA software development: C++ using the Standard Template Library. In
short DataDraw smokes C++/STL. In simple depth-first graph traversal,
the graph_benchmark example shows DataDraw based code runs over 15X
faster than the C++/STL version."

This, and the statistics in the table below it, are fairly vague and
unconvincing, as none of the implementation details are mentioned and
there is insufficient evidence to show that you used comparable
algorithms and techniques in all the test cases. I once saw a C vs. C+
+ "speed" comparison that compared a hash table implemented in C with
an RB-tree implemented in C++. Needless to say, it said nothing about
the languages themselves (the author was honest about that, however).

Also, are you claiming that DataDraw is "7x faster" than <language x>
for all tasks, or for traversing some sort of graph? DataDraw claims
to be "an ultra-fast persistent database for high performance programs
written in C", and so your comparison to the STL seems like apples and
oranges, as the STL does not provide persistent database services.

Anyways, I haven't actually seen or tried the benchmarks for myself.
I'm reserving judgment until I can find the test code used to perform
the benchmarks. I can't seem to find it (or I skipped right over it)
in the 'examples' directory. Where is the source for the three
implementations you compared in the benchmark table on the web site?

Jason

Hi, Jason.

I challenge you to download DataDraw using:

svn co https://datadraw.svn.sourceforge.net/svnroot/datadraw/trunk
datadraw

Then, go to examples/graph_benchmark. There are other benchmarks you
can check as well. Type "make", and then:

[graph_benchmark] time ./c_graph
Process completed in 0:00:08
Used 972.37 MB of memory

real 0m8.673s
user 0m7.900s
sys 0m0.772s
[graph_benchmark]

I simply don't know how to argue about speed other than running
benchmarks. You can continue to deny all you like, but the memory
layout for C sucks. If you don't like to hear it, continue to pretend
that the benchmarks don't exist.

Bill

 

[JC]

Hi, Jason.

I challenge you to download DataDraw using:

    svn cohttps://datadraw.svn.sourceforge.net/svnroot/datadraw/trunk
datadraw

Will do, thanks; the benchmarks were not in the non-svn tarball.

Then, go to examples/graph_benchmark.  There are other benchmarks you
can check as well.  Type "make", and then:

[graph_benchmark] time ./c_graph
Process completed in 0:00:08
Used 972.37 MB of memory

real    0m8.673s
user    0m7.900s
sys     0m0.772s
[graph_benchmark]

I simply don't know how to argue about speed other than running
benchmarks.  You can continue to deny all you like, but the memory
layout for C sucks.  If you don't like to hear it, continue to pretend
that the benchmarks don't exist.

I don't believe or disbelieve you, however if the benchmarks are
invalid, then they might as well not exist.

You say you do not know how to argue about speed other than running
benchmarks. One important thing to remember to do when arguing about
speed is to provide evidence that your benchmarks are both meaningful
and applicable to relevant situations. Also, the issues raised in my
post above were rather important, ignoring them entirely, as you did,
is not convincing. You may consider going back and responding to them.

I'm pretty open-minded and very curious about it, and will run the
DataDraw benchmarks tonight and see what happens. It looks like a
promising technology if it does what you claim (although I'm still not
sure what you claim -- your benchmarks, if they are true, show that a
database framework can traverse graphs faster than a native
implementation in C, which means... what?). However, the tone (appears
exaggerated, somewhat abrasive in your responses) and content
(benchmark numbers with no rationale) of your claims make them rather
hard to believe, and you may consider taking a slightly more
professional approach.

Jason

 

[Bill Cox]

To get the speed of DataDraw backed C in raw C, you have to give up
pointers and structures.  If you can write a large complex data-
structure driven program with those limitations, you can match the
speed of DataDraw.  Otherwise, it makes more sense to use DataDraw or
the wishfully thinking upcoming 42 compiler to help you write all that
indexed based access to individual arrays of properties without losing
your mind.

Just check out the benchmarks.  Really.  DataDraw backed C is way
faster than pointers-to-structures based code.  http://datadraw.sf.net.

Grr. Sorry Jason. I'm web-browser challenged this afternoon, which
may have to do with just finishing lunch over some really good beer
with a bunch of geek friends of mine to discuss things like 42, and
other topics that friends are working on. Instead of posting the full
message I meant to, I posted the first half twice! No, it wasn't
me... it was Google! Really! (Bill slinks into cave for a while)

After doing "make" in the examples/graph_benchmark directory, you can
run c_graph (the DataDraw backed benchmark) and compare it to
rawc_graph (the raw C benchmark). The output:

[graph_benchmark] time ./rawc_graph

real 0m57.412s
user 0m56.664s
sys 0m0.700s
[graph_benchmark] time c_graph
Process completed in 0:00:08
Used 972.37 MB of memory

real 0m8.617s
user 0m7.832s
sys 0m0.768s
[graph_benchmark]

This isn't the worst benchmark for DataDraw. It's one of the best.
However, I've done extensive testing for years on memory intensive
applications, and can confidently state that you can expect a 20%
speed improvement or better on almost any memory intensive algorithm.
It's not 7X in general, but still faster than C.

Bill