http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Exception Misconceptions: Exceptions are for unrecoverable errors. - 22
messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
* Exception Misconceptions: Exceptions are better than return values - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/5afe6eb8af0f3da5?hl=en
* Locale to Unicode Codepoint mapping? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0f87b730b24e407a?hl=en
==============================================================================
TOPIC: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================
== 1 of 22 ==
Date: Fri, Dec 25 2009 1:54 pm
From: tanix@mongo.net (tanix)
In article <hh3bev$lj9$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>tanix wrote:
>> In article
> <ec7d2a9b-ee76-46b6-ae3a-587d199b66f0@s3g2000yqs.googlegroups.com>, James
> Kanze <james.kanze@gmail.com> wrote:
>>> On Dec 23, 11:21 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>> tanix wrote:
>>>>> In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic
>>> <vladasp...@gmail.com> wrote:
>>>>> C++ would probably be benefited tremendously if it adopted some
>>>>> of the central Java concept, such as GC, threads and GUI.
>>>> GC is heavy performance killer especially on multiprocessor systems
>>>> in combination with threads....it is slow, complex and inefficient...
>>> Obviously, you've never actually measured. A lot depends on the
>>> application, but typically, C++ with garbage collection runs
>>> slightly faster than C++ without garbage collection. Especially
>>> in a multi-threaded envirionment,
>>>
>>> [...]
>>>>> Except that would require an equivalent of a virtual machine
>>>>> underneath.
>>>> virtual machine is also heavy performance killer...
>>> Which explains why some of the leading experts in optimization
>>> claim that it is necessary for the best optimization. (I don't
>>> fully buy that claim, but a virtual machine does have a couple
>>> of advantages when it come to optimizing: it sees the actual
>>> data being processed, for example, and the actual machine being
>>> run on, and can optimize to both.)
>>
>> Yep. And the more high level some abstraction is,
>> the more performance it can gain and the less of even theoretical
>> advantage any other approach may claim.
>
>You believe in ferry tales... ;0)
I don't have to believe. It is pretty much self evident.
Why?
Well, because the higher level is your abstraction,
the less impact the language has. Because you have a virtual machine
underneeth that can do anything you please, and as efficiently
as anything else under the sun.
Basically, you are running a machine code at that level.
About the only thing you can claim is: well, but what are those
additional calls? Well, yep, there IS a theoretical overhead.
But once you start looking at the nasty details of it, it all
becomes pretty much a pipe dream.
There are ALL sorts of things that happen under the hood, and
in plenty of cases, your low level details become insignificant
in the scheme of things.
Simple as that.
>Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 2 of 22 ==
Date: Fri, Dec 25 2009 2:01 pm
From: Branimir Maksimovic
tanix wrote:
> In article <hh3bev$lj9$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> tanix wrote:
>>> In article
>>> Yep. And the more high level some abstraction is,
>>> the more performance it can gain and the less of even theoretical
>>> advantage any other approach may claim.
>> You believe in ferry tales... ;0)
>
> I don't have to believe. It is pretty much self evident.
> Why?
>
> Well, because the higher level is your abstraction,
> the less impact the language has. Because you have a virtual machine
> underneeth that can do anything you please, and as efficiently
> as anything else under the sun.
Virtual machines are always slower then real machines....
No matter what, one can optimize as far as it
goes just simple cases. Anything non trivial,
and very difficult to optimize like java code...
Greets
== 3 of 22 ==
Date: Fri, Dec 25 2009 2:12 pm
From: Branimir Maksimovic
James Kanze wrote:
> On Dec 24, 10:11 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
>> tanix wrote:
>>> In article <hguelj$k4...@news.albasani.net>, Branimir Maksimovic <bm...@hotmail.com> wrote:
>
> [...]
>> Memory managment is not a problem. You can implement GC, for
>> any apllication even in assembler. Reference counting is
>> simple form of gc and works well in c++ because of RAII.
>
> Reference counting doesn't work in C++, because of cycles. And
> reference counting is very, very slow compared to the better
> garbage collector algorithms.
>
Hm, have you ever head cycles? In my long experience I never
had cyclic references...
Reference counting can;t be slow because it does not have
to lock all threads, neither is incrementing decrementing
variable slow in comparison with complete memory scan every time
gc have to chase pointeras through cyclic graph inside
application. No matter what you do , it is impossible
to make it faster than refcounting...
> [...]
>> And somebodey tried to convince me that conservative GC is
>> faster that shared_ptr/auto_ptr (what a ....;)
>
> And you refused to even look at actual measurements. I'm aware
> of a couple of programs where the Boehm collector significantly
> out performs boost::shared_ptr. (Of course, I'm also aware of
> cases where it doesn't. There is no global perfect solution.)
Hm, how can possibly complex algorithm outperform simple
reference counting. Try to measure deallocation speed.
Allocation in GC is same as manual allocation. But
deallocation is where it performs complex algorithm.
Greets
== 4 of 22 ==
Date: Fri, Dec 25 2009 2:23 pm
From: tanix@mongo.net (tanix)
In article <hh3bsb$me3$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>James Kanze wrote:
>> On Dec 23, 11:21 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>> tanix wrote:
>>>> In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic
> <vladasp...@gmail.com> wrote:
>>>> C++ would probably be benefited tremendously if it adopted some
>>>> of the central Java concept, such as GC, threads and GUI.
>>
>>> GC is heavy performance killer especially on multiprocessor systems
>>> in combination with threads....it is slow, complex and inefficient...
>>
>> Obviously, you've never actually measured. A lot depends on the
>> application, but typically, C++ with garbage collection runs
>> slightly faster than C++ without garbage collection. Especially
>> in a multi-threaded envirionment,
>
>How that can possibly be? GC kills all threads when it has
>to collect? Or it can magically sweep through heap,stack,bss
>etc and scan without locking all the time or stopping program?
>Explain to me how?
>Manual deallocation does not have to lock at all....
>
>>
>> [...]
>>>> Except that would require an equivalent of a virtual machine
>>>> underneath.
>>
>>> virtual machine is also heavy performance killer...
>>
>> Which explains why some of the leading experts in optimization
>> claim that it is necessary for the best optimization. (I don't
>> fully buy that claim, but a virtual machine does have a couple
>> of advantages when it come to optimizing: it sees the actual
>> data being processed, for example, and the actual machine being
>> run on, and can optimize to both.)
>
>Best optimization is when you can manually control memory management
>and have access to hardware directly. Everything else
>is algorithm optimization...which can be done in any language.
Looks appealing in the local scope of things.
If you get too obscessed trying to save some machine cycles,
then yes, you do have a point.
The problem is in application of any complexity, even worth mentioning,
you are no longer dealing with machine instructions, however appealing
it might look.
You are dealing with SYSTEMS.
You are dealing with structures and higher level logical constructs.
By simply changing your architecture, you may achieve orders of
magnitude more performance. And performance is not the only thing
that counts in something in the real world, although it counts
probably more than ohter things.
Except stability.
And what other things are functionality, flexibility, configurability,
the power and clarity of your user interface, that turns out to be
one of the most imporant criteria, and plenty of other things.
Yes, if you think of your code as an assembly level set of instructions,
and not matter which instruction you are looking at, you are trying
to squeze every single machine cycle out of it, then you are not
"seeing the forest for the trees".
What I see using my program is not how efficient some subcomponent
is, but how many hours does it take me to process vast amounts
of information. I could care less if GC exist, except it helps me
more than it creates problems for it, and I don't even need to
prove it to anybody. It is self evident to me. After a while, you
stop questioning certain things if you saw a large enough history.
What is the point to forever flip those bits?
Let language designers think about these things, and I assume they
have done as good of a job doing it, as state of the art allows,
especially if they are getting paid tons of money for doing that.
I trust them. I may not agree with some things, and my primary
concerns nowadays are not whether GC is more or less efficient,
but how fast I can model my app, how easy it is to do that,
how supportive my IDE, how powerful my debugger is, how easy it
is for me to move my app to a different platform and things
like this.
You can nitpick all you want, but I doubt you will be able to
prove anything of substance by doing that kind of thing.
To me, it is just a royal waste of time. Totally unproductive.
>>>> And that is one of central issues with Java.
>>> Yes.
>>> I think java is designed in such way that it will still be slow in
>>> comparison to other compiled languages...if it is compiled
>>> language.
>>
>> First, Java is a compiled language, and second, it's not slower
>> than any of the other compiled languages, globally. (Specific
>> programs may vary, of course.)
>
>Java is compiled language in a sense that any interpreted language
>is run time compiled...
Not true.
>but that does not makes those languages
>compiled...
Java IS compiled. Period.
Would you argue with a concept of P-Machine on the basis that
it is "interpetive", just because it uses the higher level
abstraction, sitting on the top of O/S?
Java does not evaluate strings run time and it is a strongly
typed language, and that IS the central difference between
what I call dynamically scoped languages and statically
scoped languages.
It does not matter to me if Java runs bytecodes or P-Machine
code. It is just another layer on the top of O/S, and that layer,
by the sheer fact that it is a higher level abstraction,
can optimize things under the hood MUCH better than you can
optimize things with languages with lower levels of abstraction.
For some reason, people have gotten away from coding in
assembly languages for most applications.
This is exactly the same thing.
What is the difference between C++ and C?
Well, the ONLY difference I know is higher level of abstraction.
And that is ALL there is to it.
The same exact thing as Java using the JVM to provide it the
underlying mechanisms, efficient enough and flexible enough
for you to be able to express yourself on a more abstract level.
And that is ALL there is to it.
And why do you think weakely typed languages are gaining ground?
Well, because you don't have to worry about all those nasty
things as arguments. They can be anything in run time.
And nowdays, the power of the underlying hardware is such,
that it no longer makes such a drastic difference whether you
run a strongly typed, compiled language or interpret it on
the fly, even though performance is order of magnitudes worse.
You need to put things in perspective.
What does it matter to me if web page renders in 100 ms.
versus 1 ms.?
NONE.
My brain can not work that fast to read anything in those 99 ms.
anyway.
I think the whole argument is simply a waste of time, or rather,
a waste of creative potential that could be used for something
WAY more constructive and WAY more "revolutionary".
>For example php with popen calling c executable in my experience
>is about three times faster as a server than jetty/solr
>for example...
Well, if you use even PHP as some kind of argument, then you
are obviosly not seen the forest. Because PHP is one of the
worst dogs overall. Because it is weakly typed language.
Even Python beats it hands down.
>Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 5 of 22 ==
Date: Fri, Dec 25 2009 2:29 pm
From: Branimir Maksimovic
tanix wrote:
>> For example php with popen calling c executable in my experience
>> is about three times faster as a server than jetty/solr
>> for example...
>
> Well, if you use even PHP as some kind of argument, then you
> are obviosly not seen the forest. Because PHP is one of the
> worst dogs overall. Because it is weakly typed language.
>
> Even Python beats it hands down.
No. cath is not in php, rather c executable for every request
initializes about 256 mb of ram of data every time and
uses simple printfs to return through pipe result to php,
and perfomrs three times faster then java jetty/solr which
hodls everything initizalized in memory...
as a search engine...
>
>> Greets
>
> --
> Programmer's Goldmine collections:
>
> http://preciseinfo.org
>
> Tens of thousands of code examples and expert discussions on
> C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
> organized by major topics of language, tools, methods, techniques.
>
== 6 of 22 ==
Date: Fri, Dec 25 2009 2:32 pm
From: tanix@mongo.net (tanix)
In article <hh3co5$nds$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>tanix wrote:
>> In article <hh3bev$lj9$1@news.albasani.net>, Branimir Maksimovic
> <bmaxa@hotmail.com> wrote:
>>> tanix wrote:
>>>> In article
>>>> Yep. And the more high level some abstraction is,
>>>> the more performance it can gain and the less of even theoretical
>>>> advantage any other approach may claim.
>>> You believe in ferry tales... ;0)
>>
>> I don't have to believe. It is pretty much self evident.
>> Why?
>>
>> Well, because the higher level is your abstraction,
>> the less impact the language has. Because you have a virtual machine
>> underneeth that can do anything you please, and as efficiently
>> as anything else under the sun.
>
>Virtual machines are always slower then real machines....
This is a blanket statement by someone who is obscessed with
machine cycles while his grand piece of work is not even worth
mentioning, I'd say.
>No matter what, one can optimize as far as it
>goes just simple cases. Anything non trivial,
Correct.
>and very difficult to optimize like java code...
I don't have to optimize Java code in any special way.
It is the same way no matter WHAT language it is.
One more time: to me, program is a SYSTEM.
And the MOST critical parameter in the system is:
STABILITY.
Why? Because if your program is not stable, you are dead.
Yes, everyone wants performance. No question about it.
You don't want to sit there for 30 seconds waiting for your
frozen GUI to get unfrozen so you can enter some parameters
or type something somewhere.
And the reason it is frozen for that long of a time is not
matter of machine instructions or the "efficiency" of your
code. It is a matter of TOTALLY wrong design.
Program is not just a hack and tons of "efficient" spaghetti
code. It is HIGLY complex system with billions of interactions,
and MANY substystems cooperating under the hood.
It is not some fancy hex calculator where you flip some bits.
Unless programs are viewed as a system, you will be trying
to pick a piece of crap from some output hole and look at it
with a magnifying glass trying to make conclusions as what
the human being.
>Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 7 of 22 ==
Date: Fri, Dec 25 2009 2:34 pm
From: tanix@mongo.net (tanix)
In article <hh3dco$osh$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>James Kanze wrote:
>> On Dec 24, 10:11 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>> tanix wrote:
>>>> In article <hguelj$k4...@news.albasani.net>, Branimir Maksimovic
> <bm...@hotmail.com> wrote:
>>
>> [...]
>>> Memory managment is not a problem. You can implement GC, for
>>> any apllication even in assembler. Reference counting is
>>> simple form of gc and works well in c++ because of RAII.
>>
>> Reference counting doesn't work in C++, because of cycles. And
>> reference counting is very, very slow compared to the better
>> garbage collector algorithms.
>>
>Hm, have you ever head cycles? In my long experience I never
>had cyclic references...
>Reference counting can;t be slow because it does not have
>to lock all threads, neither is incrementing decrementing
>variable slow in comparison with complete memory scan every time
>gc have to chase pointeras through cyclic graph inside
>application. No matter what you do , it is impossible
>to make it faster than refcounting...
Looks like it is a matter of life and death to you.
But I doubt you can win this argument.
>> [...]
>>> And somebodey tried to convince me that conservative GC is
>>> faster that shared_ptr/auto_ptr (what a ....;)
>>
>> And you refused to even look at actual measurements. I'm aware
>> of a couple of programs where the Boehm collector significantly
>> out performs boost::shared_ptr. (Of course, I'm also aware of
>> cases where it doesn't. There is no global perfect solution.)
>
>Hm, how can possibly complex algorithm outperform simple
>reference counting. Try to measure deallocation speed.
>Allocation in GC is same as manual allocation. But
>deallocation is where it performs complex algorithm.
And so it goes "till your nose goes blue"...
:--}
>Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 8 of 22 ==
Date: Fri, Dec 25 2009 2:36 pm
From: Branimir Maksimovic
tanix wrote:
>> Virtual machines are always slower then real machines....
>
> This is a blanket statement by someone who is obscessed with
> machine cycles while his grand piece of work is not even worth
> mentioning, I'd say.
Well, I've started and stopped application which controlled Shanghai
airptort back in 1993. Two stratus engineers besides me , I work
on 4 terminals in emacs with C language and VOS operating
system...
I was hired by stratus then as expert for c programming language...
Greets
--
http://.....
== 9 of 22 ==
Date: Fri, Dec 25 2009 2:39 pm
From: tanix@mongo.net (tanix)
In article <hh3c3g$mea$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>James Kanze wrote:
>> On Dec 24, 2:03 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>> Stefan Ram wrote:
>>
>> [...]
>>> Allocation is not where GC fails, rather deallocation....
>>
>> It doesn't fail there, either. But any comparison should take
>> deallocation into consideration. (Well, formally... there's no
>> deallocation with garbage collection. But the system must take
>> some steps to determine when memory can be reused.)
I DO like that one. What a master stroke!
:--}
>>> Because there is no fastest and simpler way to perform
>>> collection, than to stop program, perform collection in
>>> multiple threads, then let program work....
>>
>> Try Googleing for "incremental garbage collection".
>>
>Incremental garbage collection is form of collection when
>you don;t free everything immediately, but this does not
>change a fact whenever you have to see if something is referenced
>or not you have to stop program and examine pointers,
Yes. This IS becoming a matter of life and death issue it seems.
:--}
>which of course kills performance of threads...
>
>Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 10 of 22 ==
Date: Fri, Dec 25 2009 2:41 pm
From: Branimir Maksimovic
tanix wrote:
> In article <hh3c3g$mea$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Dec 24, 2:03 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>> Stefan Ram wrote:
>>> [...]
>>>> Allocation is not where GC fails, rather deallocation....
>>> It doesn't fail there, either. But any comparison should take
>>> deallocation into consideration. (Well, formally... there's no
>>> deallocation with garbage collection. But the system must take
>>> some steps to determine when memory can be reused.)
>
> I DO like that one. What a master stroke!
>
> :--}
>
>>>> Because there is no fastest and simpler way to perform
>>>> collection, than to stop program, perform collection in
>>>> multiple threads, then let program work....
>>> Try Googleing for "incremental garbage collection".
>>>
>> Incremental garbage collection is form of collection when
>> you don;t free everything immediately, but this does not
>> change a fact whenever you have to see if something is referenced
>> or not you have to stop program and examine pointers,
>
> Yes. This IS becoming a matter of life and death issue it seems.
>
> :--}
Ok, I give, Merry Christmass! ;)
>
Greets
--
http://.......
== 11 of 22 ==
Date: Fri, Dec 25 2009 2:43 pm
From: tanix@mongo.net (tanix)
In article <hh3eoo$qt3$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>tanix wrote:
>>> Virtual machines are always slower then real machines....
>>
>> This is a blanket statement by someone who is obscessed with
>> machine cycles while his grand piece of work is not even worth
>> mentioning, I'd say.
>
>Well, I've started and stopped application which controlled Shanghai
>airptort back in 1993.
Don't know what you mean by that, but yes, sounds impressive.
> Two stratus engineers besides me , I work
>on 4 terminals in emacs with C language and VOS operating
>system...
Wooo! That's definetely impressive.
Good. Than fix C++ so I can go back to it.
After all, it is one of the first "higher level" languages
I had to deal with. I kinda hunts you...
>I was hired by stratus then as expert for c programming language...
Good. I don't remember what Stratus stands for, but I do recall
hearing it somewhere on more or less big scale. What did they do?
>Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 12 of 22 ==
Date: Fri, Dec 25 2009 2:45 pm
From: tanix@mongo.net (tanix)
In article <hh3ebp$q3r$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>tanix wrote:
>>> For example php with popen calling c executable in my experience
>>> is about three times faster as a server than jetty/solr
>>> for example...
>>
>> Well, if you use even PHP as some kind of argument, then you
>> are obviosly not seen the forest. Because PHP is one of the
>> worst dogs overall. Because it is weakly typed language.
>>
>> Even Python beats it hands down.
>
>No. cath is not in php, rather c executable for every request
>initializes about 256 mb of ram of data every time and
>uses simple printfs to return through pipe result to php,
>and perfomrs three times faster then java jetty/solr which
>hodls everything initizalized in memory...
>as a search engine...
Well, I'd be curious to see more specifics on this.
>>> Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 13 of 22 ==
Date: Fri, Dec 25 2009 2:47 pm
From: tanix@mongo.net (tanix)
In article <hh3f2a$qt3$2@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>tanix wrote:
>> In article <hh3c3g$mea$1@news.albasani.net>, Branimir Maksimovic
> <bmaxa@hotmail.com> wrote:
>>> James Kanze wrote:
>>>> On Dec 24, 2:03 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>>> Stefan Ram wrote:
>>>> [...]
>>>>> Allocation is not where GC fails, rather deallocation....
>>>> It doesn't fail there, either. But any comparison should take
>>>> deallocation into consideration. (Well, formally... there's no
>>>> deallocation with garbage collection. But the system must take
>>>> some steps to determine when memory can be reused.)
>>
>> I DO like that one. What a master stroke!
>>
>> :--}
>>
>>>>> Because there is no fastest and simpler way to perform
>>>>> collection, than to stop program, perform collection in
>>>>> multiple threads, then let program work....
>>>> Try Googleing for "incremental garbage collection".
>>>>
>>> Incremental garbage collection is form of collection when
>>> you don;t free everything immediately, but this does not
>>> change a fact whenever you have to see if something is referenced
>>> or not you have to stop program and examine pointers,
>>
>> Yes. This IS becoming a matter of life and death issue it seems.
>>
>> :--}
>
>Ok, I give, Merry Christmass! ;)
You do not have to give. Otherwise, what are we going to do here?
:--}
I'd just like to see something more elegant of an argument.
>Greets
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 14 of 22 ==
Date: Fri, Dec 25 2009 2:49 pm
From: Branimir Maksimovic
tanix wrote:
> In article <hh3f2a$qt3$2@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> tanix wrote:
>>> In article <hh3c3g$mea$1@news.albasani.net>, Branimir Maksimovic
>> <bmaxa@hotmail.com> wrote:
>>>> James Kanze wrote:
>>>>> On Dec 24, 2:03 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>>>> Stefan Ram wrote:
>>>>> [...]
>>>>>> Allocation is not where GC fails, rather deallocation....
>>>>> It doesn't fail there, either. But any comparison should take
>>>>> deallocation into consideration. (Well, formally... there's no
>>>>> deallocation with garbage collection. But the system must take
>>>>> some steps to determine when memory can be reused.)
>>> I DO like that one. What a master stroke!
>>>
>>> :--}
>>>
>>>>>> Because there is no fastest and simpler way to perform
>>>>>> collection, than to stop program, perform collection in
>>>>>> multiple threads, then let program work....
>>>>> Try Googleing for "incremental garbage collection".
>>>>>
>>>> Incremental garbage collection is form of collection when
>>>> you don;t free everything immediately, but this does not
>>>> change a fact whenever you have to see if something is referenced
>>>> or not you have to stop program and examine pointers,
>>> Yes. This IS becoming a matter of life and death issue it seems.
>>>
>>> :--}
>> Ok, I give, Merry Christmass! ;)
>
> You do not have to give. Otherwise, what are we going to do here?
> :--}
>
> I'd just like to see something more elegant of an argument.
I thought I give up ;) , Merry Christmass, gain ;)
>
>> Greets
== 15 of 22 ==
Date: Fri, Dec 25 2009 3:03 pm
From: LR
Branimir Maksimovic wrote:
> Java is compiled language in a sense that any interpreted language
> is run time compiled...but that does not makes those languages
> compiled...
What about JIT compilation?
LR
== 16 of 22 ==
Date: Fri, Dec 25 2009 3:03 pm
From: Branimir Maksimovic
tanix wrote:
> In article <hh3ebp$q3r$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> tanix wrote:
>>>> For example php with popen calling c executable in my experience
>>>> is about three times faster as a server than jetty/solr
>>>> for example...
>>> Well, if you use even PHP as some kind of argument, then you
>>> are obviosly not seen the forest. Because PHP is one of the
>>> worst dogs overall. Because it is weakly typed language.
>>>
>>> Even Python beats it hands down.
>> No. cath is not in php, rather c executable for every request
>> initializes about 256 mb of ram of data every time and
>> uses simple printfs to return through pipe result to php,
>> and perfomrs three times faster then java jetty/solr which
>> hodls everything initizalized in memory...
>> as a search engine...
>
> Well, I'd be curious to see more specifics on this.
>
You want me to tell which search engine it is ;)
I can;t tell you that...
Greets
== 17 of 22 ==
Date: Fri, Dec 25 2009 3:11 pm
From: Branimir Maksimovic
LR wrote:
> Branimir Maksimovic wrote:
>
>> Java is compiled language in a sense that any interpreted language
>> is run time compiled...but that does not makes those languages
>> compiled...
>
> What about JIT compilation?
>
> LR
Well, every interpreter can compile code after it interprets it.
Java compiles to byte code, which cannot be executed
natively...
If that counts, than it is compiled language...
Greets
== 18 of 22 ==
Date: Fri, Dec 25 2009 3:12 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
LR <lruss@superlink.net> writes:
>Branimir Maksimovic wrote:
>>Java is compiled language in a sense that any interpreted language
>>is run time compiled...but that does not makes those languages
>>compiled...
>What about JIT compilation?
Compilation is not a property of languages but of implementations.
(However, when the language has an »eval«, each implementation also
needs to provide an interpreter.)
== 19 of 22 ==
Date: Fri, Dec 25 2009 3:15 pm
From: James Kanze
On Dec 25, 2:30 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> James Kanze <james.ka...@gmail.com> writes:
> >As I said before, never trust a benchmark you haven't falsified
> Yes, of course, it all starts with the fact, that one cannot
> compare the speed of languages but only the speed of
> specific programs running under a specific /implementation/
> of a language running under a specific operating system
> running on a specific hardware.
Yes. And the fact that any given implementation (and any given
language, for that matter) will have it's strong points and its
weak points. If you want a language to look good, you write to
its strong points, and to the other languages weak points.
> What is language-specific is only the fact that some
> language features make some kinds of optimization possible
> (like restrict in C) or impossible (e.g., when aliasing by
> pointers is possible).
There's possible and impossible, but but there's also
difficulty. There are C++ compilers, for example, which use
profiler output, and if it makes a difference, generate two
versions of a function, depending on whether there is aliasing
or not, with a quick test at the top to decide which one to use.
But it's a lot more effort than in Java. Similarly, given an
array of Point (where Point is basically 2 double), it's
perfectly conceivable that a Java compiler treat it as an array
of double[2]. But it's a lot more work, and a lot less likely,
than for a C++ compiler.
> So, if I had to implement some algorithm, I would not refuse
> Java from the first, because it is slow , but do some
> benchmarking with code in the direction of that algorithm.
Exactly. Most of the time, what eliminates Java is that it
doesn't support really robust programming.
> After all, /if/ Java is sufficiently fast for my purpose,
> it gives me some conveniences, such as run-time array index
> checking, automatic memory management and freedom from
> the need for (sometimes risky) pointer arithmetics.
It also pretty much makes programming by contract impossible,
requires implementations of concrete classes to be in the same
file as the class definition, and does a number of other things
which make programming in the large difficult.
That said, it's not a bad language for small non-critical
applications. And it has a pretty nice GUI library, and is well
integrated in web server environments.
--
James Kanze
== 20 of 22 ==
Date: Fri, Dec 25 2009 3:25 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
James Kanze <james.kanze@gmail.com> writes:
>what eliminates Java is that it doesn't support really robust
>programming. It also pretty much makes programming by
>contract impossible, requires implementations of concrete
>classes to be in the same file as the class definition.
If you would like to provide a minimal example of C++ source code
with a class definition and a concrete class in two different
files, I hope that I then can show how to do the same in Java.
== 21 of 22 ==
Date: Fri, Dec 25 2009 3:48 pm
From: James Kanze
On Dec 25, 7:01 pm, ta...@mongo.net (tanix) wrote:
> In article
> <ec7d2a9b-ee76-46b6-ae3a-587d199b6...@s3g2000yqs.googlegroups.com>,
> James Kanze <james.ka...@gmail.com> wrote:
[...]
> >> virtual machine is also heavy performance killer...
> >Which explains why some of the leading experts in
> >optimization claim that it is necessary for the best
> >optimization. (I don't fully buy that claim, but a virtual
> >machine does have a couple of advantages when it come to
> >optimizing: it sees the actual data being processed, for
> >example, and the actual machine being run on, and can
> >optimize to both.)
> Yep. And the more high level some abstraction is, the more
> performance it can gain and the less of even theoretical
> advantage any other approach may claim.
More generally, the more information a compiler has, including
information concerning why some operation is taking place, the
better it can optimize. It's pretty well established that when
the language has built in bounds checking (so the compiler knows
the why of the comparisons), the compiler can generate better
code.
In the case of a VM, of course, the compiler has very exact
knowledge about the input data, the frequency of the various
paths, and the CPU it is running on. All of which are important
information. Where I have my doubts is because in a VM, the
compiler is severely limited in the time it can take for its
analysis; if an optimizing compiler takes a couple of hours
analysing all of the variations, fine, but in a VM? But since
I'm not an expert in this field, I don't really know.
> >> > And that is one of central issues with Java.
> >> Yes.
> >> I think java is designed in such way that it will still be
> >> slow in comparison to other compiled languages...if it is
> >> compiled language.
> >First, Java is a compiled language, and second, it's not
> >slower than any of the other compiled languages, globally.
> >(Specific programs may vary, of course.)
> And that is exactly what I am seeing in my own situation.
The few measurements I've made would bear you out. I'm sure
that there are applications where C++ will be faster, and there
are probably some where Java will be faster, but for most
applications, C++ is chosen not for speed, but because it has
greater expressibility.
--
James Kanze
== 22 of 22 ==
Date: Fri, Dec 25 2009 3:50 pm
From: James Kanze
On Dec 25, 10:32 pm, ta...@mongo.net (tanix) wrote:
> In article <hh3co5$nd...@news.albasani.net>, Branimir
> Maksimovic <bm...@hotmail.com> wrote:
[...]
> >Virtual machines are always slower then real machines....
> This is a blanket statement by someone who is obscessed with
> machine cycles while his grand piece of work is not even worth
> mentioning, I'd say.
Above all, it's a statement made by someone who's never made any
actual measurements, nor spoken to experts in the field.
--
James Kanze
==============================================================================
TOPIC: Exception Misconceptions: Exceptions are better than return values
http://groups.google.com/group/comp.lang.c++/t/5afe6eb8af0f3da5?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 20 2009 12:02 am
From: "dragan"
tanix wrote:
[what you wrote]
Wow. And I was worried about being "inflamatory" or "anti-social" or
something. I wouldn't hire him on my best day, but wo is me, I don't have
and never will have his ability/knowledge/etc.... that said, I know him, he
wants to live forever. Huh JK? ;) Hey, maybe some of this Bobama money
floating around .... (I don't want it: call it "bad upbringing" or
whatever). Aren't weekends fun?'
Not to dillude: "thx" tannix. "you take the cake". :P
== 2 of 2 ==
Date: Fri, Dec 25 2009 2:24 pm
From: tanix@mongo.net (tanix)
In article <FSkXm.8834$Gf3.5046@newsfe18.iad>, "dragan" <spambuster@prodigy.net> wrote:
>tanix wrote:
>
>[what you wrote]
>
>Wow. And I was worried about being "inflamatory" or "anti-social" or
>something. I wouldn't hire him on my best day, but wo is me, I don't have
>and never will have his ability/knowledge/etc.... that said, I know him, he
>wants to live forever. Huh JK? ;) Hey, maybe some of this Bobama money
>floating around .... (I don't want it: call it "bad upbringing" or
>whatever). Aren't weekends fun?'
>
>Not to dillude: "thx" tannix. "you take the cake". :P
I am glad you are so proud of your masterpice that you feel
it needs to be reposted, just to make sure such a grand piece of work
does not die in the shuffle.
:--}
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
==============================================================================
TOPIC: Locale to Unicode Codepoint mapping?
http://groups.google.com/group/comp.lang.c++/t/0f87b730b24e407a?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Dec 25 2009 2:51 pm
From: "Peter Olcott"
"Paavo Helde" <myfirstname@osa.pri.ee> wrote in message
news:Xns9CECB7082E9B4paavo256@216.196.109.131...
> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in
> news:EMCdnTXL-
> 5ZSW6nWnZ2dnUVZ_qudnZ2d@giganews.com:
>
>>
>> "James Kanze" <james.kanze@gmail.com> wrote in message
>> news:991f32d8-319c-45ad-9b9c-12a7f2a3daef@s31g2000yqs.googlegroups.com...
>>> On Dec 23, 6:27 pm, "Peter Olcott"
>>> <NoS...@SeeScreen.com>
>>> wrote:
>>>> I need to know the set of Unicode codepoints associated
>>>> with
>>>> every regional dialect of a human language. How can I
>>>> go
>>>> about finding this information?
>>>
>>> www.unicode.org. Go to the code charts under the
>>> standard.
>>>
>>> In general, for such things, look for the reference
>>> site.
>>> This
>>> one is actually very well done, but even in the case of
>>> those
>>> that are less well done, the reference is the reference.
>>>
>>> --
>>> James Kanze
>>
>> I already studied these for many hours. They do not have
>> what I need. I need to know the exact subset of Unicode
>> code
>> points that apply to a specific dialect of a specific
>> language. A superset of these will not do, I must have
>> the
>> minimum set of code points.
>
> Do you realize that there are thousands of languages and
> dialects?
> WikiAnswers offers a number like 2261 for the number of
> languages having a
> writing system.
>
> In any case, the local alphabete ultimately depends on the
> local national
> decisions and conventions - which characters are
> considered to belong to
> the national character set, and which are not. This can
> change over time.
>
>
>> This has to be known because the
>> keyboard must know which glyphs to produce.
>
> Knowing what characters some vendor has decided to include
> in a keyboard
> mapping for given language might help of course. However,
> this must not be
> relied on too much.
>
>> I am working on internationalizing this system:
>> www.OCR4Screen.com
>>
>
> For OCR-like tasks one also has to consider that text can
> often contain
> foreign characters and even words. For example, in Russian
> technical texts
> it is common to type technical terms in Latin alphabete.
> To make things
> worse, there are many symbols which have the same look in
> Cyrillic and in
> Latin, but correspond to different Unicode code points.
> Recognizing them
> correctly is no easy task.
>
> 5-minute Google search produced these pages, maybe these
> are of any help:
>
> http://developer.mimer.com/charts/index.tml
> http://www.evertype.com/alphabets/
>
> Paavo
Those links are exactly what I needed, thanks!
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment