4

Problem

  1. How can design my file parser to maximize the hardware when processing (creating meta data for) a large file

(i.e. how to avoid being blocked by IO and running out of memory)

preferably I would like to give the user a "high priority" (locks the system apart from some progress UI) and a "run in background" option (Allows the user to start using data that has already been indexed/loaded)

Assumptions

  1. Presumably I will have no problems having multiple threads reading the same set of files?
  2. The way I see it the biggest bottleneck / will be writing to the database. Presumably I will have to lock/unlock that and have each thread queue up data to write in batches?
  3. As each thread will need its own data queues I am unsure how to make sure the machine does not run out of memory
  4. When processing the data blocks I basically want to get stuff like averages, minimums and maximums, I have assumed I can't use the GPU to process the data blocks like this? it feels like there is too much shared data to utilize the GPU here.

Detail:

I am working with very large data sets, split across multiple files (each "full" data file is 1.5gb and there are often several of these files (I am looking at one now that has 10)

The data effectively contains a series of buffers that I want to access 1 or more at a time.

|headerInfo-datablock|HeaderInfo-datablock|HeaderInfo-datablock| (thousands)

I want to go through the data file, filling a database with index information (so i can access specific blocks quickly based of either information in the header or the datablock itself). If I can I would also want to blit information to a graph image as I do it.

Hardware

The machine it will be ran on is a proper workstation PC so there is plenty of ram and processing power to utilize :)

On the top spec machine there is 64GB of ram and a i7 that is 12 cores (hyperthreaded) so in theory i could get away with loading the whole file into memory and then processing. But some of the lower spec machines have a lot less ram and the files that people are producing are getting bigger every day, so Its not very forward thinking to rely on that plan.

Technology

I am using C# so any tips on the best ways to judge the hardware capabilities in C# (at run time) and maximize them when accessing a set of large files, would be a great bonus

|improve this question
  • 2
    There is no use in using more CPUs when you are blocked by IO – ratchet freak Mar 3 '15 at 9:44
  • 1
    Is the updated question better? Its less focussed on C# and more on how to avoid blockages by IO. The way I see it. Most of the io is reading, which if im not mistaken can be done by multiple threads – chrispepper1989 Mar 3 '15 at 9:49
  • 2
    @chrispepper1989 you are mistaken, IO is capped by architecture (the memory bus and drive speed) and more threads will not help – ratchet freak Mar 3 '15 at 9:52
  • 2
    good edit, it doesn't look like asking to recommend tools anymore – gnat Mar 3 '15 at 9:57
  • 2
    If it's a traditional spinning magnetic disk, then you don't want multiple threads reading different bits constantly. You will thrash the disk as it constantly seeks back and forth. Better to have one thread reading big chunks of data sequentially from disk, then passing them on to other threads. – Simon B Mar 3 '15 at 11:55
2

Your main bottle neck will always be IO unless you are doing some seriously intensive computations. Your best bet for squeezing the most performance out of your target machine to read all files serially (one at a time) and process each file concurrently (multiple calculation pipelines). Since you are using C#, I would suggest you look into using the Task Parallel Library for your calculation pipeline. The task scheduler is pretty darn smart about CPU utilization. You can provide it hints by specifying that particular tasks are going to be long running, thus requiring their own thread.

Design your processing pipeline such that it "pulls" data through and you'll never have more that one file in memory at a time. This means that every function which moves the pipeline forward must have some mechanism for bringing data in from the previous stage. The most common example of this type of mechanism in C# is the IEnumerable<T> and IEnumerator<T> interface pair and how they work with LINQ. You can think of LINQ statements as a series of pipeline operations that do no actual work until it is requested by some greedy function like ToArray().

|improve this answer
  • Would you read the whole file into memory and then process it then? Possibly splitting it into blocks? – chrispepper1989 Mar 4 '15 at 11:21
  • Reading serially is like using only one head of you hard drive. Assuming a decent setup (at least 4 disks each with 2 heads), reading 8 files in parallel would be ideal. – imel96 Mar 4 '15 at 14:55
  • Assuming the files are not dependent on each other, you would just have multiple file pipelines. You could easily write a system to manage the pipelines and provide metadata about them for hardware optimization purposes. Software should be like building with an unlimited amount of legos where you design the pieces. – mortalapeman Mar 4 '15 at 16:01
1

You should throw as many I/O jobs as possible and let the OS does its job, use async I/O to do that or mmap(). Don't assume you know how to it better than the OS, instead you can give hint. That's why there's call like madvise(), to let the OS know if you only need the data to be read once or sequentially, etc. Yes, even with magnetic disks you want to use every spindle and try to saturate the i/o bandwidth.

The only thing you shouldn't do is use more memory than what you have. Trashing happens when OS has to read something, discard and read it again. It's not the same as keeping the system busy, which is the goal of having good OS (high utilisation).

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.