Another crazy new language effort - Language #42

Discussion in 'C Programming' started by xyzzybill@gmail.com, Jan 2, 2009.

  1. Guest

    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.
    , Jan 2, 2009
    #1
    1. Advertising

  2. James Harris Guest

    On 2 Jan, 09:59, 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
    James Harris, Jan 2, 2009
    #2
    1. Advertising

  3. jacob navia Guest

    wrote:
    > 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
    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Jan 2, 2009
    #3
  4. Bill Cox Guest

    On Jan 2, 5:42 am, jacob navia <> wrote:
    > > The language is called 42, and has the following insane goals:

    >
    > > - Run faster than C

    >
    > 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.

    > > - Foster extreme code reuse

    >
    > 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.

    > > - 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.


    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.

    > > - 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.


    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.

    > > - 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!


    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.

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

    >
    > Yes it is.


    Thanks.
    Bill Cox, Jan 2, 2009
    #4
  5. Bartc Guest

    wrote:
    > 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.

    --
    Bartc
    Bartc, Jan 2, 2009
    #5
  6. Flash Gordon Guest

    jacob navia wrote:
    > wrote:


    <snip>

    >> - 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.


    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.
    --
    Flash Gordon
    Flash Gordon, Jan 2, 2009
    #6
  7. jacob navia Guest

    Bill Cox wrote:
    >>> - 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.

    >
    > 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
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Jan 2, 2009
    #7
  8. jacob navia Guest

    Flash Gordon wrote:
    > jacob navia wrote:
    >> wrote:

    >
    > <snip>
    >
    >>> - 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.

    >
    > 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.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Jan 2, 2009
    #8
  9. Flash Gordon Guest

    jacob navia wrote:
    > Flash Gordon wrote:
    >> jacob navia wrote:
    >>> wrote:

    >>
    >> <snip>
    >>
    >>>> - 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.

    >>
    >> 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.


    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 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.


    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.

    >> 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?


    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.

    >> 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.


    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.
    --
    Flash Gordon
    Flash Gordon, Jan 2, 2009
    #9
  10. Bill Cox Guest

    On Jan 2, 6:34 am, "Bartc" <> wrote:
    > wrote:
    > > 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.


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

    > > 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.


    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.

    > > - 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?


    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.

    > > - 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?


    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.
    Bill Cox, Jan 2, 2009
    #10
  11. Hello,

    although it gets OT:

    <ot>

    Flash Gordon wrote:
    > jacob navia wrote:
    >> Flash Gordon wrote:
    >>> Parallel C IIRC.

    >>
    >> "Parallel C" according to the wiki is:


    What is *the* wiki?

    [...]
    >
    >> 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.


    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.

    --
    Spiro R. Trikaliotis http://opencbm.sf.net/
    http://www.trikaliotis.net/ http://www.viceteam.org/
    Spiro Trikaliotis, Jan 2, 2009
    #11
  12. Bill Cox Guest

    On Jan 2, 8:30 am, pete <> wrote:
    > wrote:
    > > 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

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


    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.
    Bill Cox, Jan 2, 2009
    #12
  13. jameskuyper Guest

    Bill Cox wrote:
    > On Jan 2, 8:30�am, pete <> wrote:
    > > wrote:
    > > > 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

    ....
    > 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
    jameskuyper, Jan 2, 2009
    #13
  14. JC Guest

    On Jan 2, 6:51 am, Flash Gordon <> wrote:
    > jacob navia wrote:
    > > wrote:

    >
    > <snip>
    >
    > >> - 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.

    >
    > 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, Jan 2, 2009
    #14
  15. JC Guest

    On Jan 2, 6:03 am, Bill Cox <> wrote:
    > On Jan 2, 5:42 am, jacob navia <> wrote:
    >
    > > > The language is called 42, and has the following insane goals:

    >
    > > > - Run faster than C

    >
    > > Any ideas on how would you achieve this?

    >
    > 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
    JC, Jan 2, 2009
    #15
  16. Bill Cox Guest

    On Jan 2, 11:33 am, jameskuyper <> wrote:
    > Bill Cox wrote:
    > > On Jan 2, 8:30 am, pete <> wrote:
    > > > wrote:
    > > > > 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

    > ...
    > > 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


    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, Jan 2, 2009
    #16
  17. Bill Cox Guest

    On Jan 2, 12:51 pm, JC <> wrote:
    > On Jan 2, 6:03 am, Bill Cox <> wrote:
    >
    > > On Jan 2, 5:42 am, jacob navia <> wrote:

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

    >
    > > > > - Run faster than C

    >
    > > > Any ideas on how would you achieve this?

    >
    > > 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


    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, Jan 2, 2009
    #17
  18. Bill Cox Guest

    On Jan 2, 12:51 pm, JC <> wrote:
    > On Jan 2, 6:03 am, Bill Cox <> wrote:
    >
    > > On Jan 2, 5:42 am, jacob navia <> wrote:

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

    >
    > > > > - Run faster than C

    >
    > > > Any ideas on how would you achieve this?

    >
    > > 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


    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, Jan 2, 2009
    #18
  19. JC Guest

    On Jan 2, 3:55 pm, Bill Cox <> wrote:
    > On Jan 2, 12:51 pm, JC <> wrote:
    >
    >
    >
    > > On Jan 2, 6:03 am, Bill Cox <> wrote:

    >
    > > > On Jan 2, 5:42 am, jacob navia <> wrote:

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

    >
    > > > > > - Run faster than C

    >
    > > > > Any ideas on how would you achieve this?

    >
    > > > 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

    >
    > 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
    JC, Jan 2, 2009
    #19
  20. Bill Cox Guest

    On Jan 2, 3:49 pm, Bill Cox <> wrote:
    > On Jan 2, 11:33 am, jameskuyper <> wrote:
    >
    >
    >
    > > Bill Cox wrote:
    > > > On Jan 2, 8:30 am, pete <> wrote:
    > > > > wrote:
    > > > > > 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

    > > ...
    > > > 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

    >
    > 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
    Bill Cox, Jan 2, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bluke
    Replies:
    3
    Views:
    372
    Tricia Bushnell
    Sep 4, 2003
  2. Corey B
    Replies:
    3
    Views:
    405
    Corey B
    Jan 17, 2007
  3. Just Me
    Replies:
    11
    Views:
    675
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=
    Feb 24, 2007
  4. consultant

    C Ebooks, Itz my effort

    consultant, May 2, 2007, in forum: C Programming
    Replies:
    3
    Views:
    351
  5. Bill Cunningham

    printig effort

    Bill Cunningham, Jun 8, 2008, in forum: C Programming
    Replies:
    45
    Views:
    1,152
    santosh
    Jun 11, 2008
Loading...

Share This Page