Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » C++ FQA
Re: C++ FQA [message #12646 is a reply to message #12642] Mon, 12 November 2007 09:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Sun, 11 November 2007 18:58


So, adding notes about efficiency, do you know how VCL handles it`s forms? Forms and components are converted to textual representation. The borland IDE gives text to linker, which adds these text resources to the end of .exe files. When you start any BCB application, it runs special parser (which is by default in dll!). Text resources are parsed. How? Application gives this text to internal engine, then to newly-created components which serialize their properties from text parts. That is how BCB application starts.



Actually, this might seem horrible, but in reality, it does not need to cause any real problems... Those text descriptions are usually not too big and easy to parse. I do not know too much about VCL, but this could be "OK solution" IMO...

Quote:


The greatest issue for me personally is that IDE "insists" on the only one programming style.



Smile Similar experience with MFC or some other environments. This is what made me sceptical about "visual tools".

(Ironically, it seems like U++ starts to be quite ide supported too... I guess if you have that power - to support your library in your ide - it is just hard to resist..)

Mirek

[Updated on: Mon, 12 November 2007 10:05]

Report message to a moderator

Re: C++ FQA [message #12648 is a reply to message #12646] Mon, 12 November 2007 10:19 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Mon, 12 November 2007 09:46

Mindtraveller wrote on Sun, 11 November 2007 18:58


So, adding notes about efficiency, do you know how VCL handles it`s forms? Forms and components are converted to textual representation. The borland IDE gives text to linker, which adds these text resources to the end of .exe files. When you start any BCB application, it runs special parser (which is by default in dll!). Text resources are parsed. How? Application gives this text to internal engine, then to newly-created components which serialize their properties from text parts. That is how BCB application starts.



Actually, this might seem horrible, but in reality, it does not need to cause any real problems... Those text descriptions are usually not too big and easy to parse. I do not know too much about VCL, but this could be "OK solution" IMO...


I agree, BCB apps were fast starting, I don't see anything bad on loading forms from a resource file and/or from exe file. It show only that they had good serialization stuffs.

Quote:


Quote:


The greatest issue for me personally is that IDE "insists" on the only one programming style.



Smile Similar experience with MFC or some other environments. This is what made me sceptical about "visual tools".

(Ironically, it seems like U++ starts to be quite ide supported too... I guess if you have that power - to support your library in your ide - it is just hard to resist..)



I think that it's unavoidable.... every Ide tends to support best their own class library, as people have more skills on it.
That's the same for Codeblocks.... it can work with many widget libraries, but is focused on wxwidgets, as it's written using that library. They have wizards for a few more frameworks, but then no support for layout editing and more stuffs. It's a great tool, but not for quick development, IMHO. And wxwidgets is an old and heavy framework.
Theide is focused on Upp, has a good layout editor, is still young in particular in respect to help system and (IMO) debugger, but is lightweight and fast to use. You could use it with wxwidgets or other tools but.... why ? Smile

Ciao

Max
Re: C++ FQA [message #12650 is a reply to message #12648] Mon, 12 November 2007 10:28 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Just a note on VCL. It stands for Visual Components Library (or something similar) and it was developed a visual components library (Razz), and as such other features where introduced to support the visual stuff. You can't expect it to be a general purpose library. But as the version number increased, the library got a good deal of non-visual features. But you still needed a good systems interaction library if you didn't want to use windows API. And under Delphi, not BCB, using it felt more integrated. I couldn't shake the feeling when working in BCB that VCL for C was more of an afterthought than a real alternative. An BCB 1.0 was extremely buggy.
Re: C++ FQA [message #12652 is a reply to message #12650] Mon, 12 November 2007 11:43 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
cbpporter wrote on Mon, 12 November 2007 10:28

Just a note on VCL. It stands for Visual Components Library (or something similar) and it was developed a visual components library (Razz), and as such other features where introduced to support the visual stuff. You can't expect it to be a general purpose library. But as the version number increased, the library got a good deal of non-visual features. But you still needed a good systems interaction library if you didn't want to use windows API. And under Delphi, not BCB, using it felt more integrated. I couldn't shake the feeling when working in BCB that VCL for C was more of an afterthought than a real alternative. An BCB 1.0 was extremely buggy.


Yes, BCB 1.0 was buggy, but following versions were more than ok.
BTW, the buggiest Borland product I've ever seen was C#builder 1.0 ... That one was quite unusable.

But VCL is a good *visual* library, with some more stuffs. And, besides, you could get many more components for BCB/Delphi on open source/shareware market.
Re: C++ FQA [message #12654 is a reply to message #12521] Mon, 12 November 2007 13:09 Go to previous messageGo to next message
exolon is currently offline  exolon
Messages: 62
Registered: July 2006
Location: 53'21N 6'18W
Member
unodgs wrote on Wed, 07 November 2007 09:40

Quote:

So, I would say for now we do not have any adequate alternatives for C++.

Some claim it is D (www.digitalmars.com/D). At least it has comparable set of features.

D does seem good, and its built-in string handling and GC are apparently fast.
Check out the computer language benchmarks game for some tests of various languages.

Personally, I've been looking into programming in Eiffel (with the free SmartEiffel compiler) lately, but there seems to be no useful GUI library... the built-in one supplied with the compiler libraries, "Vision", is so ugly it hurts.

Oisín

p.s.
Funny quote from the FQA

"There's a basic assumption behind C++ that extra features can't be a problem - only missing features can. That's why there are so many features in C++, and in particular so many duplicate ones. Real world analogies ("imagine a dog with twelve legs") are pale compared to this reality."

[Updated on: Mon, 12 November 2007 13:10]

Report message to a moderator

Re: C++ FQA [message #12661 is a reply to message #12648] Mon, 12 November 2007 15:54 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

It is funny, I`m criticizing the tool, I`ve been using for years. Just to make clear - programms written under BCB were my main job throughout these years. Yes, while I used it heavily, I just wanted something better - and this is purpose of my being here. Event this critics aimed not to blame Borland with VCL, but to think of something better and more advanced than good old VCL.

It was also mentioned above, that VCL (it really stands for Visual Components Library) - is not framework, it is simple bunch of approaches and code for rapid GUI writing. I`ve forgotten this, considering VCL a complete framework - it`s wrong of course.

Quote:

I don't see anything bad on loading forms from a resource file and/or from exe file

The main issue is that you need to have all components in your code - because application doesn`t know which components are used at the compile time. This way we have very-big-applicaction-code. Borland solved this by dividing components by packages, which you can plug-in (or not) in your app.
And, yes, they managed to make serialization rather quick. I wonder if we`d have even more effective and fast-starting applications if VCL used more simple ways to start.

The second issue about working with these resources is that heavy graphics usage led to fast-growing exe files - because picture resources where also included into text resources in the form of textual binary data representation:
        Glyph.Data = {
          76010000424D7601000000000000760000002800000020000000100000000100
          04000000000000010000120B0000120B00001000000000000000000000000000
          800000800000008080008000000080008000808000007F7F7F00BFBFBF000000
          FF0000FF000000FFFF00FF000000FF00FF00FFFF0000FFFFFF00555555555555
          5000555555555555577755555555555550B0555555555555F7F7555555555550
          00B05555555555577757555555555550B3B05555555555F7F557555555555000
          3B0555555555577755755555555500B3B0555555555577555755555555550B3B
          055555FFFF5F7F5575555700050003B05555577775777557555570BBB00B3B05
          555577555775557555550BBBBBB3B05555557F555555575555550BBBBBBB0555
          55557F55FF557F5555550BB003BB075555557F577F5575F5555577B003BBB055
          555575F7755557F5555550BB33BBB0555555575F555557F555555507BBBB0755
          55555575FFFF7755555555570000755555555557777775555555}


The third issue about text resources is that one may "hack" application. Imagine, you have access rights in your banking operations program. Operator access rights don`t allow him to move money from one account to another - where app simply disables unavailable buttons (this is very common approach).
Ok. You just run special resource editor (there are visual ones also) and make button enabled by default. Or add button with the same handlers, or 1000 more ways to change how your program works - without actual debugging, back engineering, etc. Of course, there are 3rd party utilities encrypting .exe, but think of how many programs are written by people who actually can`t imagine that their programms can be hacked in any moment, without even installing a debugger and living all the application code alone.
Once I was needed to try some application, but it had password protection. I applied some resource hacks and entered it (more just for fun). But I just didn`t like an idea that anyone else may do the same with apps I`ve written.

Quote:

Ironically, it seems like U++ starts to be quite ide supported too
Yes, but U++ restrictions are way too wider than common IDE`s. Also, I like the way of programming U++ proposes to me. After many problems with standard GUI approaches, to have components in class, where they are needed - is like breath of fresh air for me. That is why I don`t see any problems with U++ restrictions on my code (maybe I`m wrong with this, but alternative restrictions seem to me far worse).
Yesterday I`ve finished rewriting some of my helper classes for U++ (previuosly created for BCB) - the ones I commonly used in my apps. The first version of one of them (ConveyorThread) - being posted into forum. It turned that they were four times smaller, and all my tool application, rewritten under U++, fit into 10Kb of source code (without helper classes). This is more than three times smaller than BCB version - even to mention I`m no professional in U++ for now.

Quote:

D does seem good, and its built-in string handling and GC are apparently fast.
It was mentioned above that D`s GC may sometimes hang your application for 2-3 seconds. It soesn`t sound like good for serious programms. Also, I don`t like an idea that something else would control freeing of blocks I allocated. I don`t think that good-structured code have much problems with loosing allocated memory. More problematic for me personally is keeping things under control when you heavily use pointers with address arithmetics on many types. It`s very effective and quick (and sometimes necessary) but very dangerous.
Re: C++ FQA [message #12662 is a reply to message #12661] Mon, 12 November 2007 16:47 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Mindtraveller wrote on Mon, 12 November 2007 15:54


............
The third issue about text resources is that one may "hack" application. Imagine, you have access rights in your banking operations program. Operator access rights don`t allow him to move money from one account to another - where app simply disables unavailable buttons (this is very common approach).
....


brrrrrrrrr ! Thinkin' that an app is 'secure' just hiding some buttons makes me think to take my (few) money from bank and put it under my bed....
With modern debuggers, it's a child game to hack a program, with or without resources embedded on it.
With data sensible apps, the only way is to rely on passwords, cryptography and such techniques, not on 'hidden data' inside executables !
Quote:


Quote:

Ironically, it seems like U++ starts to be quite ide supported too
Yes, but U++ restrictions are way too wider than common IDE`s. Also, I like the way of programming U++ proposes to me. After many problems with standard GUI approaches, to have components in class, where they are needed - is like breath of fresh air for me. That is why I don`t see any problems with U++ restrictions on my code (maybe I`m wrong with this, but alternative restrictions seem to me far worse).
......



BTW, I don't see nothing bad on a gui approach to Upp.
It's a good framework and a good layout editor/Rad tool will help people to jump in.
In modern programs more than 60-70% of work is spent on layouts, appearance, ecc ecc... So having a good framework that is also a good 'visual' framework is surely a plus.
Re: C++ FQA [message #12663 is a reply to message #12661] Mon, 12 November 2007 16:51 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Quote:

It was mentioned above that D`s GC may sometimes hang your application for 2-3 seconds. It soesn`t sound like good for serious programms. Also, I don`t like an idea that something else would control freeing of blocks I allocated. I don`t think that good-structured code have much problems with loosing allocated memory. More problematic for me personally is keeping things under control when you heavily use pointers with address arithmetics on many types. It`s very effective and quick (and sometimes necessary) but very dangerous.

Well these execution freezes are not worse than in JVN or .NET platforms. Actually, they can even be shorter. I would like to see some real-life samples of GC performance, not just speculation or my personal experience. Have you ever used a bigger .NET or JVM application. For example Eclipse (I don't know of any big applications in .NET). D applications would seem somewhat livelier than these, not because of GC, but because of generally better performance and less laggy GUI.

And in D you never need pointer arithmetics. You don't even need to bother with pointers and allocations at all, except when working with C libs and once in a while when you have a shared object and need to clone in first (nasty bug).
Re: C++ FQA [message #12664 is a reply to message #12663] Mon, 12 November 2007 20:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Mon, 12 November 2007 10:51


I would like to see some real-life samples of GC performance, not just speculation or my personal experience. Have you ever used a bigger .NET or JVM application.



BTW, I did only that single benchmark D vs U++ - U++ was about 2x faster, but what was really shocking is that D consumed 5 times as much memory....

Quote:


And in D you never need pointer arithmetics. You don't even need to bother with pointers and allocations at all, except when working with C libs and once in a while when you have a shared object and need to clone in first (nasty bug).



I guess it is the same for U++. OTOH sometimes pointer arithemtic is handy....

Mirek
Re: C++ FQA [message #12665 is a reply to message #12661] Mon, 12 November 2007 20:21 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Mon, 12 November 2007 09:54


The second issue about working with these resources is that heavy graphics usage led to fast-growing exe files



BTW, I am proud to say that U++ is now highly optimized here; not only are .iml compressed using zlib, but even more importantly, several images are always compressed in a single block; means you compress usually about 4KB of often related data together.

Mirek
Re: C++ FQA [message #12671 is a reply to message #12665] Mon, 12 November 2007 21:39 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Quote:


BTW, I did only that single benchmark D vs U++ - U++ was about 2x faster, but what was really shocking is that D consumed 5 times as much memory....


As said before, D has a known performance problem with built in hash maps. I guess the developers are more concerned with the shape of the language and haven't had time to optimize such details yet.

As for the memory consumption, I am not surprised at all. Mark and sweep abandons traditional memory paradigms as allocation when you need and freeing again when you are done with the object. As much as you can optimize these algorithms, allocation and memory freeing are very time consuming operations (relatively speaking of course). In mark and sweep, allocation consists of an if to see if there is enough space. If not, a huge block is allocated. If there is enough space, a simple pointer incrementation is performed. Very fast. You continue to allocate and only do time costly deallocations when you are out of physical memory or have reached a certain threshold. Another advantage is zero memory fragmentation is the mark-and-sweeper is also a moving-compactor. And if you make it generational too, you can really optimize it. So in theory, GC programs should run a lot faster. Memory is cheap, and if with 1-2 GB of memory extra you can gain sufficient extra speed, I think GC will continue to get more and more popular. But this is only theory, and that's why I'm interested in some scientifically sane benchmarks.
Re: C++ FQA [message #12673 is a reply to message #12671] Mon, 12 November 2007 22:43 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Mon, 12 November 2007 15:39

Quote:


BTW, I did only that single benchmark D vs U++ - U++ was about 2x faster, but what was really shocking is that D consumed 5 times as much memory....


As said before, D has a known performance problem with built in hash maps. I guess the developers are more concerned with the shape of the language and haven't had time to optimize such details yet.

As for the memory consumption, I am not surprised at all. Mark and sweep abandons traditional memory paradigms as allocation when you need and freeing again when you are done with the object. As much as you can optimize these algorithms, allocation and memory freeing are very time consuming operations (relatively speaking of course). In mark and sweep, allocation consists of an if to see if there is enough space. If not, a huge block is allocated. If there is enough space, a simple pointer incrementation is performed. Very fast.



Sorry for being rude, but your understanding of actual GC (and especially conservative GC) is sort of lacking Wink

Quote:


Another advantage is zero memory fragmentation is the mark-and-sweeper is also a moving-compactor.



Not in all cases and AFAIK, not in D. I might be wrong, but I am afraid that D, using conservative GC, is still prone to memory fragmentation.

Quote:


And if you make it generational too, you can really optimize it.



I am no expect in GC and perhaps I am wrong about this, but IMO generational GC and moving GC are mutually exclusive.

Quote:


So in theory, GC programs should run a lot faster. Memory is cheap, and if with 1-2 GB of memory extra you can gain sufficient extra speed, I think GC will continue to get more and more popular. But this is only theory, and that's why I'm interested in some scientifically sane benchmarks.



...or you can do twice as much work with existing hardware....

Anyway, I think the main argument w.r.t. GC is management of other resources than memory. With GC, it is virtually impossible. And no, you cannot have destructors and GC working together.

I believe that with a couple of tricks, I am getting (with U++) more than I could get with GC - all resources are managed by program structure.

Mirek
Re: C++ FQA [message #12676 is a reply to message #12673] Mon, 12 November 2007 23:22 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Quote:


Sorry for being rude, but your understanding of actual GC (and especially conservative GC) is sort of lacking.


That could very well be the case, but I believe I have some if not enough teoretical and practical experience. What exactly did I say that was inaccurate? I was referring to generic garbage collection (no ref-counting though), but biased toward mark and sweep style algorithms, not exactly to D's implementation (about which I have only superficial knowledge). And what do you mean by conservative GC?

Quote:


I am no expect in GC and perhaps I am wrong about this, but IMO generational GC and moving GC are mutually exclusive.


Well a moving GC (which makes little sense without a compacting GC) moves memory chunks around when neaded and modifies pointers to point to the new locations. A generational GC simply optimizes the allocated objects list so that objects that were created recently are faster to deallocate than old objects (plainly put), because newly created objects have a larger change to get destroyed. So I don't see any reason for them to be mutually exclusive. I could be wrong though.

Quote:


And no, you cannot have destructors and GC working together.


Well you can. With a little extra care, you can have fully functional destructors (just be sure never to physically deallocate memory, just do cleanups). But with GC you rarelly need non-trivial destructors. And if the programing language has a "scope" clause like D, things get a lot simpler.

Quote:


I believe that with a couple of tricks, I am getting (with U++) more than I could get with GC - all resources are managed by program structure.


No arguing here. This is one of the main reasons I like U++. But I would say "almost all", because once in a while you do need to manually manage memory outside of program structure. But those cases are insignificant to overall code size and scope.


[Updated on: Mon, 12 November 2007 23:24]

Report message to a moderator

Re: C++ FQA [message #12677 is a reply to message #12673] Mon, 12 November 2007 23:33 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well, also being absolutely not an expert of GC algorithms, I always think that to allocate a lot of memory just because there is enough of it it's not a great practice.
First thing, you must look to what does OS in respect of free memory.... If your OS tells you that you've got 1 GB free ram, even when it's already swapping out another GB on disk, what this behaviour does is slowing down your system.

IMHO a truly efficient GC should be hardware implemented, or at least have a strong hardware support. Doing it software you'll face everytimes with some sort of problem, as latency, memory inefficiency or both.
And it should also collect freed memory asap.
Cbpporter spoke about some sort of 'threshold' for collecting garbage.... but what should be such a threshold ? On oldest OS that was simple, no swapping mechanics, so you could decide, 30% of physical ram, ok. On modern OS, you can't. That depends on too many factors, on how many processes are running, and so on. You could implement a maybe efficient GC only at OS level, not at the application level, I guess.

No doubt that manual memory allocation is more efficient than GC, even if it can be a bot slower on the short time.
And a good framework can help to keep things simple.

Id rather extend C++ (or make some more modern language, without GC) to include some helpful features, than switch to less efficient languages.

Ciao

Max
Re: C++ FQA [message #12678 is a reply to message #12676] Mon, 12 November 2007 23:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Mon, 12 November 2007 17:22

Quote:


Sorry for being rude, but your understanding of actual GC (and especially conservative GC) is sort of lacking.


That could very well be the case, but I believe I have some if not enough teoretical and practical experience. What exactly did I say that was inaccurate? I was referring to generic garbage collection (no ref-counting though), but biased toward mark and sweep style algorithms, not exactly to D's implementation (about which I have only superficial knowledge). And what do you mean by conservative GC?



Well, your description of allocation as only "moving the pointer" is accurate (IMO, again) for moving collector. Anyway, D, by principle, has conservative GC, which cannot be moving (because you simply do not know where pointers are, therefore you cannot adjust them).

Obviously, for non-moving collectors, allocations are more complicated and fragmentation exists as well.

Quote:


Quote:


And no, you cannot have destructors and GC working together.


Well you can. With a little extra care, you can have fully functional destructors (just be sure never to physically deallocate memory, just do cleanups). But with GC you rarelly need non-trivial destructors. And if the programing language has a "scope" clause like D, things get a lot simpler.



No, you cannot Smile scope is nice, but IMO limited. And finalizers are not destructors, if anything else, they are asynchronous.

Alternatively, you can suggest that GC only cares about memory management and destructors are on demant, but in that case you simply reduce GC to sort of leak checker... (because you have to carefully watch that all destructions do not leave GC collected destructable orphans).

Mirek
Re: C++ FQA [message #12685 is a reply to message #12613] Tue, 13 November 2007 01:56 Go to previous messageGo to next message
Zardos is currently offline  Zardos
Messages: 62
Registered: April 2007
Member
luzr wrote on Sat, 10 November 2007 17:54

cbpporter wrote on Sat, 10 November 2007 11:31


And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower and almost impossible to use efficiently in a multi-threading application.



I mostly agree with this...

Mirek


If we talk about a naive reference counting implementation I agree without hestiation.

About the prejudice: "GC is fast" / "Reference counting is slow":

I have read 3 papers approximately one year ago which showed reference counting can be as fast as garbage collection. In addition there are some benefits. Unfortunately I don't have the links anymore. But you may try goolgle with something like "cycles reference counting" and read the /newer/ papers!

But some basic ideas I still remember:

1.) Aggressive removal of AddRef/RemRef by a static flow analysis of the programm: The idea is to only inc. or dec. reference counters if neccessary. Usually only if a (smart)pointer manipulation is done inside a struct/class/... It is not neccessary to do inc./dec. operation for (smart)pointers on the stack or as function arguments. Probably special care has to be taken for threads. Even for (smart)pointers inside structs many inc./dec. operation can be elimanated by a (not so complicated) static analysis of the programm flow.

2.) Avoiding "Atmoic operations": The simple but effective idea is this. Instead of doing AtmoicInc/AtomicDec operations directly on the refence counters all Increments and Decrements are logged in a buffer with a fixed length. Each thread has it's own buffers! So, no locks are required for the ordinary Inc/Dec. If the buffer is full the buffer is given to a "memory management" thread. This requires a Lock operation, but if we assume a buffer has place for 10000 "Inc/Dec" ops. the synchronization cost boils down to 1/10000 which is negligible.
The memory management thraed finally can perform the inc/dec operations without the expensive "Atmoic" vesions just ordinary ++/--
Benefit: The memory management thread can be tuned to only do a fixed number of delete operations per second. This avoids "cascading deletes" where one destructer call triggers a chain of delete operations. => Even with manual memory management there can be stalls!

=> So we have a concurent - nearly log free - reference counting garbage collection.

3.) Cycles: I have forgotten how they get removed. But it was not to complicated to understand. Yes it costs time to detect the cycles... The cost is reduced by point 1.). In addition the cylcle detection can be performed by the memory management - concurrently - without any additional locks. And again this memory management can be tuned to do only N. operations per second. To really spread the memory mangament cost over time (Of course, this means for some time periods more memory is allocated than necessary).

I think it's a really interesting topic. I always had the feeling Refernce Counting can be supperior over garbage collection... May be the furture brings a revival of the counters....

EDIT: I think 2.) was implemented differently: Instead of having buffer with a fixed length: The memory management thraed performed a "stop the world" (pausing all threads) periodically and fetched the buffers from all running threads. While stop the world sounds like stalling - you have to remember only some pointers to buffers have to be transfered to the menory management thread... After the transfer the world starts rotating again.

[Updated on: Tue, 13 November 2007 02:18]

Report message to a moderator

Re: C++ FQA [message #12686 is a reply to message #12515] Tue, 13 November 2007 02:41 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

luzr

not only are .iml compressed using zlib, but even more importantly, several images are always compressed in a single block
Smile More I know, more I like it Smile

cbpporter

Well these execution freezes are not worse than in JVN or .NET platforms. Actually, they can even be shorter. I would like to see some real-life samples of GC performance, not just speculation or my personal experience. Have you ever used a bigger .NET or JVM application.
Just don`t get me wrong: I develop nearly real-time applications (not RTA actually at all when we discuss Windows issues). I do work with actual hardware devices with a number of protocols. It all runs under highly truncated version of Windows, which doesn`t know much of system-hanging device drivers like CD-ROM ones. So, generally we have no big problems with OS latensy on protocol timeouts like 50-500 msecs.
This way neither Java or .NET, nor similar "heavy" platforms can be used (usually those industrial computers are not that quick as Pentium3/4 to support virtual machines, and memory installed may be below even 64/128 MB).
But I need to use GUI as much as time-critical code working with hardware devices. It all of course is devided into different threads etc. The thing I need most - is efficiency and predictability, afterwards - ease of use.
This all situation makes GC or other hanging solutions totally inacceptable for my tasks. Huge memory consumption is inacceptable too.
Besides, I don`t like complex solutions in a situation when simple solution can be applied without high cost. So that U++ satisfies me by a number of criteria, becoming succesful replacement for Borland C++ Builder.

You can throw rocks at me, but I don`t see necessarity of having general purpose GC when you have experience with constructing/destructing of objects. It all may be good at learning-style languages like basic, but well-organized code generally knows where and when to delete objects - more of that, you may choose a moment to do costly memory operations - when they are the mostly invisible for user (knowing program logic). I just don`t believe that GC can determine these (most effective) moments automatically.

Also.
Speaking about reference counting and GC in such a general way makes hard to think of what is really better. Maybe it would be more efficient to discuss some real-life class to be more spicific and sure in reasons. Just a thought.
Re: C++ FQA [message #12690 is a reply to message #12685] Tue, 13 November 2007 09:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Zardos wrote on Mon, 12 November 2007 19:56


2.) Avoiding "Atmoic operations": The simple but effective idea is this. Instead of doing AtmoicInc/AtomicDec operations directly on the refence counters all Increments and Decrements are logged in a buffer with a fixed length. Each thread has it's own buffers!



Yes, considered this one too. I guess this is promissing idea, but there are many caveats.

Quote:


EDIT: I think 2.) was implemented differently: Instead of having buffer with a fixed length: The memory management thraed performed a "stop the world" (pausing all threads) periodically and fetched the buffers from all running threads. While stop the world sounds like stalling - you have to remember only some pointers to buffers have to be transfered to the menory management thread... After the transfer the world starts rotating again.


Yep, you need to process all buffers unfortunately, otherwise you would get false deletes.

Mirek
Re: C++ FQA [message #12692 is a reply to message #12690] Tue, 13 November 2007 10:14 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Quote:

Just don`t get me wrong: I develop nearly real-time applications (not RTA actually at all when we discuss Windows issues). I do work with actual hardware devices with a number of protocols. It all runs under highly truncated version of Windows, which doesn`t know much of system-hanging device drivers like CD-ROM ones. So, generally we have no big problems with OS latensy on protocol timeouts like 50-500 msecs.
This way neither Java or .NET, nor similar "heavy" platforms can be used (usually those industrial computers are not that quick as Pentium3/4 to support virtual machines, and memory installed may be below even 64/128 MB).

I understand that and I was not trying to convince you to use GC on those machines. I was just giving arguments that a generic GC on a modern PC or similar hardware can save a lot of pain. You can live without it, doing all the memory management manually like in other frameworks, you can give smart pointers from BOOST a shot, you can use something like U++ or you can use GC (even with C++; AFAIK D GC is available/inspired by the C++ GC). For people with a lot of experience and good technical know-how, it's just a matter of compromise between choice and the needs of the project. Yet really knowledgeable C++ programmers are not that common, and managers often have teams formed of a little less experienced programmers. These are the people who introduce memory leaks and who misuse language features, not the guys who can perfectly understand were complex template code with multiple inheritance, virtual inheritance and some hidden macro-magic at the first glance. In such situations, GC can be a good alternative. Also, training time and cost for these programmers is reduced and there are people who refuse to go all the way and acquire full C++ feature knowledge, remaining in a "C with classes + some design patterns( + use of the STL without really understanding it; still so many hand written vectors, lists, etc. in commercial code)"
Re: C++ FQA [message #12696 is a reply to message #12692] Tue, 13 November 2007 10:52 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 13 November 2007 04:14

Quote:

Just don`t get me wrong: I develop nearly real-time applications (not RTA actually at all when we discuss Windows issues). I do work with actual hardware devices with a number of protocols. It all runs under highly truncated version of Windows, which doesn`t know much of system-hanging device drivers like CD-ROM ones. So, generally we have no big problems with OS latensy on protocol timeouts like 50-500 msecs.
This way neither Java or .NET, nor similar "heavy" platforms can be used (usually those industrial computers are not that quick as Pentium3/4 to support virtual machines, and memory installed may be below even 64/128 MB).

I understand that and I was not trying to convince you to use GC on those machines. I was just giving arguments that a generic GC on a modern PC or similar hardware can save a lot of pain. You can live without it, doing all the memory management manually like in other frameworks, you can give smart pointers from BOOST a shot, you can use something like U++ or you can use GC (even with C++; AFAIK D GC is available/inspired by the C++ GC). For people with a lot of experience and good technical know-how, it's just a matter of compromise between choice and the needs of the project. Yet really knowledgeable C++ programmers are not that common, and managers often have teams formed of a little less experienced programmers. These are the people who introduce memory leaks and who misuse language features, not the guys who can perfectly understand were complex template code with multiple inheritance, virtual inheritance and some hidden macro-magic at the first glance. In such situations, GC can be a good alternative. Also, training time and cost for these programmers is reduced and there are people who refuse to go all the way and acquire full C++ feature knowledge, remaining in a "C with classes + some design patterns( + use of the STL without really understanding it; still so many hand written vectors, lists, etc. in commercial code)"


Well, of course. Nobody disputes that finding average Java programmer is much more simple than hiring good C++ programmer - and that hiring average C++ programmer is a threat to the project...

Mirek
Previous Topic: Tools or methodologies you use when developing software
Next Topic: About vista....
Goto Forum:
  


Current Time: Thu Mar 28 21:15:14 CET 2024

Total time taken to generate the page: 0.01685 seconds