Friday, November 14, 2014

Digest for comp.lang.c++@googlegroups.com - 25 updates in 9 topics

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
JiiPee <no@notvalid.com>: Nov 14 03:30AM

To continue about int to string conversion discussion.
Now I have tested again std/C++ library int to string conversion
functions with Visual Studio and gcc, and I still get that std and C++
library functions are way slower than our conversion functions
(including my fastest I just made). (all code is below the message)
 
Some of you are already familiar with the function somebody made on one
site, I call it intToStr. It uses 200 size char-string look-up table to
convert for example 49 to '4','9'. I suggested even faster version by
using 40000 look-up table converting four integers: like 4691 -> '4' '6'
'9' '1' . I just implemented it, and it makes it even faster! I call it
intToStrSuperFast.
 
I have Windows XP 32 bit, using 1 cpu, Visual Studio 2008 and 2010, gcc
(using O3 optimization). compiler: GCC 4.8.1, use C++11, -O3, -s
Here are the results:
 
loop: for(i = 0; i < 4294966000; i += 20)
->about. 215 million ints
 
Seconds it took to convert ints to string:
intToStrSuperFast : 3.415 s
intToStr : 4.687 s (+37%)
snprintf (gcc) : 588 s (+17118%)
_snprintf (VC2008) : 112 s (+3179%)
_snprintf (VC2010) : 140 s (+3999%)
_itoa (VC2008) : 36.9 s (+980%)
 
As we can see, intToStrSuperFast is even 37% faster than intToStr.
Also I tested itoa which is much faster than snprintf but still 9 times
slower than intToStr.
Strange that GCC snprintf is 5 times slower than Microsoft one.
Now, many said that in real program it would not be this fast. So I
would like to next see that in what kind of program this would be the case.
 
Also am still confused why others say they run this same code and
intToStr was only 2 times faster than snprintf. Did you definitely run
exactly the same code I am running below? Or is this because of 64 bit
machines/windows 7 doing things differently?
 
Would be nice if somebody could make a simple program which uses
intToStrSuperFast and makes it slow as many here said it could be when
creating a normal program.
 
Can somebody test the code below so we see if you get similar results as
I got?
 
code:
 
#include <stdio.h>
#include <iostream>
#include <ctime>
#include <stdlib.h>
#include <stdio.h>
#include <string>
#include <vector>
#include <limits>
#include <cstring>
 
const char digit_pairs[201] = {
"00010203040506070809"
"10111213141516171819"
"20212223242526272829"
"30313233343536373839"
"40414243444546474849"
"50515253545556575859"
"60616263646566676869"
"70717273747576777879"
"80818283848586878889"
"90919293949596979899"
};
 
char digit_pairs_sf[50000];
 
void init_digit_pairs_sf()
{
int ind = 0;
for(int a=0; a<=9; ++a)
{
for(int b=0; b<=9; ++b)
{
for(int c=0; c<=9; ++c)
{
for(int d=0; d<=9; ++d)
{
digit_pairs_sf[ind++] = '0' + a;
digit_pairs_sf[ind++] = '0' + b;
digit_pairs_sf[ind++] = '0' + c;
digit_pairs_sf[ind++] = '0' + d;
}
}
}
}
}
 
inline void intToStrSuperFast(unsigned int val, char* c)
{
int size;
if(val>=10000)
{
if(val>=10000000)
{
if(val>=1000000000)
size=10;
else if(val>=100000000)
size=9;
else
size=8;
}
else
{
if(val>=1000000)
size=7;
else if(val>=100000)
size=6;
else
size=5;
}
}
else
{
if(val>=100)
{
if(val>=1000)
size=4;
else
size=3;
}
else
{
if(val>=10)
size=2;
else if (val==0) {
c[0]='0';
c[1] = '\0';
return;
}
else
size=1;
}
}
 
c += size-1;
while(val>=10000)
{
int pos = val % 10000;
val /= 10000;
char hh;
 
*(c-3) = digit_pairs_sf[4*pos];
*(c-2) = digit_pairs_sf[4*pos+1];
*(c-1) = digit_pairs_sf[4*pos+2];
*(c) = digit_pairs_sf[4*pos+3];
 
c-=4;
}
while(val>0)
{
*c--='0' + (val % 10);
val /= 10;
}
c[size+1] = '\0';
}
 
 
//13/11/14
//Tested that it works with all ulong inteters (0-4294967295). No errors.
 
