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.

int x = file.open(someFile)/3;
x.binaryWrite(anotherFile);

Define the format of the integer and its limits.
Without limiting the language, the fastest will be in hand-optimized asm. If you take a high level language into consideration, then, the result varies widely depending on the compiler and the design choices of your language.

Due to these inconsistencies, I conclude this is a troll thread.

Do your own homework

main = liftM (show . (/ 3) . read) (readFile "in") >>= writeFile "out"

In before best Java scalable enterprise solutions, pseudo-functional FIOC, Haskell one-liner that uses extensive amounts of $ that are really parens, and a C program that actually works.

Your program is fast, but does it scale?


#define FUNCTION_RETURN_TYPE void
#define FUNCTION_NAME writeLoop
#define FUNCTION_PARAMETERS void
#define START_FUNCTION {
#define END_FUNCTION }
#define OPENING_DEVICE file
#define OPENING_FUNCTION open
#define WRITING_FUNCTION binaryWrite
#define FILE_OPEN_NAME someFile
#define FILE_WRITE_NAME anotherFile
#define MATH_OPERATION /
#define MATH_OPERATION_VALUE 3
#define NUMBER_OF_FILES 1
#define LOOP_INITIAL 0
#define INCREMENT += 1;
#define FOR_LOOP_BEGIN for
#define FOR_INITIALIZE_BEGIN (
#define FOR_INITIALIZE_END ;
#define FOR_CONDITION_BEGIN
#define FOR_CONDITION_END ;
#define FOR_INCREMENT_BEGIN
#define FOR_INCREMENT_END ) {
#define FOR_LOOP_END }
#define PARAMETERS_BEGIN (
#define PARAMETERS_END )
#define END_STATEMENT ;
#define INDEX_BEGIN [
#define INDEX_END ]
#define HEADERS #include <stdio.h> \
                #include <sys/stat.h> \
                #include <unistd.h> \
                #include <fcntl.h> \
                #include <stdlib.h>

HEADERS

typedef int arbitrary_precision_integer_t;

FUNCTION_RETURN_TYPE
FUNCTION_NAME
PARAMETERS_BEGIN
   FUNCTION_PARAMETERS
PARAMETERS_END
START_FUNCTION

int loopCount;
arbitrary_precision_integer_t arbitraryPrecisionIntegerFiles[NUMBER_OF_FILES];

FOR_LOOP_BEGIN
   FOR_INITIALIZE_BEGIN
      loopCount = LOOP_INITIAL;
   FOR_INITIALIZE_END
   FOR_CONDITION_BEGIN
      loopCount < NUMBER_OF_FILES
   FOR_CONDITION_END
   FOR_INCREMENT_BEGIN
      loopCount INCREMENT;
   FOR_INCREMENT_END
   loopCount = OPENING_DEVICE.OPENING_FUNCTION
               PARAMETERS_BEGIN
                  FILE_READ_NAME
                  O_RDONLY
               PARAMETERS_END
               END_STATEMENT
   OUTPUT_FILE = OPEN_DEVICE.OPENING_FUNCTION
                 PARAMETERS_BEGIN
                    FILE_WRITE_NAME,
                    O_WRONLY
                 PARAMETERS_END
                 END_STATEMENT
   OUTPUT_FILE.BINARY_WRITE
             PARAMETERS_BEGIN
                arbitraryPrecisionIntegerFiles
                   INDEX_BEGIN
                      loopCount
                   INDEX_END
             PARAMETERS_END
             END_STATEMENT
FOR_LOOP_END
END_FUNCTION

SCALABLE C

I will send it to the next department so they can implement ERROR CHECKING!

>>6
Haskell one-liner that uses extensive amounts of $ that are really parens
In after, you mean.

Additionally, $ is the operator for low-precedence function application -- it's has the same effect as using parens to change evaluation order in most situations, but can be used for much, much more.

>>8
Is it wrong that I came buckets to that program?

#define FUNCTION_RETURN_TYPE void
#define FUNCTION_NAME writeLoop
#define FUNCTION_PARAMETERS void
#define START_FUNCTION {
#define END_FUNCTION }
#define OPENING_DEVICE file
#define OPENING_FUNCTION open
#define WRITING_FUNCTION write
#define CLOSING_FUNCTION close
#define FILE_READ_NAME someFile
#define FILE_WRITE_NAME anotherFile
#define MATH_OPERATION /
#define MATH_OPERATION_VALUE 3
#define NUMBER_OF_FILES 1
#define LOOP_INITIAL 0
#define INCREMENT += 1;
#define FOR_LOOP_BEGIN for
#define FOR_INITIALIZE_BEGIN (
#define FOR_INITIALIZE_END ;
#define FOR_CONDITION_BEGIN
#define FOR_CONDITION_END ;
#define FOR_INCREMENT_BEGIN
#define FOR_INCREMENT_END ) {
#define FOR_LOOP_END }
#define PARAMETERS_BEGIN (
#define PARAMETERS_END )
#define END_STATEMENT ;
#define INDEX_BEGIN [
#define INDEX_END ]
#define HEADERS #include <stdio.h> \
                #include <sys/stat.h> \
                #include <unistd.h> \
                #include <fcntl.h> \
                #include <stdlib.h>

