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

71–80 of 91 posts

Re: Beating C with one line of Brainfuck

#71

Post by stiray »

randomsearch wrote: post #62
stiray wrote: post #60

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

> Your language, that was made in c/c++, can hardly be faster than the language it was written in What if the language you wrote includes a run-time that does JIT?

This would be "equivalent" but as jit has to process it first (overhead) and code here is just executing binary code, it will be faster. I am not talking here about readability, how much knowlidge is behind etc.

#include char code[] = "\x01\xb8\x00\x00\xbb\x00\x00\x2a\x00\x00\x80\xcd\x00";

int main(int argc, char argv) { int (func)(); func = (int ()()) code; (int)(*func)();

return 0; }

This whole sharade of how fast the language is a nonsense. There are other metrics that are more important TODAY, the industry needs languages that are maintainable, can be used by cheap workforce that is simple to find anywhere and dont need to know much about computers, memory,... but rather about a problem. Why picking on c/c++ which is not solving any of those problems is such a trendy topic today, is beyond my understanding.

Re: Beating C with one line of Brainfuck

#72

Post by randomsearch »

stiray wrote: post #71
randomsearch wrote: post #62

Earlier quoted context omitted.

> Your language, that was made in c/c++, can hardly be faster than the language it was written in What if the language you wrote includes a run-time that does JIT?

This would be "equivalent" but as jit has to process it first (overhead) and code here is just executing binary code, it will be faster. I am not talking here about readability, how much knowlidge is behind etc. #include char code[] = "\x01\xb8\x00\x00\xbb\x00\x00\x2a\x00\x00\x80\xcd\x00"; int main(int argc, char argv) { int ( func)(); func = (int ( )()) code; (int)(*func)(); return 0; } This whole sharade of how fas…

> code here is just executing binary code, it will be faster

No it won't. JIT-ed code can take into account dynamic information, and therefore outperform even the best general static compiler.

Re: Beating C with one line of Brainfuck

#73

Post by randomsearch »

IcePic wrote: post #66
randomsearch wrote: post #62

Earlier quoted context omitted.

> Your language, that was made in c/c++, can hardly be faster than the language it was written in What if the language you wrote includes a run-time that does JIT?

and the JIT is written in...

The JIT compiler is written in C.

Its output is assembly code.

That assembly code can outperform code written in C, because it has access to dynamic run time information that your C compiler does not.

Re: Beating C with one line of Brainfuck

#74

Post by [deleted] »

randomsearch wrote: post #72
stiray wrote: post #71

Earlier quoted context omitted.

This would be "equivalent" but as jit has to process it first (overhead) and code here is just executing binary code, it will be faster. I am not talking here about readability, how much knowlidge is behind etc. #include char code[] = "\x01\xb8\x00\x00\xbb\x00\x00\x2a\x00\x00\x80\xcd\x00"; int main(int argc, char argv) { int ( func)(); func = (int ( )()) code; (int)(*func)(); return 0; } This whole sharade of how fas…

> code here is just executing binary code, it will be faster No it won't. JIT-ed code can take into account dynamic information, and therefore outperform even the best general static compiler.

[deleted]

Re: Beating C with one line of Brainfuck

#75

Post by stiray »

randomsearch wrote: post #72
stiray wrote: post #71

Earlier quoted context omitted.

This would be "equivalent" but as jit has to process it first (overhead) and code here is just executing binary code, it will be faster. I am not talking here about readability, how much knowlidge is behind etc. #include char code[] = "\x01\xb8\x00\x00\xbb\x00\x00\x2a\x00\x00\x80\xcd\x00"; int main(int argc, char argv) { int ( func)(); func = (int ( )()) code; (int)(*func)(); return 0; } This whole sharade of how fas…

> code here is just executing binary code, it will be faster No it won't. JIT-ed code can take into account dynamic information, and therefore outperform even the best general static compiler.

I have written the (bogus) code in assembler and executed it using C, there is nothing compiled about it. Without any dynamic information as there is nothing dynamic about it. There is nothing to outperform/optimize it will run at max speed on specific architecture. Compiler is only involved to do a 'call'. Same as with JIT. But hand optimized.

Let me repeat it, stop this stupid evangelist wars. They are nonsense. Who cares about C speed when the lasagna with spaghetti frameworks are run on daily bases. Speed is irelevant today for almost all cases as no one is prepared to pay for it. And nobody cares about those left.

Re: Beating C with one line of Brainfuck

#77

Post by labawi »

kiwec wrote: post #58
re wrote: post #10

Earlier quoted context omitted.

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.

I prefer setting LC_ALL=C for to be sure, though LANG may be sufficient, as running "LANG=C locale" confirms LC_CTYPE=C is set.

Re: Beating C with one line of Brainfuck

#79

Post by shultays »

zabzonk wrote: post #11
NilsIRL wrote: post #6

Generated C: #include char mem[30000] = { }; #define OUTPUTS 0 char outputs[OUTPUTS] = { }; int main() { char* ptr = mem + 0; fwrite(outputs, sizeof(char), OUTPUTS, stdout); ptr[2] = getchar(); ++ptr[2]; while (ptr[2]) { ptr[2] -= 11; while (ptr[2]) { ptr[2] -= 22; while (ptr[2]) { ++ptr[3]; --ptr[1]; while (ptr[1]) { ++*ptr; ++ptr[1]; } ptr[2] = 0; } ptr[2] = 0; } ptr[1] = 0; ptr[1] += ptr[3] * 1; ptr[3] = 0; ptr[2]…

Note that: #define OUTPUTS 0 char outputs[OUTPUTS] = { }; is not valid C (or C++) - zero length arrays are not a thing in either language,

what it is being used for? I can't figure what that fwrite part does
Post reply on HN