inline void intToStr(unsigned int val, char* c)
{
int size;
if(val>=10000)
{
if(val>=10000000)
{
if(val>=1000000000)
size=10;
else if(val>=100000000)
size=9;
else
size=8;
}
else
{
if(val>=1000000)
size=7;
else if(val>=100000)
size=6;
else
size=5;
}
}
else
{
if(val>=100)
{
if(val>=1000)
size=4;
else
size=3;
}
else
{
if(val>=10)
size=2;
else if (val==0) {
c[0]='0';
c[1] = '\0';
return;
}
else
size=1;
}
}
 
c += size-1;
while(val>=100)
{
int pos = val % 100;
val /= 100;
 
*(c-1) = digit_pairs[2*pos];
*c = digit_pairs[2*pos+1];
 
c-=2;
}
while(val>0)
{
*c--='0' + (val % 10);
val /= 10;
}
c[size+1] = '\0';
}
 
 
void benchmarkSF() {
init_digit_pairs_sf();
clock_t begin = clock();
 
char str1[16];
char cU;
unsigned int errorCount = 0;
//intToStr((unsigned int)1234567, str2);
unsigned int i;
int count=0;
for(i = 0; i < 4294966000; i += 20) {
 
// HERE COMMENT OUT THE FUNCTION YOU WANT TO TEST:
intToStrSuperFast(i, str1);
//intToStr(i, str1);
//snprintf (str1, 15, "%u",i); // sizeof(str)
//sprintf(str1,"%d",i);
// itoa (i,str1,10); if using this, change uint to int and for
loop to end to 4294966000/2
 
cU += str1[6]; // use string so that compiler will not optimize
things out
 
++count;
}
 
clock_t end = clock();
double elapsed_secs = double(end - begin) / CLOCKS_PER_SEC;
 
std::cout<<"Time: "<<elapsed_secs<<", integers count: "<<count<<",
"<<cU<<std::endl;
std::cout<<"errors: "<<errorCount;
}
 
/*
Test:
- for(i = 0; i < 4294966000; i += 20)
- n. 215 million ints
- Average of 4 tests:
intToStrSuperFast : 3.415 s
intToStr : 4.687 s (+37%)
snprintf : 588 s (+17118%)
_snprintf (VC2008) : 112 s (+3179%)
_snprintf (VC2010) : 140 s (+3999%)
_itoa (VC2008) : 36.9 s (+980%)
 
*/
JiiPee <no@notvalid.com>: Nov 14 03:45AM

On 14/11/2014 01:02, Öö Tiib wrote:
> optimal middle ground between too lot of transistors and too few L1
> cache. Your tests (if they only work with algorithms that use fully the
> 64k L1 and 40k is almost full) will lie to you!
 
Ok, can you make/show a simple program where this would happen? A
program where using my conversion functions things get slow. I would
like to test it on my computer.
 
(I have attached the full code to test my new version which uses 40000
look up table in the main message above.)
Ian Collins <ian-news@hotmail.com>: Nov 14 05:50PM +1300

JiiPee wrote:
> _snprintf (VC2008) : 112 s (+3179%)
> _snprintf (VC2010) : 140 s (+3999%)
> _itoa (VC2008) : 36.9 s (+980%)
 
On my Solaris system with the native compiler:
 
intToStrSuperFast 2.4s
intToStr 3.3s
lltostr 4.9s
snprintf 12.8s
 
--
Ian Collins
JiiPee <no@notvalid.com>: Nov 14 06:26AM

