I am currently developing a GUI program called QuickPar. It's based on mirror AND QuickSFV, both in one program. It knows about SFV files and PAR files, and it uses the check-only-once-if-found-OK feature of QuickSFV to prevent re-checking of files found good last time they were checked. (Though the format is not cross-compatible with QuickSFV.)
I, currently, can see about 3 different things that would make mirror *WAY* faster on a windows box. Currently it takes around 4-5 times longer than it should, in my estimation.
I'm curious as to whether I should just use parts of your code, or if I should buck up and rewrite the whole thing? I looked at some of your code, and wow... talking about hard to read. What's with all this one-letter-variable crap? I want a version of the RS coding I can use with other projects anyway...
If you're interested I could submit the source to your project. I don't plan on making it anything but FreeWare anyway, so I wouldn't see a prob with that.
I can also see an improvement to your filespec that would allow you to simply repair damaged files instead of totally replacing them -- something I may implement in my program if I can figure a way to make it backwards compatible with mirror and parchive.
Anyway, drop me an email at sanche@ualberta.ca if you're a programmer on the team and wish to discuss QuickPar with me. I'm sure I could divulge my ideas on how to make your algorithm faster -- one major point really only works on windows, but there are some improvements to the RS coding I found.
-Ryan Sanche
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>It's just the source from parchive -- I would assume he used parts from that... perhaps I am wrong.
Uhm, Yes and No...
For building the restoring matrix, I coded the usual mathemathical algorithm. For inverting that matrix, I took a PD C routine for inverting, ported it to delphi and changed it from arithmethic calculation to galois fields. Because this still uses the algorithms, you learn in school, the structure nearly looks like Willems C code.
But this is not important for speed, because it is done just a single time.
The actual calculus, I'm doing in a different way.
(Other Loops and direct array access for the galois calculus - no subroutines.)
But even that is not vital.
What's the big bottomleck here is the file access. To read simultaniously from a variable number of files is a bit difficult to code in Delphi. (Maybe memory-mapped files are faster than the filestreams I use, but I don't know, how to code them...)
C is a bit more easier there, but then Windows sets a limit to the number of open files...
So you have to choose a good strategy for handling the file access. And you better don't use my system as a example for this. I'm just a amateur, coding with his old Turbo Pascal knowledge from highschool...
Stefan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am currently developing a GUI program called QuickPar. It's based on mirror AND QuickSFV, both in one program. It knows about SFV files and PAR files, and it uses the check-only-once-if-found-OK feature of QuickSFV to prevent re-checking of files found good last time they were checked. (Though the format is not cross-compatible with QuickSFV.)
I, currently, can see about 3 different things that would make mirror *WAY* faster on a windows box. Currently it takes around 4-5 times longer than it should, in my estimation.
I'm curious as to whether I should just use parts of your code, or if I should buck up and rewrite the whole thing? I looked at some of your code, and wow... talking about hard to read. What's with all this one-letter-variable crap? I want a version of the RS coding I can use with other projects anyway...
If you're interested I could submit the source to your project. I don't plan on making it anything but FreeWare anyway, so I wouldn't see a prob with that.
I can also see an improvement to your filespec that would allow you to simply repair damaged files instead of totally replacing them -- something I may implement in my program if I can figure a way to make it backwards compatible with mirror and parchive.
Anyway, drop me an email at sanche@ualberta.ca if you're a programmer on the team and wish to discuss QuickPar with me. I'm sure I could divulge my ideas on how to make your algorithm faster -- one major point really only works on windows, but there are some improvements to the RS coding I found.
-Ryan Sanche
I didn't know that the sources of Mirror were available ?
I'd like to take a look at them myself. Where did you find them ?
Willem.
I didn't know that the sources of Mirror were available ?
I'd like to take a look at them myself. Where did you find them ?
Willem.
It's just the source from parchive -- I would assume he used parts from that... perhaps I am wrong.
-Ryan
>It's just the source from parchive -- I would assume he used parts from that... perhaps I am wrong.
Uhm, Yes and No...
For building the restoring matrix, I coded the usual mathemathical algorithm. For inverting that matrix, I took a PD C routine for inverting, ported it to delphi and changed it from arithmethic calculation to galois fields. Because this still uses the algorithms, you learn in school, the structure nearly looks like Willems C code.
But this is not important for speed, because it is done just a single time.
The actual calculus, I'm doing in a different way.
(Other Loops and direct array access for the galois calculus - no subroutines.)
But even that is not vital.
What's the big bottomleck here is the file access. To read simultaniously from a variable number of files is a bit difficult to code in Delphi. (Maybe memory-mapped files are faster than the filestreams I use, but I don't know, how to code them...)
C is a bit more easier there, but then Windows sets a limit to the number of open files...
So you have to choose a good strategy for handling the file access. And you better don't use my system as a example for this. I'm just a amateur, coding with his old Turbo Pascal knowledge from highschool...
Stefan