|
Hi Colin,
this is puzzling me: I expect GUID are unique all over the universe.
They also need many bits; how can it be if a take 1 million GUIDs and convert each of them
to int, that all ints will also be unique (inside my confined process that is),
so which transformation preserves uniqueness while compressing from many to 32 bits ??
A simple hash code wont be sufficient, its only function as I understand is putting objects
into 2^32 buckets with a "good distribution".
Can you enlighten me on this ? Thanks.
|
|
|
|
|
Guids are 128 bits. No one said anything about being constrained to 32 bits.
Upcoming events:
* Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ...
"I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless."
My website
|
|
|
|
|
Thanks Colin
I confused with the GUID strings, the ones used for registering a class (and filling the
registry).
Now 128-bit isnt very much, and MSDN on Guid.NewGuid says "There is a very low probability that the value of the new Guid is all zeroes or equal to any other Guid." which may not be good
enough for the OP, he really insisted on uniqueness...
|
|
|
|
|
Oh, the OP don't have to worry about it...
However, using GUIDs is not practical due to timing requiremts and 128-bit integers handling: he don't need such complexity.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Your solution is simply not practical.
See Luc Pattyn one [^] for a better approach (at least IMHO).
BTW you don't need to convert hexadecimal chars to obtain integers from GUIDs.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: Your solution is simply not practical.
I realise this also[^]
Upcoming events:
* Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ...
"I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless."
My website
|
|
|
|
|
Converting GUID into numbers does not guarantee uniqueness... I've checked that already.
|
|
|
|
|
Jalpesh B. Patel wrote: Converting GUID into numbers does not guarantee uniqueness... I've checked that already.
Yes, it does. You have to translate it in to a 128bit number. You never specified you were constrained by a specific size of number. If that is the case you might want to be a bit more specific about your requirements in the future.
Upcoming events:
* Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ...
"I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless."
My website
|
|
|
|
|
I am sorry for that...
but mine should be in the range of Long or uLong.
|
|
|
|
|
You might want to go with Luc's idea[^]
Upcoming events:
* Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ...
"I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless."
My website
|
|
|
|
|
By the way,
How do i convert it to 128 bits ?
|
|
|
|
|
This sounds like a homework assignment. If there is no In/Output, how do you expect to ensure that these numbers are unique?
After a crash, that is.
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
Its not homework man.
I really have to make an app that can server as much as 50,000 numbers per sec.
I/O makes it too slow...thats why
|
|
|
|
|
You'll need something longer than a 32bit ID then.
50,000ids/sec = 4,320,000,000ids/day, so would overflow a 32bit ID in slightly less than 24 hours.
--
You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
|
|
|
|
|
store number 0 to text file before execution of ur application.During execution get that number from the file.Increment that nos. by 1.and overrite it to same file.![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Regards
Chintan
www.visharadsoft.com
(Nothing is so purify as KNOWLEDGE)
|
|
|
|
|
Tried it already...
This is too much I/O at this rate I would generate between 30-50 per sec.
I want 50,000 per sec.
|
|
|
|
|
It's very difficult to maintain state across application crashes without resorting to some form of external mechanism in which to persist that state (IO/Database/WebService/Whatever). However, have you considered the use of GUIDS in your application?
"It was the day before today.... I remember it like it was yesterday."
-Moleman
|
|
|
|
|
The problem with saving something to disk or database is the reduction in performance of the application.
I have to generate the numbers as fast as 50,000 per second. Without loss.
I have tried saving in registry, database and files, the i/o overhead is too much. I didn't forget MSMQ too.
And converting GUID to Long does not guarantee uniqueness.
Please help with something else.
|
|
|
|
|
I'm intrigued - what does your application do that it requires 50,000 unique numbers every second?
"It was the day before today.... I remember it like it was yesterday."
-Moleman
|
|
|
|
|
Well, actually other apps request mine to give them a unique number. and those request come very very fast...
|
|
|
|
|
Ah, I see.
Here's an idea (but I think Luc's is better, now that I've just read it). The major problem you're facing is the IO overhead, and yet you do need some way to prevent duplicates from occuring.
How about booking out blocks of numbers in large chunks (for the sake of argument, say 50,000 at a time), and keeping a file which tells your program the range of the next chunk. That way, if your program crashed it could restart and know what the next chunk of numbers should be, and the number of IO requests would be fewer than with an update after every number issued. Of course, in a situation where your program crashed after only 10 numbers had been issued, you'd have "lost" 49,990 numbers...
"It was the day before today.... I remember it like it was yesterday."
-Moleman
|
|
|
|
|
Hi,
this is how I might tackle this one:
- split the (32-bit) number you are after into a session field and a sequential field
(e.g. 16-bit each).
- keep the session field in a file, read it from file, increment it, write it back to file,
read it again from file, check it, now trust it;
- withtin the session, that just got a new session ID, initialize the sequential field
to zero, increment it everytime you need a new number
- if sequential field is exhausted, start a new session
- use Interlocked.Increment to protect your sequential field
- use appropriate locking to protect your operations on the session ID.
You can choose how many bits you spend to the session ID; more bits means less numbers
get skipped (new session starts with skipping some) but more session ID operations
(i.e. file operations) are involved.
|
|
|
|
|
I think it is a very good approach.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
That sounds pretty smart, my 5!
|
|
|
|
|
You could always use the DateTime.Ticks - with a little bit of synchronisation to make sure that you haven't already retrieved it.
private static object SyncLock = new object();
private long lastValue = 0;
public static long GetUnique()
{
lock (SyncLock)
{
long value = lastValue;
while (value == lastValue)
{
value = DateTime.Ticks;
}
lastValue = value;
return value;
}
}That's off the top of my head, so I apologise now if it needs tweaking a little bit.
Deja View - the feeling that you've seen this post before.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