On 14/11/2014 04:50, Ian Collins wrote:
> intToStr 3.3s
> lltostr 4.9s
> snprintf 12.8s
 
ok interesting. So there is the same 37% difference, but snprintf is
much faster than mine. lltostr is not in C++ standard, so it does not
really count. I guess you would get portability problems with lltostr?
 
Maybe its my old computer which is doing this. I ll have to test using
another computer.
JiiPee <no@notvalid.com>: Nov 14 06:28AM

On 14/11/2014 06:26, JiiPee wrote:
> really count. I guess you would get portability problems with lltostr?
 
> Maybe its my old computer which is doing this. I ll have to test using
> another computer.
 
Clearly its not a GCC issue because VC gives me similar results.
Ian Collins <ian-news@hotmail.com>: Nov 14 08:24PM +1300

JiiPee wrote:
 
> ok interesting. So there is the same 37% difference, but snprintf is
> much faster than mine. lltostr is not in C++ standard, so it does not
> really count. I guess you would get portability problems with lltostr?
 
You can see the source here:
 
https://github.com/joyent/illumos-joyent/blob/master/usr/src/lib/libc/port/gen/lltostr.c
 
--
Ian Collins
Luca Risolia <luca.risolia@linux-projects.org>: Nov 14 09:00AM +0100

Il 14/11/2014 04:30, JiiPee ha scritto:
> creating a normal program.
 
> Can somebody test the code below so we see if you get similar results as
> I got?
 
I get similar results. But on my machine the implementation of your
super unuseful function that I provided in a previous post is still ~4x
faster. In facts, if you think better, a great part of calculations can
be done at compile time, there is no need to read from an array in
memory. Furthermore, that version will also convert unsigned integers of
any size, while your function does not (the upper limit is 10^11
apparently).
Alain Ketterlin <alain@dpt-info.u-strasbg.fr>: Nov 14 09:21AM +0100

JiiPee <no@notvalid.com> writes:
 
[...]
> version by using 40000 look-up table converting four integers: like
> 4691 -> '4' '6' '9' '1' . I just implemented it, and it makes it even
> faster! I call it intToStrSuperFast.
 
Make it an array of 4 billion entries of length 10, and you get a
constant time int-to-string conversion! OK, I'm kidding.
 
> _snprintf (VC2008) : 112 s (+3179%)
> _snprintf (VC2010) : 140 s (+3999%)
> _itoa (VC2008) : 36.9 s (+980%)
 
There is something really wrong with your snprintf.
 
Anyway, comparing with snprintf to compare conversion time doesn't mean
much:
 
- your function is a specialized, inline routine, that get optimized at
compile time inside a loop (i.e., it may be unrolled, etc.), and since
you're building an executable and your function is declared inline,
even if it is not actually inlined the compiler is not required to
respect the ABI (this may lead to dramatic improvement on
register-starved archs like x86, especially for functions with 2
parameters).
 
- snprintf is a general, variable-argument, library routine, and the
compiler doesn't even see it. It has probably been compiled
conservatively, to work on any processor sold in the last 10 years or
so.
 
My guess is that you are measuring the overhead of the call, much more
than the conversion time itself. If you want something more useful, make
your function parameters var-arg, use a va_list to pop data, compile
this into a shared-library (with no arch-specific optimization), rewrite
your main to use this, link against the shared-lib.
 
Then, measure and compare. You'll still win (because there is no format
sting to parse, etc), but I would be surprised if the difference were
significant.
 
-- Alain.
JiiPee <no@notvalid.com>: Nov 14 12:20PM

On 14/11/2014 08:00, Luca Risolia wrote:
> from an array in memory. Furthermore, that version will also convert
> unsigned integers of any size, while your function does not (the upper
> limit is 10^11 apparently).
 
But C++ standard says that maximum uint is 4294967295, so its doing the
job its meant to do. I did not even require to convert bigger than that
as this is only a replacement of std::snprintf which I guess is also
limited like that.
 
