flat assembler
Message board for the users of flat assembler.

Index > Heap > C# that doesn't require .Net

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
AsmGuru62 wrote:
Build the size of a FULL DAY!
Wow!


I think it's commonly known that C++ is not the fastest HLL to compile. In fact, probably one of the slowests.

If you are brave enough, maybe you'd like to built KDE (obviously a huge C++ project) from source.

This post says 3 days are required. Not sure about the current situation, though. Smile
Post 13 Jan 2013, 16:22
View user's profile Send private message Reply with quote
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
TmX wrote:
AsmGuru62 wrote:
Build the size of a FULL DAY!
Wow!


I think it's commonly known that C++ is not the fastest HLL to compile. In fact, probably one of the slowests.

If you are brave enough, maybe you'd like to built KDE (obviously a huge C++ project) from source.

This post says 3 days are required. Not sure about the current situation, though. Smile


True. I dont know if C++ is that hard to parse or if compilers are badly done.

D compiler is very fast. Also Free Pascal compiler is fast too.
Post 13 Jan 2013, 18:41
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
OzzY wrote:
The first time you build a project (package as they call it) the entire frameworm is built, but it builds fast because it uses this: http://en.wikipedia.org/wiki/Single_Compilation_Unit

Hm, SCU can be a decent enough strategy for some things, especially if you need to support a wide range of compilers and can't depend on things like precompiled header support or link-time code generation - it works pretty well for a project like SQLite. But using it for something the size of a standard library? I'm not sure what to think of that Smile

I haven't used the IDE, and the Blitz documentation doesn't mention just how it's applied; is the entire standard library SCU'ed, or is it just the parts you need, per-project?

OzzY wrote:
It takes me about 1 minute to build the entire library. Compared to a full day that Qt takes, it rocks in my opinion.

Ultimate++ is pretty large, but Qt is huge. A full day sounds a bit much - it's been years since I used Qt last, so I can't remember if I built it from source or used the libraries. That's the thing, though - you've got libraries. As an end-user, you don't need to do a full compile from source - and if you do development on Qt itself, you'll only be rebuilding modified files after the initial compile.

PS: when building Qt, did you enable precompiled headers? I don't think it's enabled by default, and should speed up the build process quite a bit (depending on the compiler you use, and how much memory you've got and how many parallel compiler instances you use for the build process).

TmX wrote:
This post says 3 days are required. Not sure about the current situation, though. Smile

10 years old post, and a computer that was ancient already back then Razz - but yeah, it's a big beast. A more recent post says 6 hours on a 2.9GHz quadcore.

OzzY wrote:
True. I dont know if C++ is that hard to parse or if compilers are badly done.

C++ definitely isn't the easiest langauge to parse - and a lot of time is wasted because of the lack of module support, by the constant re-parsing of header files. Using precompiled headers, while somewhat of a hack, can speed up builds quite drastically... and doesn't help wrt. compile speed of templates.

Anyway, I finally got around to building the Ultimate++ benchmark thingy. I didn't want to use their IDE, so I had to manually figure out which files to include (build, look at linker errors, add a bunch of source files (with new dependencies...), rebuild, et cetera). Ended up having to pull in 39 files, as well as 12 ZLib files.

OK, Ultimate++ is a big enough project that you're kind not writing C++ but U++ (whole new standard library, different build system with their own terms, ...), so I guess that if you've committed yourself that much to it, you probably probably want to take full use of it, and don't mind using only their IDE and build process etc... I personally prefer being able to choose my own IDE, and having a more standard build process Smile

I built the benchmark with Visual C++ from VS2012-Update1, Microsoft (R) C/C++ Optimizing Compiler Version 17.00.51106.1 for x86. A couple of observations while getting the thing to build:

1) Compiling in debug mode, App.cpp makes calls to MemoryBreakpoint() inside a #if defined(_DEBUG) && defined(UPP_HEAP). MemoryBreakpoint() is defined in heapdbg.cpp, but only if HEAPDBG is defined - ending up with link errors. Defining HEAPDBG made UPP want to pull in EVEN MORE files - so I commented out the MemoryBreakpoint() call in App.cpp.

2) I removed GCC/non-GCC checks, and simply did typedef std::unordered_map< string, vector<int> > HashMap;, which is the C++11 way

3) the final executable ends up at ~467k, and that's even though the C++ runtime is linked dynamically... ouch.

I used the King James Bible from Project Gutenberg as test input, and lowered the number of iterations to 100. The results on my i7-3770 (with 16gig DDR3-1600) are:
Quote:
D:\src\test\UltimatePP\Release>Benchmark.exe r:\pg10.txt
STL hash_map time: 26380 ms
STL map time: 33182 ms
NTL time: 4742 ms


So, the hashmap version is 5,563x slower than U++, and the treemap version is 6,997x slower.

However, I wouldn't say that the STL version is entirely good, idiomatic C++ usage. Quite a lot of time is wasted by doing character-at-a-time scanning of the file. Yes, it's sorta fair in that the same algorithm is used both for the STL/ifstream and the U++/FileIn reading, but it's not how you'd normally do things in C++ Smile.

I'll probably play around with the code a bit tomorrow.

_________________
Image - carpe noctem
Post 21 Jan 2013, 01:31
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:56; edited 1 time in total
Post 21 Jan 2013, 02:03
View user's profile Send private message Reply with quote
ASM-Man



