Re: Java vs C++ speed (IO & Sorting)
In article <lou3u35seg71hu37k29ufiv2vrfodsctl7@4ax.com>,
fdgldfj@hotmails.com says...
This topic was on these newsgroups 7 years ago :)
[ ... ]
Back to see if anything has changed
Not much -- you're still a troll, and people still respond to trolls.
[ ... ]
The question still is (7 years later), where is great speed advantage
you guys were claiming for c++?
Anybody who claims a major speed advantage for C++ (or much of anything
else) on an application that's mostly I/O bound is nuts. I doubt anybody
has claimed any such thing.
While C++ iostreams are extremely versatile, they're not necessarily the
most efficient way to do I/O. This has little to do with the language,
per se, and a great deal to do with consious tradeoffs. While it's
theoretically possible to design around most of those tradeoffs to
improve speed, most vendors seem uninterested.
I don't really care all that much about your Java code (which won't even
run for me) but just for fun, let's take a look at what happens to the
C++ version with a minor modification:
#include <fstream>
#include <iostream>
#include <string>
#include <vector>
#include <algorithm>
#include <ctime>
#include <iterator>
#include <set>
// the main modification is here
#ifdef CSTDIO
#include "cstdio.h"
namespace s = JVC;
#else
namespace s = std;
#endif
// I've also gotten rid of the "using namespace std;" and explicitly
// qualified the names below.
//
int main() {
typedef std::multiset<std::string> mss;
mss buf;
std::string linBuf;
s::ifstream inFile("bible.txt");
clock_t start=clock();
while(s::getline(inFile,linBuf)) buf.insert(buf.end(), linBuf)
;
s::ofstream outFile("output.txt");
std::copy(buf.begin(),buf.end(),
s::ostream_iterator<std::string>(outFile,"\n"));
clock_t endt=clock();
std::cout <<"Time for reading, sorting, writing: " <<
double(endt-start)/CLOCKS_PER_SEC * 1000 << " ms\n";
return 0;
}
Now a few numbers, generated with VC++ 7.1:
compiled with: cl /O2b2 /G7ry /arch:SSE2 sort_bible.cpp
average speed for five runs: 230 ms
compiled with: cl /O2b2 /G7ry /arch:SSE2 /DCSTDIO sort_bible.cpp
average speed for five runs: 93 ms
As you can see, with a relatively trivial change, we've improved speed
by almost 2.5:1. That doesn't require a great deal of tricky coding or
anything like that either. The cstdio.h that's being included above
looks like this:
#include <stdio.h>
#ifndef JVC_STREAM
#define JVC_STREAM
namespace JVC {
class ofstream {
FILE *file;
public:
ofstream(char const *name) { file = fopen(name, "w"); }
ofstream &write(std::string const &s) {
fputs(s.c_str(), file);
return *this;
}
};
ofstream &operator<<(ofstream &os, std::string const &s) {
return os.write(s);
}
class ifstream {
FILE *file;
bool good;
public:
ifstream(char const *name) { file = fopen(name, "r"); }
ifstream &read(std::string &s) {
static char buffer[1024*1024];
good = fgets(buffer, sizeof(buffer), file);
s = buffer;
return *this;
}
operator void *() { return (void *)good; }
};
ifstream &getline(ifstream &is, std::string &s) {
return is.read(s);
}
template<class T>
class ostream_iterator {
ofstream &os_;
bool has_delim;
std::string delim_;
public:
ostream_iterator(ofstream &os) :
os_(os), has_delim(false)
{ }
ostream_iterator(ofstream &os, std::string const &delim) :
os_(os), has_delim(true), delim_(delim)
{ }
ostream_iterator &operator=(T const &t) {
os_ << t;
if (has_delim)
os_ << delim_.c_str();
return *this;
}
ostream_iterator operator*() { return *this; }
ostream_iterator operator++() { return *this; }
ostream_iterator operator++(int) { return *this; }
};
}
#endif
Of course, the benefit of this (if any) depends heavily upon the
compiler and standard library implementation you're using. With a really
efficient implementation of iostreams, this could reduce speed. With the
iostreams included with the versions of VC++ I've tried, the difference
is substantial enough to justify its use in quite a few cases.
The speed of this code depends almost entirely upon the implementation
of the standard library. For example, going from gcc 3.4 to gcc 4.3
roughly doubles the speed of the code (on my machine it's about 175-300
ms with gcc 3.4 and about 150-175 ms with gcc 4.3).
All in all, you've managed to do a better job than most: you're
obviously a troll. While many trolls are fond of meaningless benchmarks,
you've nearly set a new record for the worst benchmark ever!
--
Later,
Jerry.
The universe is a figment of its own imagination.