So the task was to convert integers less than 4294967295 as fast as
possible....
Using integers greater than that would give proglems anyway as uint
could not take them (at least not on every machine, so portability
problems).
 
But if somebody wants bigger than 4294967295 then we could modify easily
intToStr to do that.
JiiPee <no@notvalid.com>: Nov 14 12:26PM

On 14/11/2014 08:21, Alain Ketterlin wrote:
> sting to parse, etc), but I would be surprised if the difference were
> significant.
 
> -- Alain.
 
Ok, but the task /challenge was always to create as fast int to string
function regardless of other issues, but not using too much memory
obviously so its usefull in real life. And my functions they already
meet that criteria. So I do not see any need to try to make them as C++
library functions. But that can be the explanation yes.
JiiPee <no@notvalid.com>: Nov 14 12:30PM

On 14/11/2014 08:00, Luca Risolia wrote:
> from an array in memory. Furthermore, that version will also convert
> unsigned integers of any size, while your function does not (the upper
> limit is 10^11 apparently).
 
oh I missed your function... now found it. I have to try that as well
and compare. I ll try to do it later. Obviously if it does not use any
memery and is faster than mine then its much better. But let me
check/test that.
Luca Risolia <luca.risolia@linux-projects.org>: Nov 14 02:40PM +0100

Il 14/11/2014 13:20, JiiPee ha scritto:
> But C++ standard says that maximum uint is 4294967295, so its doing the
> job its meant to do.
 
There is not such limit in the standard for an unsigned integer
(assuming that you mean unsigned integer by "uint"). The maximum value
depends on a number of things and is provided by a given C++
implementation via std::numeric:limits<unsigned integer>::max().
 
> I did not even require to convert bigger than that
> as this is only a replacement of std::snprintf which I guess is also
> limited like that.
 
I don't think that limit exists for std::snprintf.
 
> Using integers greater than that would give proglems anyway as uint
> could not take them (at least not on every machine, so portability
> problems).
 
This does not make any sense..
 
> But if somebody wants bigger than 4294967295 then we could modify easily
> intToStr to do that.
 
I don't buy it :) Honestly, this function is going to be useful to you only.
JiiPee <no@notvalid.com>: Nov 14 07:25PM

On 14/11/2014 13:40, Luca Risolia wrote:
> (assuming that you mean unsigned integer by "uint"). The maximum value
> depends on a number of things and is provided by a given C++
> implementation via std::numeric:limits<unsigned integer>::max().
 
ULONG_MAX is 4294967295 or greater. So it can be 4294967295 ....
 
>> as this is only a replacement of std::snprintf which I guess is also
>> limited like that.
 
> I don't think that limit exists for std::snprintf.
 
But the biggest snprintf can take is uint (or long uint). So that means
in my computer at least 4294967295. Or can you show me a code which
would convert bigger than 4294967295 on my computer to a string? I think
the compiler will complain if I put bigger than that....
 
>> could not take them (at least not on every machine, so portability
>> problems).
 
> This does not make any sense..
 
intToStr(myInt);
...
foo(myInt);
 
foo() can be maximum:
void foo(unsigned int),
so the parameter cannot be more than max_uint.
 
Most of the functions in normal programs are uint, and thus cannot
operate with values bigger than that. So using bigger ints than that is
nor very useful as most functions cannot use them...
 
>> intToStr to do that.
 
> I don't buy it :) Honestly, this function is going to be useful to you
> only.
 
We could indeed modify it :). That remains a fact :).
scott@slp53.sl.home (Scott Lurndal): Nov 14 07:33PM

>> depends on a number of things and is provided by a given C++
>> implementation via std::numeric:limits<unsigned integer>::max().
 
>ULONG_MAX is 4294967295 or greater. So it can be 4294967295 ....
 
Not on my system. ULONG_MAX here is:
 
$ printf "%u\n" $(( 0xffffffffffffffff ))
18446744073709551615
 
 
>>> limited like that.
 
>> I don't think that limit exists for std::snprintf.
 
