- Question on padding and alignment of `struct` and its members (olcott) - 7 Updates
- Microsoft dropped the ball... - 1 Update
- Ridiculously high standards? - 2 Updates
- Saint Paul, Minnesota user group - 3 Updates
| Pankaj Jangid <pankaj.jangid@gmail.com>: Sep 27 03:28PM +0530 On Sat, Sep 26 2020, olcott wrote: > char a; // 1 byte > char d; // 1 byte > } bar[3]; Certainly. But I have one more query in this regard. This clearly saves memory. But is there an effect on speed as well? Ultimately, the compiler aligns it; so I guess there is no effect on speed. |
| David Brown <david.brown@hesbynett.no>: Sep 27 01:29PM +0200 On 27/09/2020 11:58, Pankaj Jangid wrote: > Certainly. But I have one more query in this regard. This clearly saves > memory. But is there an effect on speed as well? Ultimately, the > compiler aligns it; so I guess there is no effect on speed. That will depend on what you are doing with the struct. If you have a single item, the size won't make a difference. If you are copying lots of them, size certainly /does/ matter. If you are passing a "struct _x" in a function, perhaps the 64-bit version will be passed in a register rather than a block of memory on the stack, for significant speed gains. If you have enough of them, the smaller version gets better cache hit ratios and is thus faster. In general, smaller is faster for data. But whether or not it is /significantly/ faster is a different matter. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 27 08:13AM -0700 On Sunday, 27 September 2020 12:58:52 UTC+3, Pankaj Jangid wrote: > Certainly. But I have one more query in this regard. This clearly saves > memory. But is there an effect on speed as well? Ultimately, the > compiler aligns it; so I guess there is no effect on speed. 1/3 size economy will improve also some speed as you can exchange 1.5 times more records at same throughput. But usually the overall effect is way less. |
| olcott <NoOne@NoWhere.com>: Sep 27 11:59AM -0500 On 9/27/2020 4:58 AM, Pankaj Jangid wrote: > Certainly. But I have one more query in this regard. This clearly saves > memory. But is there an effect on speed as well? Ultimately, the > compiler aligns it; so I guess there is no effect on speed. If you want maximum speed you have to waste space and define char as int. I think that the compiler might load "d" as an int and then & out the upper bits. Same idea with "a" plus bit shifting. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Sep 27 12:43PM -0500 On 9/27/2020 11:59 AM, olcott wrote: > If you want maximum speed you have to waste space and define char as > int. I think that the compiler might load "d" as an int and then & out > the upper bits. Same idea with "a" plus bit shifting. I take this back. The memory fetch operation is much slower than internal processor operations. I am not sure of the speed cache fetch compared to internal processor operations. Because of this the minimum space approach may also be the maximum speed approach. -- Copyright 2020 Pete Olcott |
| Vir Campestris <vir.campestris@invalid.invalid>: Sep 27 09:12PM +0100 ... and following on to this a little late: Pankaj, be aware of that >> Yes, you can rely for the same behaviour on almost any platfom. From Christian. He means it. Almost any. Most of the time... An int could be 64 bits, even though it's almost always 32 these days. On some small systems I think it's still 16 the way it used to be. There's also #pragma pack which affects the padding inserted. Andy |
| olcott <NoOne@NoWhere.com>: Sep 27 04:42PM -0500 On 9/27/2020 3:12 PM, Vir Campestris wrote: > On some small systems I think it's still 16 the way it used to be. > There's also #pragma pack which affects the padding inserted. > Andy I just found out that different compilers might handle padding differently. I had some code that parsed COFF object files that depended on known alignment. It turned out in this case that fixed width integers solved the problem. https://en.cppreference.com/w/cpp/types/integer I didn't need any of the structure packing directives like #pragma pack -- Copyright 2020 Pete Olcott |
| Manfred <noname@add.invalid>: Sep 27 05:26PM +0200 On 9/25/2020 9:29 PM, Ben Bacarisse wrote: > Ah, right. I missed that change (and I thought this was a follow on > from the << discussion so I didn't check). My mistake. > FWIW, g++ 9.3.0-17ubuntu1~20.04 produces 0x1111. gcc 10.2.1 still gives 0xBB11 I think it would be wise for the OP to file a bug to gcc. |
| Brian Wood <woodbrian77@gmail.com>: Sep 26 10:13PM -0700 On Wednesday, April 8, 2020 at 11:41:29 AM UTC-5, Alf P. Steinbach wrote: > --- > Three things I noticed reading the "Readme": > * The need to run a component on a *nix system. Huh. There are many free *nix operating systems. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 27 07:57AM -0700 On Sunday, 27 September 2020 08:14:06 UTC+3, Brian Wood wrote: > > Three things I noticed reading the "Readme": > > * The need to run a component on a *nix system. Huh. > There are many free *nix operating systems. Who cares? There are technology companies with billion dollar turnover whose IT does not just let to put such system into their network. Case closed. What about other remarks of Alf? Let me restore: * The need for an account number in invocations. Huh. * No link to example. Just learn from README.md of repository of (perhaps best ATM) competitor: <https://github.com/google/flatbuffers> 1) Two-three lines of what it is so no one can say TL;DR to it. 2) Link to detailed docs (detailed descriptions, videos, examples, tutorials etc. are all there). 3) Answers or links for questions that one does not want to search from docs. * what platforms are supported? * what programming languages are supported? * where is forum? * where is issue tracker? * where is q/a site? * how to contribute? * what is usage license? |
| Brian Wood <woodbrian77@gmail.com>: Sep 26 10:11PM -0700 Shalom Over the years some have tried to make me feel uncomfortable here. I've posted several times about feeling like Rudolph the Red-nosed Reindeer, but the G-d of all comfort has helped me persevere. So I'm posting for an ode review. What do you suggest I change: https://github.com/Ebenezer-group/onwards And I'm looking for some users of my software: https://webEbenezer.net/about.html . Thanks in advance. Brian Ebenezer Enterprises - Enjoying programming again. https://webEbenezer.net |
| Ian Collins <ian-news@hotmail.com>: Sep 27 08:19PM +1300 On 27/09/2020 18:11, Brian Wood wrote: > about feeling like Rudolph the Red-nosed Reindeer, > but the G-d of all comfort has helped me persevere. > So I'm posting for an ode review. Writing poetry now? -- Ian. |
| David Brown <david.brown@hesbynett.no>: Sep 27 10:31AM +0200 On 27/09/2020 07:11, Brian Wood wrote: > uncomfortable here. I've posted several times > about feeling like Rudolph the Red-nosed Reindeer, > but the G-d of all comfort has helped me persevere. People don't want you to feel uncomfortable about making posts about C++ here. But a lot of us /do/ want you do feel uncomfortable about posting spam, posting religious messages, posting bigotry, or posting self-pitying martyrdom or narcissism as you have done so often in the past. Stick to technical posts about C++, and you'll be quite comfortable and welcome here. |
| 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. |
No comments:
Post a Comment