Joined: 11 Jan 2013
Posts: 65
ASM-Man
OzzY wrote:

True. I dont know if C++ is that hard to parse or if compilers are badly done.

D compiler is very fast. Also Free Pascal compiler is fast too.


C++ is a complex and ambiguos grammar(as already has been mentioned by RMS and a lot of programmers) This is one-of reasons that RMS don't like C++ and haven't used in your projects. (well, the gcc 4.6 begings by using C++ but I'm not sure if RMS is still in its developing team).

DMD compiler is so fast too because doesn't perform nor even assembly code generation.
One-of reasons because the DMD compiler is so fast is because doesn't perform nor even assembly code generation. Walter Bright talent helps so much. He have wrote a C++ compiler hand-written by using recursive decence parser.

Also,here's a good article by Walter Bright on C++ compiler speed

HaHaAnonymous wrote:
TmX wrote:
I think it's commonly known that C++ is not the fastest HLL to compile. In fact, probably one of the slowests.

If you are brave enough, maybe you'd like to built KDE (obviously a huge C++ project) from source.

This post says 3 days are required. Not sure about the current situation, though. Smile

This sounds very scary. I am almost sure this would take days to build on my computer (2.5GB of RAM, Intel Pentium E2200 @ 1.20GHz, 1 active core).

One must really "love" a programming language to wait so MUCH time to compile an ordinary project when they can use another that is so MUCH faster. Unless you are rich enough to pay the electricity bill and buy a really powerful computer.

Now, how much time does the biggest "pure assembly" project takes to assemble? If any.

In my opinion.
PS. in my opinion

haha, my opinion!


By using fasm? in a power hardware as other have mentioned, I'm not sure how many nanoseconds. Joke answer. hahaa. I think that the greater project written in pure assembly that I've seen is the Manuent OS,unles open source. There was so many in the past,by including the Microsoft Word but all have been ported to C and after to C++(if not *all* perform required). Those that ported directly to C++ language have ported back to C because C++ isn't really a fast language. Not if compared to e.g. C. C# is very close to C++.

_________________
I'm not a native speaker of the english language. So, if you find any mistake what I have written, you are free to fix for me or tell me on. Smile
Post 21 Jan 2013, 03:35
View user's profile Send private message Reply with quote
KevinN



Joined: 09 Oct 2012
Posts: 161
KevinN
Post 21 Jan 2013, 10:04
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
HaHaAnonymous wrote:
One must really "love" a programming language to wait so MUCH time to compile an ordinary project when they can use another that is so MUCH faster. Unless you are rich enough to pay the electricity bill and buy a really powerful computer.

My server, i5-3550@3.30GHz (using CPU built-in GPU, no discrete card) + 2x4GB DDR3-1333MHz + ASUS P8Z77-M + 2.5" HDD, idles at around 30W... My old server was a mere Celeron-420@1.60GHz w/2GB ram idled at ~58W.

Running four instances of "dd if=/dev/urandom of=/dev/null" purportedly puts the system at 100% load (I should find some decent number-crunching to make sure it's really sweating), running at ~65W.

So, not only does the new system use much less power even under full load, it's also finishing the job vastly quicker, whereafter it can return to idle. So at least your electricity bill argument is void Smile

HaHaAnonymous wrote:
Now, how much time does the biggest "pure assembly" project takes to assemble? If any.

Even the largest pure-assembly project would seem tiny compared to behemoths like Qt or KDE. But sure, assemblers do a lot less work than HLL compilers, so they have radically higher throughput.

ASM-man wrote:
One-of reasons because the DMD compiler is so fast is because doesn't perform nor even assembly code generation.

I take it you mean that DMD doesn't produce assembly output as an intermediary, contrary to GCC which needs to run GAS? While I've always found this arrangement a bit silly, even if I don't believe this causes massive overhead? More modern C++ compilers (CLang, MSVC, ICC, ...) don't do the assembly step either.

ASM-man wrote:
Also,here's a good article by Walter Bright on C++ compiler speed

Nice little overview. The biggest problem is indeed the header file mess... Preprocessing a small ~300-line C++ program with the following header files:
Code:
<windows.h>, <winioctl.h>, <stdio.h>, <tchar.h>, <algorithm>, <iomanip>, <iostream>, <string>, <vector>    

results in a 2.6meg file of nearly 280k lines, which the compiler then has to chew through. Languages that support modules don't need to deal with that mess.

And as Walter mentions, precompiled headers aren't entirely trouble-free:
http://www.drdobbs.com/cpp/c-compilation-speed/228701711 wrote:
Precompiled headers address some of these issues by making certain simplifying assumptions about C++ that are non-Standard, such as a header will mean the same thing if #incuded twice, and you have to be careful not to violate them.

This is entirely correct, but I'd say that for "normal" header files, it's a bug depending on inclusion order. When using PCHs, you'll generally only be including things like Windows.h, libc/STL, and any prebuilt/static libraries.

Some people are lazy, and depend on simply including their big PCH everywhere, and not bother about individual module dependencies... that's bad practice. You should make sure to set up your project so you can #define DISABLE_PCH, and get clean compiles anyway (this does mean each module needs to do all it's #includes after including the PCH, so you should only put things in the PCH that have proper includes guards).

Yep, the header file messyness means you need to spend some time in C/C++ worrying about things that are non-issues in other languages, and that does suck Smile

_________________
Image - carpe noctem
Post 21 Jan 2013, 15:38
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.