>But the biggest snprintf can take is uint (or long uint). So that means
 
Most modern systems are 64-bit, and unsigned long is 64-bit. snprintf will
even take an unsigned long long, which is a 64-bit value on 32-bit CPU's
and the gnu compilers offer 128-bit scalar types (__int128_t, __uint128_t).
David Brown <david.brown@hesbynett.no>: Nov 14 08:02AM +0100

On 13/11/14 23:34, Mr Flibble wrote:
>> have so little optimisation that the compiler generates worse code for
>> "++tnX" than "tnX + 1".
 
> Give it up; this guy is obviously a troll.
 
My post was in answer to JiiPee, not to Rick.
 
And I don't think Rick is a troll. A troll deliberately posts to annoy,
confuse or irritate people - I don't believe that applies to Rick. He
truly believes that his ideas about programming languages are important
and useful, even though everyone else sees them as confusing, pointless,
or dangerous. And he truly believes that his posts about religion are
helpful and that he is trying to "save" us - despite their annoyance,
irritation, and having the complete opposite effect of what he intends.
 
So no, he is not a troll. I think he is in a class of his own. He
makes it extremely tempting to play the amateur psychiatrist, but I
don't think that would be helpful. But I know that if ever I started to
act like he does, my family loves me enough to get me to professional help.
Nobody <nobody@nowhere.invalid>: Nov 14 01:44PM

On Wed, 12 Nov 2014 03:23:28 -0800, Rick C. Hodgin wrote:
 
> code is identical to tnX++;, but its meaning is something else which
> is incomplete and invalid because the dereference is lost-but-
> provided-for in source code.
 
There are a lot of cases where expressions have both a value and
side-effects. Sometimes you want the value, sometimes you want the
side-effects, sometimes you want both.
 
It's senseless to single out that particular case just because
 
a) only the side-effects are being used, not the value,
b) there is a "simpler" expression which has the same side-effects, and
c) you once made a coding mistake due to getting the precedence wrong and
this must somehow be the fault of the language.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 14 06:49AM -0800

On Friday, November 14, 2014 8:44:00 AM UTC-5, Nobody wrote:
> There are a lot of cases where expressions have both a value and
> side-effects. Sometimes you want the value, sometimes you want the
> side-effects, sometimes you want both.
 
What are some other ones?
 
> It's senseless to single out that particular case just because
 
> a) only the side-effects are being used, not the value,
> b) there is a "simpler" expression which has the same side-effects, and
 
The simpler expression doesn't have any side effects. It is a proper
expression which is complete and accomplishes everything its expression
form indicates.
 
> c) you once made a coding mistake due to getting the precedence wrong and
> this must somehow be the fault of the language.
 
There's no place to respond to statements like these. Anything I would
say could seem like an excuse.
 
I coded the *tnX++; form because it looked nicer in source code than the
++*tnX; form. I thought they did the same thing, but they did not and
that was my error. However, in coming to the understanding of what it's
doing (by looking at the disassembly), and then considering what that
actually means in terms of the "*tnX++;" expression, and what it actually
accomplishes in stand-alone non-volatile form... that's where I began to
realize it was a silly expression with no real ability to do any kind of
real work. It's kind of like "x = x = 5;" ... there's nothing wrong with
that expression. It won't cause problems or generate incorrect data...
but it's still incorrect.
 
I'm curious what your (or other people's) response is to "There are a
lot of cases..." above.
 
Best regards,
Rick C. Hodgin
Robert Hutchings <rm.hutchings@gmail.com>: Nov 14 08:16AM -0600

http://shop.oreilly.com/product/0636920033707.do
 
You can also use PayPal to buy. Paperback will be out in December.
bleachbot <bleachbot@httrack.com>: Nov 14 03:05PM +0100

BV BV <bv8bv8bv8@gmail.com>: Nov 14 06:05AM -0800

Islam prohibited women to be Unveiled....why?

Are there any harmful effects on women if they used to display parts of their body? Let us read.........
 
