Thursday, October 20, 2016

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

rout.jyoti@gmail.com: Oct 20 11:35AM -0700

I am working on a project to form a clustering algorithm. Actually I have created a struct which I have to copy to constant char* so that to pass it as a string. I am trying like this below to setWsmData as a cstring in the below function "sendMessage" and to receive the sent value in getWsmData in the function "onData" :
 
File:- pedcluster.h
====================
class PedCluster:: public BaseWaveApplayer {
...
protected:
void sendMessage(std::string blockedRoadId) ;
 
struct cluster{
int clustNum;
std::string messageName;
....
};
}
 
File:- pedcluster.cc
====================
void PedCluster::sendMessage(std::string blockedRoadId) {
sentMessage = true;
 
t_channel channel = dataOnSch ? type_SCH : type_CCH;
 
cluster *form = new cluster{2, "invite"};
 
const char* hello;
memcpy(hello, form, sizeof(form));
blockedRoadId = std::string (hello);
 
WaveShortMessage* wsm = prepareWSM("data", dataLengthBits, channel, dataPriority, -1, 2);
 
wsm->setWsmData(blockedRoadId.c_str()); // Output gives garbage value
 
sendWSM(wsm);
}
 
void PedCluster::onData(WaveShortMessage* wsm) {
 
if (!sentMessage) sendMessage(wsm->getWsmData());
 
const char* hello = {wsm->getWsmData()};
 
const cluster *form = reinterpret_cast <const cluster*>(hello);
 
}
 
File:- WaveShortMessage.cc
===========================
const char * WaveShortMessage::getWsmData() const
{
return wsmData_var.c_str();
}
 
void WaveShortMessage::setWsmData(const char * wsmData)
{
this->wsmData_var = wsmData;
}
 
I think there is a mistake in these lines below, which I have written above:
 
const char* hello;
memcpy(hello, form, sizeof(form));
blockedRoadId = std::string (hello);
 
Could you please help me to solve this,so that pass the data of the struct in setWsmData.
 
Thanks
"Öö Tiib" <ootiib@hot.ee>: Oct 20 12:26PM -0700

> pass it as a string. I am trying like this below to setWsmData as a
> cstring in the below function "sendMessage" and to receive the sent value
> in getWsmData in the function "onData" :
 
Huh? Passing contents of structs around as strings is something that
is needed for nothing I can imagine in "clustering algorithm".
 
 
> const char* hello;
> memcpy(hello, form, sizeof(form));
> blockedRoadId = std::string (hello);
 
You are correct. That slice of code is worse than a bad joke, sorry.
 
 
> Could you please help me to solve this,so that pass the data of the struct in setWsmData.
 
You seemingly underestimate complexity of task of passing data around
as texts.
 
You likely should first read FAQ on serialization.
https://isocpp.org/wiki/faq/serialization
 
Then most simple for you is perhaps to learn to use stream I/O and
'std::stringstream' class.
 
However most beneficial for you is perhaps to learn to use some library
that serializes/deserializes into JSON. http://www.json.org/ contains
links to some such C++ libraries.
 
Pick your poison!
Shivu <rout.jyoti@gmail.com>: Oct 20 12:44PM -0700

On Thursday, October 20, 2016 at 9:27:10 PM UTC+2, Öö Tiib wrote:
> that serializes/deserializes into JSON. http://www.json.org/ contains
> links to some such C++ libraries.
 
> Pick your poison!
 
Thanks Tiib for your suggestions.
I am very new to c++.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 20 06:38PM +0200

On 20.10.16 00.30, Daniel wrote:
> Would you use it? Or would you more likely use std::map with a sequence
> mapped_type?
 
It depends on how many values you intend to store per key. Creating a
container for every map element could be rather expensive if duplicate
keys are rare.
On the other side, if most keys have many values sequence scans for one
key could be more effective with distinct maps.
In doubt multimap is in most cases a better choice than a nested container.
 
