Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

22nd Century C

procedural.github.io

Post reply on HN
Print view View original

101–106 of 106 posts

Re: 22nd Century C

#101

Post by fnl »

tbirdz wrote: post #85
fnl wrote: post #82

Earlier quoted context omitted.

Even a hundred million integers still adds up to only 300 MB extra for 64- vs. 16-bit. On any reasonable modern server, laptop, or desktop, that kind of memory usage probably will be the least of your worries, all the more if you really have an application that needs to hold hundreds of millions of ints in memmory at the same time. And if you are programming for a very specific embedded or otherwise constrained syste…

I'm not sure where you are getting the 300MB figure from. ((64-16)/8)x10^8/2^20 gives me 572.2MB of wasted space. What's even more interesting is looking at the percentage of wasted space. (((64-16)/8)x10^8/2^20)/(((64)/8)x10^8/2^20) means a whopping 75% of the memory use of our program is completely useless wasted space. Using more space than you need to will also impact performance. First there's the cache issues.…

Sorry for the 400-100=300MB mix-up, you are completely right, it should have been 800-200=600MB.

If you need to crunch all those numbers at once, then yes, your cache will become your bottleneck. But if you were, say, keeping the count on a 100 million things, you most of the time will not be worried about that or your RAM usage, as most counts typically tend to follow a power-law distribution. Therefore, contention to make sure you are tracking every count will probably become a far worse problem for your app than your ability to shuffle data to/from the CPUs. Only in the corner case where you crunch a matrix or vectors or numbers of that size at once, you will start to get worried. But as said, I think the tensor-crunching use-case is the exception, not the norm.

Re: 22nd Century C

#102

Post by TheNewAndy »

lake99 wrote: post #100
TheNewAndy wrote: post #98

Earlier quoted context omitted.

> I am not sure about that. The original poster wrote 'I have never once thought: "You know what, I'd like to make a decision as to the width of an integer every time I declare a function."' I disagreed with that, and that's where the whole discussion started off. But your solution also doesn't involve deciding on the width of an integer - your solution is to use integers that have a minimum width. By doing that, you…

> But your solution also doesn't involve deciding on the width of an integer - your solution is to use integers that have a minimum width. We declare the minimum width for all variables. We don't use "int" in for loops and hope for the best. I wouldn't go as far as to say "we don't care". We don't worry too much for code that's mean to be portable. We obviously care in non-portable code. But the important point here…

> The only way to ensure fixed widths without int_leastX conventions is to be intimately familiar with the platform while we are declaring our typedefs, or creating makefiles for our projects..

int_leastX_t doesn't give you fixed width types - that's the entire point of them. They are not fixed width.

> And to that extent, we use only fixed with types.

I don't get it. You said this:

> We don't use uint8_t or other such things, we use uint8, uint16, etc. These are typedefed to compiler-specific types that guarantee a required minimum size.

You are using uint_least8_t, uint_least16_t, just with different names. As I've said - I don't really care what things are called.

Semantically, there is very little that is different between "uint_least16_t" and "unsigned short".

Re: 22nd Century C

#103

Post by lake99 »

TheNewAndy wrote: post #102
lake99 wrote: post #100

Earlier quoted context omitted.

> But your solution also doesn't involve deciding on the width of an integer - your solution is to use integers that have a minimum width. We declare the minimum width for all variables. We don't use "int" in for loops and hope for the best. I wouldn't go as far as to say "we don't care". We don't worry too much for code that's mean to be portable. We obviously care in non-portable code. But the important point here…

> The only way to ensure fixed widths without int_leastX conventions is to be intimately familiar with the platform while we are declaring our typedefs, or creating makefiles for our projects.. int_leastX_t doesn't give you fixed width types - that's the entire point of them. They are not fixed width. > And to that extent, we use only fixed with types. I don't get it. You said this: > We don't use uint8_t or other su…

> As I've said - I don't really care what things are called.

I think this is where our disagreement lies. To me, this counts as "make a decision as to the width of an integer every time I declare a function". We are deciding the lower bound, but still, it's a decision on that matter.

> Semantically, there is very little that is different between "uint_least16_t" and "unsigned short".

But there could be a difference between "uint_least16_t" and "unsigned int" or "unsigned short". And there could be a difference between "uint_least32_t" and "unsigned int" or "unsigned long".

Re: 22nd Century C

#104

Post by TheNewAndy »

lake99 wrote: post #103
TheNewAndy wrote: post #102

Earlier quoted context omitted.

