Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beating C with one line of Brainfuck

kiwec.net

Post reply on HN
Print view View original

51–60 of 91 posts

Re: Beating C with one line of Brainfuck

#51

Post by ddalex »

paulddraper wrote: post #46
justinator wrote: post #43

It seems we've beat the webserver serving this blog with one hug from HN.

There must be way more people reading HN than I would think. Here we are 7 hours after post, overloading it. Suppose "overloading" this blog is a mere 2 requests/s. Suppose that an entire 10% of people reading HN click on this link, and on average click on it twice. Further suppose that the average "active" HN user reads HN 5 times a week. That means there are 1,210,000 active HN readers.

Thanks for the math!

I did several estimations of How-Many-of-Us-are-Here and I got ~1M users by various methods (eg number of upvotes using Reddit engagement numbers), so I'll take your number with a happy confirmation bias.

Re: Beating C with one line of Brainfuck

#53

Post by acqq »

jacquesm wrote: post #48
codetrotter wrote: post #42

Earlier quoted context omitted.

I guess what jacquesm was getting at was that instead of extending C, the world should have left C behind a long time ago and transitioned to other, safer languages. These days there are excellent alternatives to C, but of course we also have vast codebases written in C that would be too big of an undertaking and too much of a risk to rewrite in a safer language. There may not have been any sufficiently widespread al…

I'm somewhere in the middle. I love my C compiler. At the same time I recognize the limitations of a lanuage that is now well in it's 5th decade. The problem is that we have so much tooling and of such high quality that it is hard to switch to anything else. For myself mostly because of habit, existing libraries and speed of compilation. The edit-compile-test cycle length is a very high factor in my productivity. Go…

> in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick

Note however that even the those languages promoted as "safer" and "better" at the end typically use the C implementations of cryptographic routines (or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"). I see then some "wrappers" but at the end... it's still C (or assembly) that does the job. As far as I'm aware, nobody managed to produce both the "safety" and everything else necessary to the point to be the "best" solution for real-life use cases.

Re: Beating C with one line of Brainfuck

#54

Post by lgeorget »

throw_m239339 wrote: post #37

> Following on the recent “faster than wc” blogposts, I decided to end this fad once and for all, using the best language ever created : Brainfuck. This "Go faster than C" post was a complete joke, one could very easily write a "C faster than C" the exact same way to prove the absurdity of an optimized implementation that does not do what the original program does.

This blog post also does that actually since the Brainfuck code is transpiled to C.

Re: Beating C with one line of Brainfuck

#56

Post by Dylan16807 »

acqq wrote: post #53
jacquesm wrote: post #48

Earlier quoted context omitted.

I'm somewhere in the middle. I love my C compiler. At the same time I recognize the limitations of a lanuage that is now well in it's 5th decade. The problem is that we have so much tooling and of such high quality that it is hard to switch to anything else. For myself mostly because of habit, existing libraries and speed of compilation. The edit-compile-test cycle length is a very high factor in my productivity. Go…

> in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick Note however that even the those languages promoted as "safer" and "better" at the end typically use the C implementations of cryptographic routines (or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"). I see…

I bet that's almost entirely based on preferring the devil you know. Trying to write C without side channels is a ridiculously fragile affair. Many high level languages aren't suited to it, but that doesn't mean C is suited to it. Nobody should be using C for that kind of code either. Assembly maybe. The good answer is a language that can handle arrays safely and also make guarantees about what's actually executed.

Re: Beating C with one line of Brainfuck

#57

Post by kiwec »

JoshMcguigan wrote: post #12

Is the 85MB test file available? I wasn't able to find it. I'd like to test this result against nerve [0], a brainfuck to x86_64 asm compiler I wrote (like funkicrab, it is also written in Rust). [0]: https://github.com/JoshMcguigan/nerve

After editing my code to use EOF == 0, I get :

    19.55 user 21.49 system 0:41.13 elapsed
However, you're using 8-bit cells, so the resulting word count is incorrect. In case you're wondering, the file was generated with :

    python3 -m faker -o words.txt text -r [large number] -s '\n'

Re: Beating C with one line of Brainfuck

#58

Post by kiwec »

re wrote: post #10
readingnews wrote: post #9

I wonder if Brainfuck wins by his 100th of a second since he already called a program with words.txt, and therefore it was already loaded into memory, thus saving just a slice of time, as it would already be in the cache.

Could also be that their version of wc is doing Unicode-aware counting by default; it could be a lot faster with LANG=C set in the environment. https://unix.stackexchange.com/a/96580

For some reason, wc is even slower with LANG=C.

    cat words.txt | time wc -w
    13018291
    0.76 user 0.01 system 0:00.78 elapsed
That's on the default wc build of void linux, and not in a proper benchmark environment, but that's still strange.

Re: Beating C with one line of Brainfuck

#59

Post by shakna »

klyrs wrote: post #28
readingnews wrote: post #9

I wonder if Brainfuck wins by his 100th of a second since he already called a program with words.txt, and therefore it was already loaded into memory, thus saving just a slice of time, as it would already be in the cache.

For a #shitpost, one need only observe the fastest run of program A being faster than the slowest run of program B, to declare A is faster than B. With a sufficiently powerful static evaluator, you could embed the input into the program and get an even faster runtime.

> With a sufficiently powerful static evaluator, you could embed the input into the program and get an even faster runtime.

If you feel the need to cheat, you could do something like I used for dumb_cat [0] and dump the resulting executables into a cache somewhere.

[0] https://git.sr.ht/~shakna/dumb_cat

Re: Beating C with one line of Brainfuck

#60

Post by stiray »

I love it!!!

It is a great parody on latest trends in "my favorite xy language is faster than 'c/c++", each time I see one of those, it sends shivers down my spine.

Your language, that was made in c/c++, can hardly be faster than the language it was written in. Whatever optimizations it has, you can still make them in c/c++ with enough knowlidge, but probably you can optimize it some more (staring at c++ template metaprogramming) or use __asm or execute opcodes directly (cheating :D) The only question here is how good can the "compiler" be in making optimal cpu instructions from "your" language.

Stop this evangelist wars, your language can be great due to some other features (ease of use, knowlidge needed to be proficient in it, forgiveness of mistakes,..), you dont need to compare it to c/c++. It just doesnt make any sense.

Post reply on HN