HEADERS

typedef int arbitrary_precision_integer_t;

FUNCTION_RETURN_TYPE
FUNCTION_NAME
PARAMETERS_BEGIN
   FUNCTION_PARAMETERS
PARAMETERS_END
START_FUNCTION

int loopCount, readFile, writeFile;
arbitrary_precision_integer_t arbitraryPrecisionIntegerFiles[NUMBER_OF_FILES];

FOR_LOOP_BEGIN
   FOR_INITIALIZE_BEGIN
      loopCount = LOOP_INITIAL;
   FOR_INITIALIZE_END
   FOR_CONDITION_BEGIN
      loopCount < NUMBER_OF_FILES
   FOR_CONDITION_END
   FOR_INCREMENT_BEGIN
      loopCount INCREMENT;
   FOR_INCREMENT_END
   readFile = OPENING_DEVICE.OPENING_FUNCTION
               PARAMETERS_BEGIN
                  FILE_READ_NAME,
                  O_RDONLY
               PARAMETERS_END
               END_STATEMENT
   writeFile = OPEN_DEVICE.OPENING_FUNCTION
                 PARAMETERS_BEGIN
                    FILE_WRITE_NAME,
                    O_WRONLY | O_APPEND
                 PARAMETERS_END
                 END_STATEMENT
   WRITE
      PARAMETERS_BEGIN
         writeFile,
         readFile MATH_OPERATION MATH_OPERATION_VALUE,
         sizeof(int)
      PARAMETERS_END
      END_STATEMENT
   CLOSING_FUNCTION
      PARAMETERS_BEGIN
         writeFile
      PARAMETERS_END
   CLOSING_FUNCTION
      PARAMETERS_BEGIN
         readFile
      PARAMETERS_END
FOR_LOOP_END
END_FUNCTION

There, that's closer to something to work with.  I think I started writing SEPPLES on the last one.

in b4 JAVA

>>11
I think if people saw that, there would be no more need for Java.  You still have two sections with C++, but you just have to remove the "OPENING_DEVICE" and "OPENING_DEVICE."

>>8
BRINGING C TO THE ENTERPRISE

I've started running my Ruby implementation. I'll give you the benchmark stats once it's done.