The reason why I almost never use std::multimap neither std::map is that
they are implemented as Red Black Tree which is quite ineffective for
small key-value pairs due to the excessive allocation overhead. B-Trees
are by far more efficient in most use cases.
Unfortunately there is no B-Tree container in the C++ standard. So I end
up with my own implementation in almost any project sooner or later.
 
 
Marcel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 20 06:39PM +0100

On 20/10/2016 17:38, Marcel Mueller wrote:
> are by far more efficient in most use cases.
> Unfortunately there is no B-Tree container in the C++ standard. So I end
> up with my own implementation in almost any project sooner or later.
 
The performance of map and multimap can often be improved significantly
by using a pool allocator such as the one Boost provides. You should
try using that rather than eschewing such standard workhorse containers.
 
/Leigh
Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 20 09:43PM +0200

On 20.10.16 19.39, Mr Flibble wrote:
 
> The performance of map and multimap can often be improved significantly
> by using a pool allocator such as the one Boost provides. You should
> try using that rather than eschewing such standard workhorse containers.
 
You just mentioned that the standard allocator is often also not that
efficient when dealing with many objects. Even if the algorithms and
containers used for data processing and storage are suitable the overall
application performance may scale unexpectedly bad when the number of
allocated objects is large. So using a more efficient allocator for
std::(multi)map is just a work around for a not well chosen container
type and does not really solve the problem at all. Furthermore nested
allocators may significantly increase memory fragmentation in case the
container is held for a longer time with less than its maximum size.
 
The fact that there is no B-Tree in the standard makes no difference. RB
trees are only a good choice if invalidation of iterators on container
changes are undesirable. In most other cases they are outperformed by a
B-Tree by far. Think also of cache efficiency when small objects are
distributed over the entire memory.
 
 
Marcel
scott@slp53.sl.home (Scott Lurndal): Oct 20 01:06PM


>> http://www.anandtech.com/show/8423/intel-xeon-e5-version-3-up-to-18-haswell-ep-cores-/4
 
>However you do it, you still have both address and data buses. They are
>required to get data to and from memory, and do have limitations.
 
You really don't understand modern processors. They don't have "address
and data busses". They're much closer to token-ring networks where
data is transferred as packets (very similar to TLPs on PCI-Express).
 
 
>And sure, they handle the I/O capabilities built into the processor -
>but we're not dealing with just the processor here.
 
Are you familiar with the concept of SoC? Intel processors have
40+ lanes of Gen3 PCI Express _ON THE PROCESSOR_. For ThunderX,
there are 16 SATA controllers, 6 PCI Express controllers, two 40Gb
network controllers and a bunch of other devices (I2C, eMMC, Secure
Digital, GPIO, UARTs, et. al.) _ALL ON THE PROCESSOR_.
Christian Gollwitzer <auriocus@gmx.de>: Oct 20 03:26PM +0200

Am 19.10.16 um 22:56 schrieb Jerry Stuckle:
>> port multiplier, the behaviour remains the same.
 
> Right. Keep dreaming. And you claim to know something about hardware?
> With that statement you just proved your ignorance.
 
It's really hilarious how much you fight to learn something new. Why not
try it? It can be fun. Are you feeling old? Is it Dunning-Kruger?
 
Christian
cross@spitfire.i.gajendra.net (Dan Cross): Oct 20 02:52PM

In article <nuagli$cb6$1@dont-email.me>,
>> With that statement you just proved your ignorance.
 
>It's really hilarious how much you fight to learn something new. Why not
>try it? It can be fun. Are you feeling old? Is it Dunning-Kruger?
 
My money is on an absolutely spectacular case of Dunning-Kruger.
 
While watching Jerry Stuckle struggle to boil everything down to
an overly simplistic view of the world so he can justify his
misunderstanding of how computing has evolved over the last four
decades (e.g., irrelevant meanderings on individual RAM devices and
buses without taking into consideration the much bigger picture of
the machine as a whole) can be momentarily amusing, I feel kind of
bad because the inevitable pile-up on him just feels like punching
down.
 
