Challenge: fastest program wins

Write a program in your language that
1.opens a file as arbitrary precision integer.
2.divides the number by 3.
3.stores the binary result in another file.

>>40
drivers

>>41
what about them?

>>42
They're nice

$ cat file1.txt
1726721657861278561278567182657861278612786781265786215786172765782167856217865726178567126578216587217856782165782178467821647862178462178471286478612746217864


$ time java Lol

real             0m0.199s
user             0m0.109s
sys              0m0.045s


$ time ./div3 file1.txt div3.out

real 0m0.003s
user 0m0.001s
sys  0m0.003s


$ gcc -c post23.c -o post23 file1.txt post23.out
post22.c:3:17: error: gmp.h: No such file or directory
post22.c: In function 'main':
post22.c:8: error: 'mpz_t' undeclared (first use in this function)
post22.c:8: error: (Each undeclared identifier is reported only once
post22.c:8: error: for each function it appears in.)
post22.c:8: error: syntax error before 'n'
post22.c:9: error: 'n' undeclared (first use in this function)


$ time ./post23
-bash: ./post23: No such file or directory

real    0m0.002s
user    0m0.000s
sys     0m0.002s

WE HAVE A WINNER

SEX

>>44
Two milliseconds to run an inexistent program? cygwin is faster than that!

>>46
Enjoy your bloat

>>47
Cygwin is smaller than Java.

>>44
try compiling and running the java one without java installed.
it'll work about as well as the gmp one without gmp installed.

I don't want to install the GNU Image Manipulation Program

>>50
I think you accidentally posted in the wrong thr^H^H^Hboard.

>>50
it's GIMP Image Manipulation Program

This problem was built for Haskell

>>52
Did you mean /progImage Manipulation Program, also known as PIMP?

>>44
Now try it with a file of multiple GB size, and see which one wins. I bet my cock it'll be >>35.

>>16
Python is much slower than C

>>55
I am the author of >>20, and I think you meant "I bet my cock it'll be >>20".

>>56
How is babby formed

Benchmark with one-megabyte file:

$ time python3.0 16.py in.txt out.txt

real    1m14.621s
user    1m11.377s
sys    0m2.338s
$ time java Lol /* 20 */

real    0m45.685s
user    0m43.816s
sys    0m1.308s
$ time ./23 in.txt out.txt

real    0m2.834s
user    0m2.114s
sys    0m0.157s
$ time ./35 in.txt out.txt

real    0m0.049s
user    0m0.037s
sys    0m0.010s

from sys import argv
from gmpy import mpz