from sys import argv
open(argv[2], 'w').write(bin(int(open(argv[1], 'r').read()) // 3))

The challenge is badly specified, uninteresting and useless. Bring back Practical /prog/ Challenges!

Bring back Practical /prog/ Challenges!
In that case, implement a POSIX-compliant implementation of ls

>>17
Anonix anyone?

>>8
that's beautiful.

It's fast, believe me.

import java.io.File;
import java.io.FileOutputStream;
import java.math.BigInteger;
import java.util.Scanner;

public class Lol {
  private static final String IN  = "file1.txt";
  private static final String OUT = "file2.bin";

  public static void main(String[] args) {
    try {
      Scanner scanner = new Scanner(new File(IN));
      BigInteger n = scanner.nextBigInteger();
      scanner.close();
 
      n.divide(BigInteger.valueOf(3));
      byte[] b = n.toByteArray();

      FileOutputStream out = new FileOutputStream(new File(OUT));
      out.write(b);
      out.close();
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}

>>20
Doesn't meet the spec, uses BigInteger and default I/O buffering. 0/10.

>>21
BigInteger is arbitrary precision, and the default I/O buffering is sufficient

Try it aganist your "C" programs and see how it stacks up, I dare you

>>22
try this one.
#include <stdio.h>
#include <gmp.h>

int main(int argc, char **argv)
{ if(argc > 2)
  { FILE *f;
    mpz_t n;
    mpz_init(n);
    if(f = fopen(argv[1], "r"))
    { mpz_inp_str(n, f, 10);
      fclose(f);
      mpz_tdiv_q_ui(n, n, 3);
      if(f = fopen(argv[2], "w"))
      { mpz_out_str(f, 10, n);
        fputs("\n", f);
        fclose(f); }
      mpz_clear(n); }}
  return 0; }

When the fire leaps amidst the ^{northern maelstrom} I will rise covered in glory with all the underaged valkyries chewing my cum

>>22
BigInteger has obnoxious overhead for such a trvial problem and the default I/O buffering is NOT sufficient given it will be the bottleneck in this problem.

>>23
Holy fuck, take that indentation somewhere else. Jesus fucking christ it burns my eyes.

>>26
it doesn't matter what it looks like. it's faster than yours.

>>27
it doesn't matter what it looks like.
Yes, it does.

Also, your program doesn't do >>1.3, however you interpret it.

>>28
are you saying that the resulting file isn't made up of bits? what the fuck is it then?

>>29
I'm asking for the output to be NUMBERS.
As in: 2938175 or whatever, but expressed in BINARY as NUMBERS

>>30
OP just asked for a binary result.
as long as the output is a bunch of bits, it's correct.

>>32
But is it in NUMBERS?

>>32
Depends how you interpret binary zeros and ones. As symbols for truth function results or as numbers in their own right.

>>30,32
Do you mean ASCII CHARACTERS?  Because there's a huge fucking difference between a bloated mass of ASCII CHARACTERS and the actual, numerical, binary result.  Say what you mean (or stop meaning such a retarded thing in the first place), or you have no right to be a dick when you don't get it.

This is best implemented using long division and not reading the entire file in at once. Thus it will scale nicely.

Here's my C program to do this:

/* div3.c */

#include <errno.h>
#include <stdio.h>

typedef unsigned char byte;

int main(int argc, char *argv[])
{
    FILE *fin;
    FILE *fout;
    byte remainder = 0;
    byte remdiv = 0;
    byte buf[4096];
    size_t bytes_read, nums_cnt, n;
   
    if (argc < 3)
    {
        fprintf(stderr, "usage: div3 infile outfile\n");
        return 1;
    }
   
    if (!(fin = fopen(argv[1], "rb")))
    {
        fprintf(stderr, "can't open input file due to error %u\n", errno);
        return 2;
    }
   
    if (!(fout = fopen(argv[2], "wb")))
    {
        fprintf(stderr, "can't open output file due to error %u\n", errno);
        return 3;
    }

    while(!feof(fin))
    {
        bytes_read = fread(&buf, 1, sizeof(buf), fin);
        if (ferror(fin))
        {
            fprintf(stderr, "error %u while reading file\n", errno);
            return 4;
        }

        for (n=0; n<bytes_read; n++)
        {
            switch(remainder)
            {
            case 0:
                remdiv = 0;
                break;
            case 1:
                remdiv = 85;
                break;
            case 2:
                remdiv = 170;
            }
            remainder += buf[n] % 3;
            buf[n] = buf[n]/3 + remainder/3 + remdiv;
            remainder %= 3;
        }
       
        fwrite(buf, 1, bytes_read, fout);
        if (ferror(fout))
        {
            fprintf(stderr, "error %u while writing file\n", errno);
            return 5;
        }
    }
   
    fclose(fin);
    fclose(fout);
   
    return 0;
}

>>24
Thank you for your contribution.

>>35
Now make it work using the machine's word size instead of by bytes.

linux is so fucking gay. imma gonna buy a second hand mac or something.

>>38
$2500, please.

MAC OS is like BSD, only apples charge for it. Why would I pay for something that I get for free, and without pig disgusting extras like web 2.0 GUI or screenlets?

>>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.

anyone that talks about problem domains is a faggot

>>79
Your indention makes my eyes bleed.

(rand
  (
  ),stdout
Shit, I read it again more carefully and I got trolled.

>>83
);}

>>78
Back to your desk, enterprise codemonkey.

What sort of fucking idiot regards "opens a file as arbitrary precision integer" to mean "read in a file, interpret it as ASCII and take that string to be a base 10 number"? Obviously, it means take the actual file data to be a number.

>>76
Interesting method of dividing by three, but it makes little difference as the bottleneck is disk access.

>>86
Obviously, it means take the actual file data to be a number.
`Obvious' is probably not the word you're looking for here considering every single program in this thread does it the other way.

Given >>1's definition, how would you interpret a binary file as an arbitrary-precision integer?

>>88
No, every single program in this thread does not.

The two programs in this thread which actually do it properly and efficiently interpret >>1 to mean the file is read in as a binary number with the most significant bit at the start of the file and the least significant bit at the end.

>>89
I think you need to re-examine your assumptions.

>>90
I will, along with my job.

>>91
Reading SICP improves job performance.

>>76 is full of bugs and doesn't even compile properly.

>>93 is full of anticudders and doesn't even BBCODE properly

_div3:    ; void *to, void *from, uint qwords
    mov rcx,rdx
    xor rdx,rdx
    mov r8,3
    lea rsi,[rsi+8*rcx]
    lea rdi,[rdi+8*rcx]
    neg rcx
.iter:
    mov rax,[rsi+8*rcx]
    div r8
    mov [rdi+8*rcx],rax
    add rcx,1
    jnz .iter
    ret

_{…snip 100 lines of open+mmap…}