There's an argument about setting the record straight for future
archive spelunkers, but I think at this point the record is
sufficiently clear that continuing down this road is well past the
point of diminishing returns. I killfile'd him a long time ago, but
see the responses. My humble suggestion is that if others similarly
plonked him, there'd be fewer responses to see.
 
- Dan C.
Jerry Stuckle <jstucklex@attglobal.net>: Oct 20 11:22AM -0400

On 10/20/2016 9:06 AM, Scott Lurndal wrote:
 
> You really don't understand modern processors. They don't have "address
> and data busses". They're much closer to token-ring networks where
> data is transferred as packets (very similar to TLPs on PCI-Express).
 
Oh, I understand them all right. Let me see if I can make is very
simple for you.
 
Every memory chip has address and data pins. Someone sets up a
combination of values on the address pins, selecting locations in the
chip, the number of locations being dependent on the number of data pins
that chip has. This is called an *address*.
 
Depending on the value of the r/w pin, the chip either sets voltages on
the data pins based on the stored values in the chip (read) or takes
voltages off of the data pins and changes the stored data (write).
 
The lines connected to the data and address pins are called the *data
bus* and *address bus*, respectively. There can be only one address
active at any one time, and it can be for read or write, not both.
There is *no way* around this restriction, as each line on a bus can
only hold one value at any instant
 
Now, depending on the chips and the needs of the system, multiple chips
can be accessed at the same time. For instance, if the system is
designed for a 64 bit wide data bus but uses 8 bit wide chips, all of
the address lines will be connected to all 8 chips in parallel. The 8
data lines from each chip will be brought out to 8 separate data lines,
providing a bus that is 64 bits wide.
 
A specific example: 2GB can be built out of 8 256M X 8 chips. There
will be 28 address lines feeding all 8 chips in parallel. There will be
8 data lines from each chip, each coming out separately, creating a 64
bit data bus. The total is 2GB. And no matter what you claim, only 64
bits can be accessed at one time, and for a specific address line
combination, it will always be the same 64 bits. The laws of physics
don't allow anything else.
 
Now some systems may allow different modules to be accessed
concurrently. For instance, the processor may be accessing memory on
one module while an I/O device is doing direct memory transfer to/from
another device. This requires additional circuitry to switch the
modules to different resources (but still only allows access to a single
address on a module). However, this causes additional problems.
 
The most obvious one is when two resources (processor and NIC, disk and
NIC, etc.) require access to the same module, you have a contention
situation and one must wait. A more subtle but more serious problem is
the added circuitry adds both propagation delay and switching times to
the signals. While not much, it slows bus access. And at current bus
speeds, even a nanosecond delay is significant.
 
Also, you obviously don't understand how a token ring network works. I
was involved with them early on, working for IBM when they were
developed. While I was in software at the time, since I was ex-hardware
at IBM, when we had problems on our token ring network, I was one of the
first the managers asked for help diagnosing the problem so they could
give good details on a service call.
 
And token ring works nothing like any memory access. If it did, the
data would be retrieved from memory, bits added to make a packet and
placed on a bus to be passed to the first unit (processor, I/O device,
etc.). That unit would take it off the data bus and examine it. If the
unit didn't want the data, it would place it back on another bus and
send to the second unit, and so on. The last unit would pass it back to
the first (memory, in this case), creating the "ring". If it gets back
to the first unit, the unit would know no one could handle it (in token
rings, this would be equivalent to an ethernet "address not found" error).
 
When nothing would be happening on a bus, a "token" would be passed
around the ring. Any unit could access the bus, but only upon receipt
of this token. Everyone else would have to wait.
 
Such a system would be so inefficient that no engineer in his right mind
would create such a rube goldberg design (and people wonder why token
ring failed - it seems like a good idea at the time).
 
