Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Look, you are doing what I've just said not to do. I have nothing to say because the OP did most of claims already, you should directly respond to the OP.

And you are slightly altering the very claim you've already said; the OP specificially tests the claim that "V compiles [...] ~1 million (x86 and tcc backends) lines of code per second per CPU core", which I can easily verify on my machine (1m_helloworld.v took 25.5 and 15.5 seconds to compile under the same settings). To be fair these test files are edge cases you can easily dismiss (ProTip: you can make your advertisements more accurate), but edge cases show the weakness of your design and you should not confront them.



You made a claim:

> extraordinary claims failed V.

I asked you to list such claims. You fail to do so.

There's no way it takes 15s to compile 1m_helloworld.v. You're probably using a debug build of V.

What's your hardware? CPU/SSD.


> There's no way it takes 15s to compile 1m_helloworld.v. You're probably using a debug build of V.

You don't have to guess because I can give you my log. I have exactly followed what the OP did, except for more recent revision because I couldn't get it compiled in my environment.

    $ git clone https://github.com/vlang/v/
    $ cd v
    $ git checkout 0e4198f23b2b9a52d72f61dd40d019412b809791

    $ VFLAGS="-prod" make
    make fresh_vc
    make[1]: Entering directory '/tmp/v'
    rm -rf ./vc
    git clone --depth 1 --quiet --single-branch https://github.com/vlang/vc ./vc
    make[1]: Leaving directory '/tmp/v'
    cd ./vc && git clean -xf && git pull --quiet
    make fresh_tcc
    make[1]: Entering directory '/tmp/v'
    rm -rf ./thirdparty/tcc
    git clone --depth 1 --quiet --single-branch --branch thirdparty-linux-amd64 https://github.com/vlang/tccbin ./thirdparty/tcc
    make[2]: Entering directory '/tmp/v'
    make[2]: Leaving directory '/tmp/v'
    make[1]: Leaving directory '/tmp/v'
    cd ./thirdparty/tcc && git clean -xf && git pull --quiet
    cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread
    ./v1.exe -no-parallel -o v2.exe -prod cmd/v
    ./v2.exe -o ./v -prod cmd/v
    rm -rf v1.exe v2.exe
    Note: building an optimized binary takes much longer. It shouldn't be used with `v run`.
    Use `v run` without optimization, or build an optimized binary with -prod first, then run it separately.

    Note: `tcc` was not used, so unless you install it yourself, your backend
    C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

    These C compilers, are several times slower at compiling C source code,
    compared to `tcc`. They do produce more optimised executables, but that
    is done at the cost of compilation speed.

    V has been successfully built
    V 0.2.4 0e4198f

    $ cat > t.sh && chmod a+x t.sh && ./t.sh > 1m_helloworld.v
    #!/bin/bash
    echo 'fn main() {'
    for i in {3..1000000}
    do
        echo '    println("hello world")'
    done
    echo '}'

    $ time ./v 1m_helloworld.v
    parsed 100000 statements so far from fn main.main ...
    parsed 200000 statements so far from fn main.main ...
    parsed 300000 statements so far from fn main.main ...
    parsed 400000 statements so far from fn main.main ...
    parsed 500000 statements so far from fn main.main ...
    parsed 600000 statements so far from fn main.main ...
    parsed 700000 statements so far from fn main.main ...
    parsed 800000 statements so far from fn main.main ...
    parsed 900000 statements so far from fn main.main ...

    real    0m14.929s
    user    0m6.516s
    sys     0m8.031s
I have also verified that TCC was indeed in use:

    $ mv thirdparty/tcc/tcc.exe thirdparty/tcc/tcc.exe.orig

    $ time ./v 1m_helloworld.v
    parsed 100000 statements so far from fn main.main ...
    parsed 200000 statements so far from fn main.main ...
    parsed 300000 statements so far from fn main.main ...
    parsed 400000 statements so far from fn main.main ...
    parsed 500000 statements so far from fn main.main ...
    parsed 600000 statements so far from fn main.main ...
    parsed 700000 statements so far from fn main.main ...
    parsed 800000 statements so far from fn main.main ...
    parsed 900000 statements so far from fn main.main ...
    ==================
    cc: internal compiler error: Killed (program cc1)
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
    ...
    ==================
    (Use `v -cg` to print the entire error message)

    builder error:
    ==================
    C error. This should never happen.

    This is a compiler bug, please report it using `v bug file.v`.

    https://github.com/vlang/v/issues/new/choose

    You can also use #help on Discord: https://discord.gg/vlang


    real    6m50.090s
    user    6m8.375s
    sys     0m31.094s
(I gave up when the gcc memory usage ballooned up to 20 GB.)

> What's your hardware? CPU/SSD.

i7-7700 3.60 GHz, 48 GB of RAM, SSD in use, Windows 10 WSL (that's probably why kernel time is higher than average, otherwise my userland time agrees with the OP).


You're not using the tcc backend.

It says

Note: `tcc` was not used, so unless you install it yourself, your backend C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

Also you have "gcc" in your error:

See <file:///usr/share/doc/gcc-7/README.Bugs>

And on the website the claim is made for tcc and x64 backends.

Like I said, no way it'd take 15 seconds :)


If I was not using the tcc backend for the first execution, then why would the second execution without tcc.exe be timed out? (I have also checked strace just like the OP.) It seems unlikely that the first execution and the second execution use the same gcc and still behave in such diverging ways. And if my reasoning is incorrect, please do not instinctively reply to me (I had enough) and put a proper diagnostic to tell whether TCC is being used, since it looks like a genuine confusion.


You're not using tcc, because the language literally tells you so, you get a GCC error, and you get 10x slower compilation time.

I think it's pretty clear.

Anyway, now that we are clear on the compilation speed claim, can you please list a couple of those extraordinary claims?


Did you even bother to read what he pasted? Tcc is used in the first set of commands that do not terminate.


He is in fact reading it, please look again at what he pasted. It really seems somehow you're getting your wires crossed.


No he didn't understand at all. Both the OP and I'm saying that while `make` claims that tcc was not used, the compiler does seem to use tcc even in that case. I have demonstrated that this is a plausible explanation by moving the tcc binary and showing the stark performance difference.

(This is my final response on this matter. I have already given enough information and an inability to interpret it is not my business.)


I admit I misread, and you do indeed use TCC.

I've just tested it, and turns out all C compilers are terrible at hundreds of thousands of print calls (for me Clang was stuck for minutes with 100% cpu usage).

The claim was made about actual code, like the V compiler itself, which is about 220k loc and compiles in 0.3 seconds, not some unrealistic test with a million of prints.

I'll make it clear on the home page with a link to the benchmark.


Understandable to misread - I, funnily, did as well as I was quickly going down through the original comment + replies.


[flagged]


Human decency is a foreign concept to a lot of folks, eh?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: