Thread: Conceptual notion of a function/procedure which continuously repeats its methods

  1. #16
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Quote Originally Posted by Mario F. View Post
    The operations are entirely sequential. You need the data before you can process it and you need to process it before you can output it. There's no benefit in multi-threading here, particularly because the initial operation of fetching the data from the internet has higher latency than the two other threads combined.
    I was going to mention something to this effect too. Depending on the size of the data, it might actually be more costly to be using threads. You don't need 4 threads to parse a 4 element array, for example. There's a point of diminishing returns with regards to threads.

    OP, most of the best advice I've gotten is from Mario and one thing he's said that's always stuck with me is, threads are an optimization technique. Believe me, not all optimization techniques work or are even worth the effort. Especially if you're doing threads in C. * shudders *

  2. #17
    Registered User
    Join Date
    Jan 2016
    Single thread would be simpler and very easy to implement. Only thing is with multithreading you can work on different parts of the data at the same time. If the data is very large then this might be useful.

  3. #18
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    The size of the dataset is largely irrelevant. Collect -> Process -> Print represent atomic sequential processing tasks and do not translate into a multithreading need. It merely defines your data workflow; and on this case that of any typical single-threaded application.

    To justify a multithreading requirement you need to approach each of those tasks individually and find a reason to turn it into a multithreaded one. What are the operations that go into the Processing task? Can they benefit from multithreading and should you turn the Processing task into a multithreaded task? Will the performance gain be justified when considering the latency inherent to the Collect task? What are my software speed requirements and expectations, will the speed gains (assuming there will be any) justify the mammoth task of designing and maintaining a multithreaded application? etc, etc...

    These are some of the question you should ask. And how you should approach any decisions on multithreading; i.e. from inside-out, from the most atomic level of your code and outwards. High-level designs like those described by rcgldr (and that impact at the task level as you would like) are important designs but they represent Concurrency, which is a distinct concept from multithreading and aims to solve different problems. Your design does not seem to be concurrent at all. So, if you wish to play with threads in C you have to dig deeper into your code and find a reason there.
    Last edited by Mario F.; 10-26-2016 at 06:11 PM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #19
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    Is your program a client (opens it's own connections, pulls data from the net) or a server (passively waits for connections, data is pushed to it)?

    How many concurrent clients (or connections) are you expecting to deal with?

    How many concurrent messages are you expecting to deal with?

    How much work is involved in each message?
    If your 'work' is "parse some text to extract a bit of data", then it's over and done with before the next byte arrives from the network driver.
    If your 'work' is "factorise this 500-digit number", then you've got a lot of CPU time from very little network data.

    > The overall function of the program is to get data from the internet, process that data and then to format the data on the terminal.
    OK, the bottlenecks in order here are:
    1. The operator trying to read the display, a few bytes per second if it's textual information, maybe a few KB/sec if it's graphical.
    2. Fetching data from the internet. Unless you're in a data centre, you're maxing out at between 1 to 10Mbytes per second. But that greatly depends on the other end being able to deliver.
    3. Drawing images on your screen. Modern GPU's can refresh HD screens at 50/60Hz, which is in the 100's of MBytes per second.
    4. Reading and writing DRAM is well into the GBytes per second.

    > If the data is very large then this might be useful.
    Premature optimisation disease strikes again.
    What is "very large" to begin with?
    How often do they arrive?
    How long do they take to process?

    > It's too large to post here.
    But version 0.1 without threads / proof of concept might help us make better guesses as to how much work is really involved at each step.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Conceptual ambiguity "function prototype"
    By password636 in forum C Programming
    Replies: 4
    Last Post: 04-02-2009, 12:48 PM
  2. c library function conceptual doubt
    By agarwaga in forum C Programming
    Replies: 2
    Last Post: 05-11-2006, 11:34 AM
  3. notion confusion
    By volk in forum C++ Programming
    Replies: 7
    Last Post: 05-21-2003, 01:15 PM

Tags for this Thread