According to the latest figures, the incidence of melanoma, a potentially fatal skin cancer, is increasing dramatically. It is currently the most common type of cancer in young women between the ages of 25 and 29.
Researchers believe that sun exposure plays a significant role in the development of melanoma. According to Dr. Diane Berson, an American dermatologist says "intense sun exposure prior to age 20 may be more of a significant risk factor for skin cancer than sun exposure past the age of 20. Three or more blistering sunburns early in life, or three or more years of working out of doors, (e.g. camp counselors or lifeguards), without protection, can increase the risk of skin cancer by more than three times."
Another study held from 1973 to 2004 found that the rate of new melanoma cases in younger women had jumped 50 percent since 1980, but did not increase for younger men in that period.
"It's worrying," said Mark Purdue, a research fellow at the National Cancer Institute, who led the analysis published in the Journal of Investigative Dermatology. "What we are seeing in young adults right now could foretell a much larger number of melanoma cases in older women." he said.
"One possible explanation is increases among young women of recreational sun exposure or tanning bed use," Purdue said. "Both of these things have been identified as risk factors."
Statistics say that 62,000 melanoma cases are diagnosed each year in the United States, and more than 8,400 people die from the disease, according to the American Cancer Society. Previous studies have shown that the rate of new diagnoses has been increasing among adults overall.
Woman's dress in Islam
According to religion of Islam woman should only display her face and palms of hands in front of foreigner men (indoor and outdoor) and more than that is prohibited.
Allah Almighty tells prophet Mohamed peace be upon him to order women to do the following: (And tell the believing women to lower their gaze (from looking at forbidden things), and protect their private parts (from illegal sexual acts) and not to show off their adornment except only that which is apparent (like both eyes for necessity to see the way, or outer palms of hands or one eye or dress like veil, gloves, head-cover, apron, etc.), and to draw their veils all over Juyûbihinna (i.e. their bodies, faces, necks and bosoms) and not to reveal their adornment except to their husbands, or their fathers, or their husband's fathers, or their sons, or their husband's sons, or their brothers or their brother's sons, or their sister's sons, or their (Muslim) women (i.e. their sisters in Islâm), or the (female) slaves whom their right hands possess, or old male servants who lack vigour, or small children who have no sense of feminine sex. And let them not stamp their feet so as to reveal what they hide of their adornment. And all of you beg Allâh to forgive you all, O believers, that you may be successful.){ Sûrat An-Nûr - The Light -verse31}.
Also prophet Mohamed peace be upon him says in the right Hadith about some indications for the imminence of day of resurrection that "there will be women who are dressed and naked at the same time, who are reeling while walking and their heads are like the top of the camel, those will not enter the heaven or even smell its smell" [narrated by Abu- horraira]
Muslim women who are veiled believe that their body is valuable so it should not be as a commodity that is exposed to everyone to evaluate.
Conclusion
The great religion of Islam doesn't approve any practice that may cause any harm to both men and women , therefore Allah Almighty and His prophet Mohamed peace be upon him order women to be veiled because woman's veil definitely respects woman than exposing her parts in front of everyone.
Also, Allah Almighty didn't order women to be veiled and ordered men to do what they want but He Almighty orders men also to respect women by not to look in their parts because that is purer for them so that Allah Almighty tells the prophet to inform men to:(Tell the believing men to lower their gaze (from looking at forbidden things), and protect their private parts (from illegal sexual acts, etc.). That is purer for them. Verily, Allah is All-Aware of what they do.){ Sûrat An-Nûr - The Light -verse30}.

------------------------------
By: Abduldaem Al-Kaheel
www.kaheel7.com/eng
http://www.kaheel7.com/eng/index.php/legislative-miracles/646-islam-prohibited-women-to-be-unveiledwhy
References:

* http://www.webmd.com/skin-beauty/guide/sun-exposure-skin-cancer
* http://www.boston.com/news/nation/washington/articles/2008/07/11/skin_cancer_on_rise_in_young_women/
* http://www.medicalnewstoday.com/articles/44764.php