> there are 16 SATA controllers, 6 PCI Express controllers, two 40Gb
> network controllers and a bunch of other devices (I2C, eMMC, Secure
> Digital, GPIO, UARTs, et. al.) _ALL ON THE PROCESSOR_.
 
Sure, I'm familiar with SoCs - I use them all the time. However, the
overall design - including buses - is the same as I indicated above.
The only difference is they are all on one chip instead of multiple
chips on one or more boards. And it still has the same restrictions.
 
But you have once again shown you have no clue.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Oct 20 11:52AM -0400

On 10/20/2016 4:30 AM, David Brown wrote:
 
>> And you need to be pedantic about it.
 
> So to be clear on this, you understand that we are talking about
> gigabits here, not gigabytes?
 
For the pedantic arsehole, yes.
 
>> You still aren't going to get
>> 40Gb throughput from a 40Gb port without violating the laws of physics.
 
> I'd love to know which laws of physics you are talking about here.
 
Well, let's see. We can start with the fact you can only have one
voltage on a wire at any specific time. This is the most significant,
because unless you have only one thing active in the entire system at a
time, at some point you are going to have contention for data, slowing
things down.
 
Then we can discuss propagation delay time, which at 40Gb/s becomes very
significant and is dependent on the speed of light through the material.
40 Ghz equated to 0.025 nanoseconds per cycle. Now 40Gb copper doesn't
actually run at 40Gb - it has 4 parallel paths running at just over
10.3128Gh each per the 40GBASE-CR4 standard. This equates to about
0.097ns per cycle. In copper, this is a wavelength of just over one
inch - which means on a 100' cable, about 4800 bits would be transmitted
before the first one was received at the destination. This slows the
ability of the receiving system to respond to the transmitting system.
Then you also have to include any routers, switches, converters, etc. in
the path, which cause additional propagation delays.
 
We can also add switching time, which is dependent on everything from
the material being used in the semiconductors to voltage being used and
stray capacitance in and around the circuit. They add delays to the
signal, which are more significant as you go higher in speed.
 
I could continue, but we'll start with these. When you can figure out
how to violate the laws of physics, you will win a Nobel Prize.
 
 
> Yes, I understand about the physics involved well enough for the
> purpose. And I understand TCP/IP and its framing overhead, and I
> understand Ethernet with its framing overhead, inter-frame gaps, etc.
 
You obviously do NOT understand about the physics involved well enough.
There is much more than just TCP/IP's framing overhead, etc.
 
And BTW - ethernet is a physical layer protocol. TCP/IP is only one of
the link layer protocols which can be used. But even other protocols
cannot not maintain 40Gb data transfer rates.
 
 
> But if you think I am wrong, then please explain where the other 25% of
> the bandwidth goes. I am happy to admit to being wrong, and learn
> something new, if I am given a good explanation of it.
 
Some of it above. But the main limit is in the computer itself. Unless
you continue to just load the buffer of the NIC and keep sending that
data, you will at some point have contention for data in the computer
itself. Once again, the laws of physics don't allow two resources to
access the same memory chip/SATA device/whatever at the same time. One
must wait.
 
 
>> Those affect throughput, obviously. But that's not all. And your 94%
>> and 99% are once again theoretical limits - not real life ones.
 
> Again, please explain what you think is missing here.
 
I have.
 
>>> data at those speeds.
 
>> Do you like to your potential customers like this, also?
 
> I can't even figure out what you are trying to say.
 
Yes, you have already proved you don't understand the technical aspects.
 
> or what he needs, beyond a simple business argument "if it were
> cost-effective for him to have such a server, his company would have
> bought one". Everything else you write is just pulled out of the air.
 
Yea right. ROFLMAO!
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Oct 20 12:01PM -0400

On 10/20/2016 4:18 AM, David Brown wrote:
> making new types of RAID systems as well as there being a fair number of
> proprietary systems on the market already. The principles are all much
> the same, however.
 
