This might sound funny but I got a homework and I can`t make any sense of it.
The statement sounds like this:
"Find the 10 largest numbers in an array of 100.000 randomly generated integers. You will use threads to compare 2 numbers. A daemon thread will print at regular intervals the progress and the number of unchecked integers left."
I know its not appropriate to ask for help on the forum regarding a homework but I am really REALLY frustrated .... I just cant figure out why, and how, should I use threads to deal with number comparison ..... Especially when it is about 100.000 integers. Even if I go through the list with a simple for using a max variable and printing out all the values it only takes about 150 milliseconds, at most(i tried)!!
Could you at least give me a starting idea on it ???
Sorry for wasting your time!
--CONTINUED--
As I said in a reply, braking up the array into X chunks(no. of threads) would be a good idea if I would have to find only 1 element(the largest) but because I need to find the 10 largest elements, supposing one thread finds its max value in the chunk it is working on, and discards the rest, maybe one of the discarded ones would actually be larger than the rest of the elements in the other chunks. That is why I don`t think this would a good result.
Feel free to argue my point of view!
Each thread can iterate through 100,000 / X numbers (where X is the number of threads) and keep track of the top 10 numbers in that thread. Then, when all threads are done, you can merge the results.
Break the list of 100k numbers in to batches of some size. Then spawn a thread to do the checking on each of the batches. Then just merge the results.
The bonus part of this, is such a solution will easily scale to huge lists of numbers.
The reason you need to do it with threads for this problem is not because you can't solve it without threads, but that it's a good example of a threadable problem (namely, can be parallelized); and a good teaching example since the business logic is so simple so you can concentrate on threading work.
No matter how you slice it, finding the max in an unsorted array means a linear search. You could simply partition the data among the number of available threads, then find the max number among the values that the threads came up with.
Well, you want to put that list of integers in a threadsafe queue. Each thread processes the numbers by pop'ing off the top.
This is the almost the same algorithm you already wrote, but it the key is the threadsafe queue, which lets the threads pull data off of it without clobbering each others data.
When each thread is complete, the main thread should take the results and find the largest numbers between the threads.
EDIT
If each thread gets the 10 largest numbers in its chunk, then it doesn't matter what is in the rest of the array, since the other threads will find the largest in their own chunk. for example:
Array : numbers between 1 and 99
Chunk 1 : 99 98 97 ... 50
Chunk 2 : 49 48 47 ... 1
Thread one result: 99 98 97 96 95 94 93 92 91 90
Thread two result: 49 48 47 46 45 44 43 42 41 40
Merged result: 99 98 97 96 95 94 93 92 91 90 49 48 47 46 45 44 43 42 41 40
Top 10 from merge: 99 98 97 96 95 94 93 92 91 90
See it doesn't matter that chunk 2 has no numbers larger than chunk one.
Related
I am learning about GIL in python and tried to run sys.refcount() and recevied value of 148. This might be a very simple question , any help would be appreciated.
Why is the value 148 and not 2 ?
import sys
c = 1
print(sys.getrefcount(c))
>>> 148
Your Python code isn't the only thing running. Much of the Python standard library is written in Python, and depending on which shell you use that can cause quite a few modules to be imported before the first thing you type. Here under CPython 3.10.0's IDLE:
>>> import sys
>>> len(sys.modules)
159
So just getting to the prompt imported 159(!) modules "under the covers".
"Small" integer objects are shared, across uses, by the CPython implementation. So every instance of 3 across all those modules adds to 3's refcount. Here are some others:
>>> for i in range(-10, 11):
... print(i, sys.getrefcount(i))
-10 3
-9 3
-8 3
-7 3
-6 3
-5 9
-4 5
-3 12
-2 25
-1 190
0 914
1 804
2 363
3 144
4 202
5 83
6 83
7 38
8 128
9 54
10 64
So 3 is "pretty popular", but 0 is the easy winner. Nothing else is using, e.g., -10 or -9, though.
But do note that knowing this is of no actual value to you. Whether and when Python shares immutable objects is implementation-defined, and can (and does!) change across releases.
int is special.
Its values are very numerous (pun intended) and small, which is the worst-case as far object overhead (it wastes time to allocate, GCs become slower because they have more heap objects to scan, and wastes time to reference count and deallocate). Typically language runtimes go to pretty great lengths to try to optimizations special cases like int, bool, etc.
Depending on the particular implementation of Python, it's possible that int objects are represented as:
Regular, run-of-the-mill heap-allocated objects (i.e., no special optimizations).
As regular heap-allocated objects, but with a pool of shared objects used to represent all the most common values. (e.g. every instance of 1 is the same object, referenced
everywhere where a 1 is used)
Or as a tagged
pointer, which involves no heap-allocation at all (for suitably small integer values).
In case 2 or 3, its reference count will not be what you might expect, had it been a "normal" object.
Suppose i am having a FIFO with depth 32 and width 8 bit.There is a valid bit A in all 32 locations.If this bit is 1 in all locations we have full condition and if 0 it will be empty condition.My Requirement is if this bit A at one location is 0 and all locations of this bit A is 1. when reaches to 30th location it should generate Almost_full condition.
Help me out please.
Thanks in Advance.
So you have a 32 bit vector and you want to check only one of the bits is 0. If speed is not much of a concern I will use a for loop to do this.
If speed is a concern I will get this done in 5 iterations. You can do this by divide and check method. Check two 16 bit words in parallel. Then divide this into two 8 bits and check them in parallel. And depending on where the zero is divide that particular 8 bit into 4 bits and check and so on.
If at any point you have zeros in both the parts, then you can exit the checking and conclude that almost_full = 0;
I'm creating program, which will generate all possible combinations from given range, with given length.
Eg.
range: 1-6
length: 3
111
112
113
114
115
116
121
...
666
I can make such program, whoever I want to add multithreading. So I want to receive a number of threads from the user, and divide the work between them, So instand of 1 thread which generate the combinations I want N threads to do it. I can't think of a way to divide the work between the threads. I searched in Google and here, however without any luck probably I'm not using the right keywords. I want some algorithm for this, if you need programming language to describe it to me, I will be able to understand any language from the C family.
A possible partition can be by sections (or - prefix) . For example:
range: 1-6, length: 4, N: 2
Thread1: all permutations that start with 1, 2 or 3.
Thread2: all permutations that start with 4, 5 or 6.
Since you already know how to output all permutations with one thread, just create N threads, but give them a new length (in the above example - new_length = 3). This should be easy enough if you have a single-threaded working code. Now, for each thread, just add all the prefixes of the thread. Back to the example - after Thread1 is done creating all permutations of {range: 1-6, length: 3}, you just create 3 permutations from each value of the results - one with prefix of "1", one with prefix of 2, and one with prefix of "3". for 556, for example, you output 1556, 2556, 3556.
I want to generate random numbers in assembly (nasm, linux) and I don't want to use the libc (for didactic reasons), so I'm planning on reading /dev/urandom.
The thing is, I would like them to be in a specific range.
For instance let's say I want a number from 0 to 99.
When I read a byte from /dev/urandom it will come in the range 0x00 to 0xff (255).
One thing I could do is apply a mod 100, which would guarantee the correct range.
But the problem with this approach is that some numbers have more chance to
come out than others.
The number 51 would come out from 3 different results:
51 % 100 = 51
151 % 100 = 51
251 % 100 = 51
The number 99 would come only from 2 different results:
99 % 100 = 99
199 % 100 = 99
(there will be no 299 since the range of a byte ends in 255).
The only solution I came up with involves discarting the random number
when it is in the range 200-255 and reading another one.
Is there a more clever way to read a random byte, and make sure
it is in a certain range while being "fair"?
What if I'm planning to read lots of bytes within a range?
Is there a way to be fair without discarting lots of urandom reads?
I heard about the getrandom(2) linux syscall, but it's not yet in a stable kernel (3.16.3 as of this time). Is there an alternative?
As an example, suppose a QR Code data stream contains 55 data words (each one byte in length) and 15 error correction words (again one byte). The data stream begins with a 12 bit header and ends with four 0 bits. So, 12 + 4 bits of header/footer and 15 bytes of error correction, leaves me 53 bytes to hold 53 alphanumeric characters. The 53 bytes of data and 15 bytes of ec are supplied in a string of length 68 (str68). The problem seems simple enough - concatenate 2 bytes of (right-shifted) header data with str68 and then left shift the entire 70 bytes by 4 bits.
This is the first time in many years of programming that I have ever needed to do something like this, I am a c and bit shifting noob, so please be gentle... I have done a little investigation and so far have not been able to figure out how to bitshift 70 bytes of data; any help would be greatly appreciated.
Larger QR codes can hold 2000 bytes of data...
You need to look at this 4 bits at a time.
The first 4 bits you need to worry about are the lower bits of the first byte. Fortunately this is an easy case because they need to end up in the upper bits of the first byte.
The next 4 bits you need to worry about are the upper bits of the second byte. These need to end up as the lower bits of the first byte.
The next 4 bits you need to worry about are the lower bits of the second byte. But fortunately you already know how to do this because you already did it for the first byte.
You continue in this vein until you have dealt with the lower bytes of the 70th byte.