Thank you
Barry Schwarz <schwarzb@dqel.com>: Nov 13 09:49PM -0800

On Thu, 13 Nov 2014 11:10:45 -0800 (PST), "K' Dash"
<adnanrashidpk@gmail.com> wrote:
 
Please set you newsreader line length to something less than 80
 
>bellow are the MAC address of my devices. I have a vector list std::vector<Maclist> m_listentry; in header file.
 
You should never define an object in a header. What is the type
Maclist?
 
>I want to create a function in which I want to push.back all the MAC addresses. My function is also here which is not finalize. please tell me how can I do this? if any one complete my function then I will be greatfull to him/her.
 
>void
>GUID_LMS_application::CreateLMSCache(Mac48Address mac, Ipv4Address ip)
 
What are the types Mac48Address and Ipv4Address?
 
 
>"00:00:00:00:00:01"
>"00:00:00:00:00:02"
>"00:00:00:00:00:03"
 
We really didn't need two hundred lines of examples.
 
--
Remove del for email
"K' Dash" <adnanrashidpk@gmail.com>: Nov 14 05:40AM -0800

You should never define an object in a header. What is the type
Maclist?
 
Answer:
1. I declare the object in .h file and want to put MAC values in .cc file
2. class Maclist: public Object
 
What are the types Mac48Address and Ipv4Address?
Answer:
both are classes, you can find further information about these classes from below link.
http://www.nsnam.org/docs/release/3.21/doxygen/classns3_1_1_mac48_address.html
 
http://www.nsnam.org/docs/release/3.21/doxygen/classns3_1_1_ipv4_address.html
"Erdoeban Zsukloff zu Brecher Zhuang" <no@contact.com>: Nov 10 06:06PM -0500

"嘱 Tiib" wrote in message
news:cacc6334-d051-46a0-aba7-600f2ca3b7f0@googlegroups.com...
 
On Friday, 7 November 2014 04:51:24 UTC+2, Erdoeban Zsukloff zu Brecher
Zhuang wrote:
> 80% of the time ...) , the fastest and arguably easiest way would be to
> test
> for a pre-set (hardcoded ?) string ...
 
Does code written in GPU assembler contain major amount of constants
0x80000000? What you think?
 
Talking about the data, not the code. Why on earth would you infer code ? Or
is he _writing_ a GPU assembler - not something I understood from OP ...
 
 
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
 
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
"Öö Tiib" <ootiib@hot.ee>: Nov 13 05:02PM -0800

On Thursday, 13 November 2014 20:21:13 UTC+2, JiiPee wrote:
> its a static array. and for me 40000 is not much memory waste, as I do
> normal pc program mostly. its like 0.001 % of the RAM memory if having 3
> GIG memory.
 
Memory costs nothing. Gigabyte here or there. It is full L1 cache that
costs something and L1 is 64k. Platform architects say that 64k is
optimal middle ground between too lot of transistors and too few L1
cache. Your tests (if they only work with algorithms that use fully the
64k L1 and 40k is almost full) will lie to you! In real application no
algorithm can use all L1 as its private storage of nonsense sub-strings.
seeplus <gizmomaker@bigpond.com>: Nov 13 04:16PM -0800

On Thursday, November 13, 2014 10:40:53 PM UTC+11, JiiPee wrote:
> On 13/11/2014 09:33, JiiPee wrote:
> Seems like Mayers "Effective Modern C++" coming this month might be
> good. He seems to go to details a lot.
 
As you mention, the very latest is:
 
Effective Modern C++ - Scott Meyers
 
Being printed right now. Digital is available and hard copy available ~ 5th Dec.
You can/could DL a lot of excerpts from his blog site, and he also does about
an hours discussion on C11 and C14 stuff and the book here, certainly enough to keep you going :)
 
http://vimeo.com/97318797
 
That site is a bit intermittent at present tho.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)