> The only way to ensure fixed widths without int_leastX conventions is to be intimately familiar with the platform while we are declaring our typedefs, or creating makefiles for our projects.. int_leastX_t doesn't give you fixed width types - that's the entire point of them. They are not fixed width. > And to that extent, we use only fixed with types. I don't get it. You said this: > We don't use uint8_t or other su…

> As I've said - I don't really care what things are called. I think this is where our disagreement lies. To me, this counts as "make a decision as to the width of an integer every time I declare a function". We are deciding the lower bound, but still, it's a decision on that matter. > Semantically, there is very little that is different between "uint_least16_t" and "unsigned short". But there could be a difference b…

The comment that started it all was very clear that "make a decision as to the width of an integer" was referring to deciding on the exact width. In the same sentence that quote is taken from, it makes it clear that it is talking about fixed sized numerics. Deciding the width of an integer is not the same as deciding the minimum width of an integer (otherwise, the original comment makes no sense).

In the next paragraph it contrasts this with the minimum width approach ("word-sized ints and size_t's").

Deciding on the minimum width of a data type is a decision that needs to be made, and is made regardless of how you spell your type name. If you use an "int", you have specified that it must be at least 16-bits wide. Just because the name of the type doesn't have the number 16 in it doesn't mean that the same decision isn't being made.

Re: 22nd Century C

#105

Post by lake99 »

TheNewAndy wrote: post #104
lake99 wrote: post #103

Earlier quoted context omitted.

> As I've said - I don't really care what things are called. I think this is where our disagreement lies. To me, this counts as "make a decision as to the width of an integer every time I declare a function". We are deciding the lower bound, but still, it's a decision on that matter. > Semantically, there is very little that is different between "uint_least16_t" and "unsigned short". But there could be a difference b…

The comment that started it all was very clear that "make a decision as to the width of an integer" was referring to deciding on the exact width. In the same sentence that quote is taken from, it makes it clear that it is talking about fixed sized numerics. Deciding the width of an integer is not the same as deciding the minimum width of an integer (otherwise, the original comment makes no sense). In the next paragra…

I lost track of this discussion!

> If you use an "int", you have specified that it must be at least 16-bits wide.

Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. Then come beasts like "long" or "long long", and people must pull out compiler manuals, talk on support forums, and so on. A developer is obliged to do that, but system integrators and cross-team reviewers are in for a world of pain if they have to keep reading across code bases across platforms like that. It's not an unrealistic scenario. A modern airplane or electric train is bound to have tens of processor families littered throughout the vehicle.

The original commenter also wrote about Swift going backwards, with its UInt8, Int32, etc. I'm not a Swift programer, but the documents gave me the impression that these are, again, syntactic widths, not physically allocated, i.e. semantic widths. All this shows that the original commenter had a problem with specifing any indication of the size of integers. His emphasis on "word-sized" clearly indicates that he wants to use "int" everywhere, and hopes the compiler will take care of the rest. This is what Swift does too with its "Int".

Re: 22nd Century C

#106

Post by TheNewAndy »

lake99 wrote: post #105
TheNewAndy wrote: post #104

Earlier quoted context omitted.

The comment that started it all was very clear that "make a decision as to the width of an integer" was referring to deciding on the exact width. In the same sentence that quote is taken from, it makes it clear that it is talking about fixed sized numerics. Deciding the width of an integer is not the same as deciding the minimum width of an integer (otherwise, the original comment makes no sense). In the next paragra…

I lost track of this discussion! > If you use an "int", you have specified that it must be at least 16-bits wide. Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. Then come beasts like "long" or "long long", and people must pull out compiler manuals, talk on support forums, and so on…

> I lost track of this discussion!

Hah, me too. I wonder if you will ever see this :-)

> Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions.

If people are just writing code for PCs, then it is no longer portable code that is being talked about.

But when writing portable code, which you do and I do, being overly specific with type widths is bad.

The C data types all have very specific widths, and it is just a fact that int is at least 16-bits wide.

I'm not a swift person either, but based on reading this:

https://developer.apple.com/library/content/documentation/Sw...

It sounds like the types with numbers in their name are most certainly fixed width types. The original commenter didn't like the emphasis on such fixed widths, and I think the swift language designers agree - their section on the "Int" type (which is at least 32-bits wide, but may be 64-bits wide) says that this is the type that people should be using generally.

"Int" in swift is quite similar to "int" in C, just the C version is less constrained (may be any width >= 16 bits). But the principle is the same - for better portable code, enforcing exact widths of types is not a good thing.

Post reply on HN