open(argv[2], 'w').write(str(mpz(open(argv[1], 'r').read()) // 3))

$ time python 60.py in.txt out.txt

real    0m2.455s
user    0m2.278s
sys    0m0.159s

>>60
Typical python hack.
What of you want to change the divisor? What if you need to operate on a directory full of such files?

>>61
Don't optimize early. Optimize when you're certain of the bottleneck's location(s).

>>61
from sys import argv
from gmpy import mpz

div = int(argv[1])

for i in range(len(argv[2:])):
    open(argv[i+1], 'w').write(str(mpz(open(argv[i], 'r').read()) // div))

Troll harder, kid.

from sys import argv
from gmpy import mpz

div = int(argv[1])

for i in range(2, len(argv)-1):
    open(argv[i+1], 'w').write(str(mpz(open(argv[i], 'r').read()) // div))

Just when I thought I was so cool…

>>62
EXPERT ADVICE

That would make a great fortune cookie.

tl;dr I whine about faggoty reddit programmer types
>>65
I'm weary of hearing people say 'don't optimize early...', not because it is bad advice, but because it is often their way of saying "I don't like optimizing...all optimizing is bad...it's the compilers job...who cares, computers are always getting faster". I find this attitude to be unscientific and ultimately destructive, it pushes the burden of technological advance to the Electrical/Electronic Engineers(and they do a fantastic job of it) instead of the programmers. I fear that programming is destined to splinter into different levels, with the majority on the highest levels(web apps etc) completely ignorant of any low level details, all the while berating compiler-writers and other low-level programmer types for being too performance-oriented.

>>66
The point is to first know where is bottleneck and then optimize the bottleneck. Don't pre-optimize code on the basis of guessing where a bottleneck might be before you have even written some code; if you don't have an intimate knowledge of the problem domain, you should first write then profile the program. The optimization strategies I currently possess came about by first writing naive code then doing some deep analysis about what my naive code is actually doing.

>>59
Benchmarks don't mean much when none of them are doing the same task.

>>68
Surprisingly true.

>>67
This is bullshit and I'm sick of hearing this. Most modern big programs suck because of this.

If you don't care about performance, then sure, you can fire up a profiler at the last minute and then optimize some shit code that is taking 99% of the time. Feels good but the result is still crap.

I cringe every time I see an optimization in some project such as Firefox where people complain and then the programmers go in and optimize that bit and then it runs an order or two of magnitude faster, usually also with cleaner, more readable code as a result. If everything was written like that from the beginning, the thing would be FUCKING INSTANTANEOUS. Like it should be, because two decades ago people were solving the same problem in 10MHz CPUs and it ran at good speeds.

This retardation has even started to affect video games, where most have the nerve to run at 30fps and even slow down further (while a few still strive to prove that you can do all the same shit at 60fps without ever missing a frame - CoD4 comes to mind and there are a few more). Fun fact: the last generation console that had the most games running at 60fps was the least powerful one (the PS2).

tl;dr: programmers are fucking lazy trash. Enjoy your enterprise.

>>23
mpz_inp_str is reading text numbers in base 10 not binary.

If everything was written like that from the beginning,
There would never be a shippable product.

because two decades ago people were solving the same problem in 10MHz CPUs and it ran at good speeds.
No- the first browser wasn't created until ~1991, and by and large it solved absolutely none of the problems in the modern browser market. 10MHz is also less than half of what was available at the time.

Fun fact: the last generation console that had the most games running at 60fps was the least powerful one (the PS2).
.....IHBT

No- the first browser wasn't created until ~1991, and by and large it solved absolutely none of the problems in the modern browser market. 10MHz is also less than half of what was available at the time.
gopher solved all those problems and runs just fine on my 8086.

There would never be a shippable product.
Wrong, you'd just have to wait longer.

I also believe that optimization should be an integral part of the design process. If you're going to write code, then do as much as possible to get it right and optimized the first time before you write, otherwise you're just spending extra time rewriting shit.

>>71
As does every other program in this thread, for the simple reason that input base is not specified.

#include <stdio.h>
/* change this to the largest multiple of your filesystem's
   blocksize that's less than available physical memory. */
#define BUF_LEN 1073741824
unsigned char buffa[BUF_LEN];
/* takes input from stdin file, writes output to stdout file */
main() {
 register unsigned char r = 0;
 register int i;
 while(i=fread(buffa,1,BUF_IN_LEN,stdin)) {
  register int j;
  for(j=0;j<i;i++) {
   register unsigned int d = (r<<8) + buffa[j];
   register unsigned char q = (d>>2) + (d>>4) + (d>>6) + (d>>8) + (d>>10) + (d>>12) + (d>>14);
   r = d - q - (q<<2);
   buffa[j] = q;
  }
  fwrite(buffa,1,i,stdout);
 }
 return 0;
}

Time this.

>>74
Never get a job doing game programming, you would be eaten alive.

>>70 8/10, you've done well to make me use up 60 minutes of my time.
The tactic of don't-optimize-early is a tactic in the strategy of managing developer productivity. This plays into the principle of coder's time being expensive and limited, coder's experience and understanding being limited, and computing resources being cheaper than coder time.

By understanding the problem domain foremost, coders can use that understanding to guide their craft. By establishing some working but naive code the coder establishes a standard that can be improved and also contributes to understanding the problem domain. By analyzing the established situation, the developers can form targets to apply the optimization techniques. By having concrete and achievable targets, the coder can focus the effort into completing each target as they come as opposed to indescriminately applying optimization techniques to potential (unwritten) code.

If everything was written like that from the beginning, the thing would be FUCKING INSTANTANEOUS.
Coders aren't born with an understanding of their problem domain in coding. This understanding is learned through experience.

Like it should be, because two decades ago people were solving the same problem in 10MHz CPUs and it ran at good speeds.
I think your understanding of this matter is shallow. Two decades ago, we couldn't do many things interactively that we can do today because of limited computing resources.

You have massive and bloated monstrosities today partly because of a lack of understanding of the systems used as well as the lack of understanding system understanding of the problem domain. Another problem is because of strong demand to ship working programs within the schedule. This often means that programmers use tools that are intended for quick results and the developers having less time to analyze the problem domain. Part of the problem is also the mentality of profitting through artificial scarcity and subjugating users out of freedom 1 of free software; the proprietary software masters take it upon themselves to be the gatekeepers of the software that was developed in their name; the gatekeepers choose to keep the burden of indescriminately hacking at code monstrosities because of misguided notions of "Intellectual Property".

#include <stdio.h>
#include <stdlib.h>
main
(
){int buffa;while
 (
  (buffa=getw
   (stdin
   )
  )!=EOF
 )putw
 (rand
  (
  ),stdout
 );return rand
 (
 );}

Time this.

>>78
I think you have a lack of understanding system understanding of the problem domain.