You have just shown you don't have a clue about how it works. And no,
the principles are *not* "all much the same". There are wide variations
in how they work, depending on the requirements.
 
So much for your claim about knowing how RAID works.
 
> bus. There are buffers, latencies, and multiplexing along the way, but
> the throughput for large transfers is the sum of the throughputs of the
> individual disks.
 
Yes, the laws of physics are much older than I am - as old as the
universe, in fact. And they prevent two resources from accessing the
same memory at the same time. One must wait.
 
Also, it still takes time to fill the disk cache, and data won't be
available until it is in the cache. Theoretical throughput is the sum
of the throughputs of the individual disks. In reality, it is somewhat
less than that, just like throughput on a single disk in reality is
somewhat less than what is published. Total throughput of a RAID array
is based on the response of the slowest disk in the array. The
"slowest" disk is based on the individual request, and can change with
each request.
 
>> accessed as fast as memory can.
 
> I'd ask for references or quotations to justify that, but we all know
> how that will go.
 
You don't remember what you claimed? No surprise there.
 
> Yes, SSD drives can be fast - especially if they are connected by PCIe
> rather than SATA/SAS. No, they are not nearly as fast as DRAM memory.
 
Ah, now the truth.
 
>> Now you're trying to bring physical
>> disks back into the discussion to "prove your point".
 
> I was explaining how you were wrong about port multiplexers.
 
And you failed there, also.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Oct 20 12:02PM -0400

On 10/20/2016 9:26 AM, Christian Gollwitzer wrote:
 
> It's really hilarious how much you fight to learn something new. Why not
> try it? It can be fun. Are you feeling old? Is it Dunning-Kruger?
 
> Christian
 
Yes, you should try it, Christian. People just don't understand how the
real world works. A bit of reading in Wikipedia and the they they know
everything.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Oct 20 12:04PM -0400

On 10/20/2016 10:52 AM, Dan Cross wrote:
> the machine as a whole) can be momentarily amusing, I feel kind of
> bad because the inevitable pile-up on him just feels like punching
> down.
 
Yes, I am trying to boil everything down to some level that a few idiots
here can understand. I could easily get into the math of the physics
involved, but since you can't learn that from Wikipedia, the people here
couldn't understand it. So not worth the trouble.
 
> see the responses. My humble suggestion is that if others similarly
> plonked him, there'd be fewer responses to see.
 
> - Dan C.
 
No loss to me.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
scott@slp53.sl.home (Scott Lurndal): Oct 20 04:38PM


>Well, let's see. We can start with the fact you can only have one
>voltage on a wire at any specific time.
 
So use more wires. Duh.
Gareth Owen <gwowen@gmail.com>: Oct 20 06:44PM +0100


>>It's really hilarious how much you fight to learn something new. Why not
>>try it? It can be fun. Are you feeling old? Is it Dunning-Kruger?
 
> My money is on an absolutely spectacular case of Dunning-Kruger.
 
Nah. It's just plain old denial. He's watched younger, brighter people
come along and take his jobs, and bankrupt his company, as he's failed
to keep up with the changes in technology.
 
And he's just extremely bitter to the point he refuses to acknowledge
that they might know something he doesn't, so he's sitting at home
shouting at a cloud, wearing his "Make America Great Again" baseball cap.
Tim Rentsch <txr@alumni.caltech.edu>: Oct 20 08:41AM -0700

>> to know if that is also true in C++.
 
> (((ULONG_MAX >> 15) >> 15) >> 2) != 0
> should eliminate any UB issue.
 
Yes, that is one way. I didn't post a fix because I thought it
would be obvious how to avoid the UB once it had been pointed
out.
 
Now that I look at this more closely, there is another problem,
which is the test isn't quite right: what it tests is if
ULONG_MAX is at least 33 bits, not at least 64 bits. A more
accurate test is
 
#if ULONG_MAX / 4294967295UL > 4294967295UL
/* at least 64 bits */
#else
/* 63 bits or fewer */
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)