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

21–30 of 91 posts

Re: Beating C with one line of Brainfuck

#21

Post by jacquesm »

zabzonk wrote: post #19
jacquesm wrote: post #17

Earlier quoted context omitted.

(base) jam@jam-XPS-8500:~/svn/src/music/mp3tomidi$ cc -c -Wall x.c (base) jam@jam-XPS-8500:~/svn/src/music/mp3tomidi$ cat x.c #define OUTPUTS 0 char outputs[OUTPUTS] = { }; Looks like you're wrong about that; at least for GNU C. It's not official C but if it works and generates no warnings it will be used too. Long HN thread about this subject: https://news.ycombinator.com/item?id=11674374 Zero length arrays are one…

[neilb@Miranda temp]$ gcc -Wall -Wextra -pedantic a.c a.c:2:6: warning: ISO C forbids zero-size array 'outputs' [-Wpedantic] char outputs[OUTPUTS] = { };

Yes, the -pedantic is what will trigger that. See linked post. But that's not on by default (fortunately!).

ISO C is so restrictive ;)

Re: Beating C with one line of Brainfuck

#23

Post by yitchelle »

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.

To avoid the caching bias, I think a fairer test condition would be to use multiple files and do it over a number of times. The lowest average time would be the winner.

Re: Beating C with one line of Brainfuck

#24

Post by zabzonk »

jacquesm wrote: post #21
zabzonk wrote: post #19

Earlier quoted context omitted.

[neilb@Miranda temp]$ gcc -Wall -Wextra -pedantic a.c a.c:2:6: warning: ISO C forbids zero-size array 'outputs' [-Wpedantic] char outputs[OUTPUTS] = { };

Yes, the -pedantic is what will trigger that. See linked post. But that's not on by default (fortunately!). ISO C is so restrictive ;)

> (fortunately!)

Unfortunately. All warnings and errors should be on by default. That they are not is one of the things about GCC that really pisses me off.

Re: Beating C with one line of Brainfuck

#26

Post by shakna »

lilyball wrote: post #15
return_0e wrote: post #8

Earlier quoted context omitted.

Not an optimising one (yet) but a safe implementation of a malbolge interpreter written in Rust, which can run malbolge programs. Just for fun. https://github.com/return/malbolge

Has anyone used Rust to write an interpreter for INTERCAL yet?

Of course. [0]

[0] https://github.com/birkenfeld/rick

Re: Beating C with one line of Brainfuck

#27

Post by sharedfrog »

yitchelle wrote: post #23
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.

To avoid the caching bias, I think a fairer test condition would be to use multiple files and do it over a number of times. The lowest average time would be the winner.

You can manually clear the cache:

`echo 3 | sudo tee /proc/sys/vm/drop_caches`

Re: Beating C with one line of Brainfuck

#28

Post by klyrs »

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.

Re: Beating C with one line of Brainfuck

#29

Post by s_gourichon »

Given the humorous setup and experiment report, I would bet one second of my life that maybe the guy ran the test with a few random files passing by, and mentioned only the one that just happened to be slightly faster in brainfuck.

I think I got the joke, it had me chuckle anyway.

Re: Beating C with one line of Brainfuck

#30

Post by jacquesm »

zabzonk wrote: post #24
jacquesm wrote: post #21

Earlier quoted context omitted.

Yes, the -pedantic is what will trigger that. See linked post. But that's not on by default (fortunately!). ISO C is so restrictive ;)

> (fortunately!) Unfortunately. All warnings and errors should be on by default. That they are not is one of the things about GCC that really pisses me off.

Still not getting the joke.

Yes, they should be on, in fact GCC should not do this, 'extensions' to a language that invite undefined behavior are not in line with solid software development practices. Neither is brainfuck...

Post reply on HN