Seti@Home optimized science apps and information
Optimized Seti@Home apps => Windows => GPU crunching => Topic started by: efmer (fred) on 06 Dec 2009, 05:13:59 am
-
Just a suggestion ,it would be nice to add a flops statement to the app_info.xml.
Because BOINC still doesn't have a separate CPU / GPU scheduler, the flops statement is essential is you have a faster GPU installed.
Without the flops, I see GPU tasks planned for almost 3 hours, as they take only 15 minutes or less, this causes the scheduler to request no GPU tasks.
-
Just a suggestion ,it would be nice to add a flops statement to the app_info.xml.
Because BOINC still doesn't have a separate CPU / GPU scheduler, the flops statement is essential is you have a faster GPU installed.
Without the flops, I see GPU tasks planned for almost 3 hours, as they take only 15 minutes or less, this causes the scheduler to request no GPU tasks.
Have been thinking about *something* along those lines, so it must be a good idea :P. It's on a pretty long list of stuff that needs looking at ... Have not managed to work out how to best determine a default entry ... I'm hoping to avoid having to parse boinc state files (as they can be problematic for a few reasons) and installer parsing capabilities aren't easy to program.
It might be best to leave that to a separate small GUI app (perhaps optionally installed in installer & run after setup. ) which could be run even sometime after installation (for 'recalibration' to new hardware etc, could evolve into kindof a control panel applet or similar). If that looks like the way to go (when I get to it), then I'll lliase with Richard Haselgrove on the latest best defaults. Since I've been preoccupied with my own 'fiddling', rather than concerned with how flops is dealt with now that new Boinc versions seem to have multipled the performance of my card by five for no apparent technical/practical purpose other than marketing ::).
Jason
-
Just a suggestion ,it would be nice to add a flops statement to the app_info.xml.
Because BOINC still doesn't have a separate CPU / GPU scheduler, the flops statement is essential is you have a faster GPU installed.
Without the flops, I see GPU tasks planned for almost 3 hours, as they take only 15 minutes or less, this causes the scheduler to request no GPU tasks.
Have been thinking about *something* along those lines, so it must be a good idea :P. It's on a pretty long list of stuff that needs looking at ... Have not managed to work out how to best determine a default entry ... I'm hoping to avoid having to parse boinc state files (as they can be problematic for a few reasons) and installer parsing capabilities aren't easy to program.
It might be best to leave that to a separate small GUI app (perhaps optionally installed in installer & run after setup. ) which could be run even sometime after installation (for 'recalibration' to new hardware etc, could evolve into kindof a control panel applet or similar). If that looks like the way to go (when I get to it), then I'll lliase with Richard Haselgrove on the latest best defaults. Since I've been preoccupied with my own 'fiddling', rather than concerned with how flops is dealt with now that new Boinc versions seem to have multipled the performance of my card by five for no apparent technical/practical purpose other than marketing ::).
Jason
The easiest way is by a GPU card list, because as you already stated, the reported values are not very accurate, but have to be as high as possible, marketing wise.
If you are interested I could help you with some things, I have some experience. Detecting the nVidia and AMD cards is fairly easy to do.
-
The easiest way is by a GPU card list, because as you already stated, the reported values are not very accurate, but have to be as high as possible, marketing wise.
If you are interested I could help you with some things, I have some experience. Detecting the nVidia and AMD cards is fairly easy to do.
Cheers Fred. Good ideas. A few things that I need to look at before getting to that. In the meantime, for reference, the installer system I use is the NSIS one, and can run external (customi by us) executables for detection etc.
Probably if you're going to be helping out with installer stuff (which has proven a bit more important/successful than I thought it would) then you should have some developer access. I'll forward a link to this post/thread to Gecko_R7, to see if it's possible/feasible to arrange that. [Edit: haven't seen much of our liizard friend lately, hopefully he's still about & doing well]
Jason
-
Have been thinking about *something* along those lines, so it must be a good idea :P. It's on a pretty long list of stuff that needs looking at ... Have not managed to work out how to best determine a default entry ... I'm hoping to avoid having to parse boinc state files (as they can be problematic for a few reasons) and installer parsing capabilities aren't easy to program.
Agreed, parsing state files is a pain. The 'correct' way to do it within BOINC would be a GUI_RPC (http://boinc.berkeley.edu/trac/wiki/GuiRpc): but - I've just done one with <get_host_info> (against v6.10.21), and it only mentions the CPU. No reference to the CUDA card at all!!
Fred - please check and confirm: they've forgotten to add any GPU information to the standard GUI_RPC calls (<get_state> says nothing either). I'll check with DA, too.
Pending that, there is no way of getting GPU information even by file parsing - it would have to be direct detection. I would suggest it would be better to query the card(s) directly for shaders/speeds/compute capability, and impute a figure from that - like the old BOINC 'est flops' figure, peak is useless - rather than working from a look-up list which would be difficult to maintain and go rapidly out of date.
It might be best to leave that to a separate small GUI app (perhaps optionally installed in installer & run after setup. ) which could be run even sometime after installation (for 'recalibration' to new hardware etc, could evolve into kindof a control panel applet or similar). If that looks like the way to go (when I get to it), then I'll lliase with Richard Haselgrove on the latest best defaults. Since I've been preoccupied with my own 'fiddling', rather than concerned with how flops is dealt with now that new Boinc versions seem to have multipled the performance of my card by five for no apparent technical/practical purpose other than marketing ::).
Jason
Happy to work with you on it when the time comes. Remember also that effective flops are strongly dependent on the version of the CUDA .DLLs in use, and judging by recent reports, driver version as well (195.xx on Win7 is horribly slow, I read - but that may just be FUD).
-
Have been thinking about *something* along those lines, so it must be a good idea :P. It's on a pretty long list of stuff that needs looking at ... Have not managed to work out how to best determine a default entry ... I'm hoping to avoid having to parse boinc state files (as they can be problematic for a few reasons) and installer parsing capabilities aren't easy to program.
Agreed, parsing state files is a pain. The 'correct' way to do it within BOINC would be a GUI_RPC (http://boinc.berkeley.edu/trac/wiki/GuiRpc): but - I've just done one with <get_host_info> (against v6.10.21), and it only mentions the CPU. No reference to the CUDA card at all!!
Fred - please check and confirm: they've forgotten to add any GPU information to the standard GUI_RPC calls (<get_state> says nothing either). I'll check with DA, too.
Pending that, there is no way of getting GPU information even by file parsing - it would have to be direct detection. I would suggest it would be better to query the card(s) directly for shaders/speeds/compute capability, and impute a figure from that - like the old BOINC 'est flops' figure, peak is useless - rather than working from a look-up list which would be difficult to maintain and go rapidly out of date.
It might be best to leave that to a separate small GUI app (perhaps optionally installed in installer & run after setup. ) which could be run even sometime after installation (for 'recalibration' to new hardware etc, could evolve into kindof a control panel applet or similar). If that looks like the way to go (when I get to it), then I'll lliase with Richard Haselgrove on the latest best defaults. Since I've been preoccupied with my own 'fiddling', rather than concerned with how flops is dealt with now that new Boinc versions seem to have multipled the performance of my card by five for no apparent technical/practical purpose other than marketing ::).
Jason
Happy to work with you on it when the time comes. Remember also that effective flops are strongly dependent on the version of the CUDA .DLLs in use, and judging by recent reports, driver version as well (195.xx on Win7 is horribly slow, I read - but that may just be FUD).
I checked the source for the GET_HOST_INFO and it only has information about the CPU stored.
There is some info in the message log, that can be read by RPC calls, but you can only do that after stopping and restarting the BOINC client.
But I don't know how accurate this info is.
Do you know of any plans of making the GPU processing self learning. e.g. add a separate correction factor in the BOINC Client. That would be the best way to go.
Otherwise there are several options, one is read the capabilities of the card directly and make a calculated guess of the actual flops to fill in the xml file.
And I have noticed a performance difference in XP and WIN 7 that is considerable, maybe 10 - 20%. But that will improve after they have solved the problem of making it work at all.
-
I checked the source for the GET_HOST_INFO and it only has information about the CPU stored.
There is some info in the message log, that can be read by RPC calls, but you can only do that after stopping and restarting the BOINC client.
But I don't know how accurate this info is.
Do you know of any plans of making the GPU processing self learning. e.g. add a separate correction factor in the BOINC Client. That would be the best way to go.
Otherwise there are several options, one is read the capabilities of the card directly and make a calculated guess of the actual flops to fill in the xml file.
And I have noticed a performance difference in XP and WIN 7 that is considerable, maybe 10 - 20%. But that will improve after they have solved the problem of making it work at all.
Yes, I checked those sources as well before asking my calculatedly-naive question on boinc_alpha. Sometimes the simplest questions have the biggest sting in the tail.
I think the start-up message log is a dead-end - not the way to go all all. The information is accurate, but summarised and badly structured - parsing it would involve detecting whether it came from a client reporting 'real' flops or 'marketing' flops, and applying different correction factors to each. David should respond to my question with an 'ooops', and I could ask him to code, as far as possible, the raw technical details returned by the GPU's API.
As regards self-learning: yes, it's been requested many times - basically, to record and maintain TDCF at the app_version level - and agreed in principle many months ago. But boring chores like this tend to get pushed to the back of the development queue. We've had the whole facebook cycle, and the ATI management, before the basic functions are properly debugged. At the moment, I'm pushing him quite hard on debt management (affecting work fetch and task switching), which is still fubar'd 50 weeks after the public CUDA launch.
-
Jorden has reminded us that you can get a sneak preview of the fields that should be in the RPC by looking at a project sched_request.xml file.
-
Jorden has reminded us that you can get a sneak preview of the fields that should be in the RPC by looking at a project sched_request.xml file.
There is a flops value in the file, per application. But it can be the manually placed value or the system value.
And the original system value is about a factor 10 off from the one it should be on my system.
Another problem is that you have to be lucky enough, that there is a cuda task in the scheduler file.
-
There is a flops value in the file, per application. But it can be the manually placed value or the system value.
And the original system value is about a factor 10 off from the one it should be on my system.
Another problem is that you have to be lucky enough, that there is a cuda task in the scheduler file.
Just thinking, another option is to obtain/calculate the values we need programmatically through CudaAPI.
Not sure what Boinc uses now, but IIRC the first releases that supported Cuda derived a value from the clocks & number of multiprocessors.
I think it may be most reliable if we calcuate it ourselves and scale as required. Being independant of Boinc, it should be simpler than processing Boinc files that may be subject to change in content or backend value/meaning per Boinc version.
The other appeal , to me, is that it should (at least partially) work for unknown/unlisted/unreleased cards, which might be an advantage over using lookup tables too ( less maintenance, i.e. not having to make a new release everytime nVidia releases/renames a card) ... it should also account for OC.
Thoughts ?
[Later:] I guess ATI would have it's own similar api method/needs ... for CPU some tiny timed calculation might be sufficient, but as an option can always implement the same bench as used by boinc (a fairly easy initial option, even if we didn't end up sticking with it as is).
-
There is a flops value in the file, per application. But it can be the manually placed value or the system value.
And the original system value is about a factor 10 off from the one it should be on my system.
Another problem is that you have to be lucky enough, that there is a cuda task in the scheduler file.
Just thinking, another option is to obtain/calculate the values we need programmatically through CudaAPI.
Not sure what Boinc uses now, but IIRC the first releases derived a value from the clocks & number of multiprocessors.
I think it may be most reliable if we calcuate it ourselves and scale as required. Being independant of Boinc, it should be simpler than processing Boinc files that may be subject to change in content or backend value/meaning per Boinc version.
The other appeal of, to me, is that it should (at least partially) work for unknown/unlisted/unreleased cards, which might be an advantage over using lookup tables too ( less maintenance, i.e. not having to make a new release everytime nVidia releases/renames a card) ... it should also account for OC.
Thoughts ?
That's my preference, the direct approach. Using Boinc everything will be highly dependent on the BOINC version.
I've taken a quick look at the API and you can get the clock rate, and nr of processors etc. That may be enough to get an est. flop value.
-
BOINC changed from 'real' flops to 'peak' flops with http://boinc.berkeley.edu/trac/changeset/19310, so you can see both versions there - they're inline functions in trunk/boinc/lib/coproc.h
Here are the fields BOINC knows about for a CUDA card. This is taken from the information sent by the BOINC client to every project indiscriminately whenever 'update' is clicked (or a scheduler contact for any other purpose). You don't have to be requesting or reporting a CUDA task - in fact, you don't need to be talking to a CUDA-capable project at all. The only ambiguous field is 'clockRate': I've checked with GPU-Z, and the value is correct for the shader clock (as it should be). BOINC rates this card as 484 GFLOPS peak.
<coprocs>
<coproc_cuda>
<count>1</count>
<name>GeForce 9800 GTX/9800 GTX+</name>
<req_secs>25769.711159</req_secs>
<req_instances>0.000000</req_instances>
<estimated_delay>0.000000</estimated_delay>
<drvVersion>19038</drvVersion>
<cudaVersion>2030</cudaVersion>
<totalGlobalMem>536543232</totalGlobalMem>
<sharedMemPerBlock>16384</sharedMemPerBlock>
<regsPerBlock>8192</regsPerBlock>
<warpSize>32</warpSize>
<memPitch>262144</memPitch>
<maxThreadsPerBlock>512</maxThreadsPerBlock>
<maxThreadsDim>512 512 64</maxThreadsDim>
<maxGridSize>65535 65535 1</maxGridSize>
<totalConstMem>65536</totalConstMem>
<major>1</major>
<minor>1</minor>
<clockRate>1890000</clockRate>
<textureAlignment>256</textureAlignment>
<deviceOverlap>1</deviceOverlap>
<multiProcessorCount>16</multiProcessorCount>
</coproc_cuda>
</coprocs>
-
Good to see both versions via the changeset, cheers (bookmarking) , might use one of those estimates scaled initially, then try whip up more accurate bench later down the road if we find that would compensate better for memory speeds etc.
-
These values look to come out of the cudaApi. But what does the BOINC client actually do with these values.
My card gives 596 GFlops and the value I found to be correct is 22 GFlops. The last one is in the flops statement in the xml.
A bit of a difference. And as already mentioned the values differ quite a bit in various BOINC versions.
I see 62 GFlops on a older BOINC client and that card is no more than 1/2 as slow as the other one. I found it to be about 14 GFlops.
So 596 = 22 and 62 = 14
It looks these values don't have much to do with the actual calculation speed. More like theoretical values out of the sales brochure.
-
...
It looks these values don't have much to do with the actual calculation speed. More like theoretical values out of the sales brochure.
...
Absolutely.
[rant]
I actually got a little agitated when I installed Boinc 6.10.18 on my system & noticed it was claiming ~.~317GFlops 'peak' ... ( the words 'when hell freezes over' came to mind ;) Then I had a good laugh about it and felt much better). Of course with memory bound algorithms like larger FFT sizes, on that hardware, real world performance is more like 18-20GFLops, around twice that of each of my CPU Cores with the same problem. I've little doubt that kernels that do multiple redundant operations on the same data repeatedly, sitting in registers, on register sized (very small, ~8k total IIRC) datasets could acheive that kind of throughput ... The dumb thing is that sounds like graphics frame by frame processing more that general purpose computation[/rant]
I'm fairly certain the syntheic estimates shoudl be good enough, provided we scale the number appropriately to a realistic range... but there is the alternative of benching with real code if we find better accuracy is needed (which I doubt, but the option is there).
Jason
-
DA has added COPROCS to HOST_INFO Changeset 19797 (http://boinc.berkeley.edu/trac/changeset/19797)
Claggy
Edit: and after Changeset 19798 (http://boinc.berkeley.edu/trac/changeset/19798) get_host_info() GUI RPC now contains GPU info
-
DA has added COPROCS to HOST_INFO Changeset 19797 (http://boinc.berkeley.edu/trac/changeset/19797)
Claggy
In simple English, this would mean the projects which run on the GPU will improve in which way?
-
...
It looks these values don't have much to do with the actual calculation speed. More like theoretical values out of the sales brochure.
...
Absolutely.
[rant]
I actually got a little agitated when I installed Boinc 6.10.18 on my system & noticed it was claiming ~.~317GFlops 'peak' ... ( the words 'when hell freezes over' came to mind ;) Then I had a good laugh about it and felt much better). Of course with memory bound algorithms like larger FFT sizes, on that hardware, real world performance is more like 18-20GFLops, around twice that of each of my CPU Cores with the same problem. I've little doubt that kernels that do multiple redundant operations on the same data repeatedly, sitting in registers, on register sized (very small, ~8k total IIRC) datasets could acheive that kind of throughput ... The dumb thing is that sounds like graphics frame by frame processing more that general purpose computation[/rant]
I'm fairly certain the syntheic estimates shoudl be good enough, provided we scale the number appropriately to a realistic range... but there is the alternative of benching with real code if we find better accuracy is needed (which I doubt, but the option is there).
Jason
We probably could get a good estimate on the performance by using the number of processor cores and clock speed. And maybe the type of cores used etc.
The best way would be to run a small WU and see how long it takes to process, nothing beats the real world.
But it is the question of need, the flops don't need to be 100% accurate. I don't think a 20% change will do much, the WU will vary in time anyway.
Using the CudaApi, get the cores, clock and make our own more realistic formula.
-
...
Using the CudaApi, get the cores, clock and make our own more realistic formula.
Agreed. Let's try the easy way, and try predict indicators that show whether it'll be good enough, or needs the extra effort. Hopefully I'll have my build environment back up and functioning soon ( In the middle of Win7 migration after HDD death ::) ) so will be able to start making some small test pieces (.exe) with flop estimate outputs to experiment with in the installer scripts.
Jason
-
DA has added COPROCS to HOST_INFO Changeset 19797 (http://boinc.berkeley.edu/trac/changeset/19797)
Claggy
Edit: and after Changeset 19798 (http://boinc.berkeley.edu/trac/changeset/19798) get_host_info() GUI RPC now contains GPU info
No reply to my question on boinc_alpha, but it obviously had the desired effect!
I'll grab one as soon as there's a build available, and let you see it so you can decide if it's any use.
-
DA has added COPROCS to HOST_INFO Changeset 19797 (http://boinc.berkeley.edu/trac/changeset/19797)
Claggy
Edit: and after Changeset 19798 (http://boinc.berkeley.edu/trac/changeset/19798) get_host_info() GUI RPC now contains GPU info
No reply to my question on boinc_alpha, but it obviously had the desired effect!
I'll grab one as soon as there's a build available, and let you see it so you can decide if it's any use.
Hopefully the info is more than the same meaningless peak flop value that's already in the message log.
-
Hopefully the info is more than the same meaningless peak flop value that's already in the message log.
The CUDA peak flops is exactly as meaningful as the older estimated flops, ratio 5.6. IMO, they are better predictors of performance than the Whetstone benchmark used for CPUs.
Joe
-
Better prediction of relative performance I would add.
As absolute value it's meaningless of course.
9400GT performs ~ as 1 core of my quad now. And its estimation value is 45Gflops. IMO single quad core has very different actual performance...
-
Better prediction of relative performance I would add.
As absolute value it's meaningless of course.
9400GT performs ~ as 1 core of my quad now. And its estimation value is 45Gflops. IMO single quad core has very different actual performance...
In the BOINC source code the comment states: FLOPS for a given app may be much less; e.g. for SETI@home it's about 0.18 of the peak
And in the flops they really use is divided by 2 or 5.
And this sort of corrections if (!strcmp(plan_class, "cuda23")) {flops *= 1.01; } for the cuda dll being more efficient.
So it maybe that newer (beta/alpha) clients, already have a correction factor for the GPU flops and the statement may be obsolete by the time of release.
-
And this sort of corrections if (!strcmp(plan_class, "cuda23")) {flops *= 1.01; } for the cuda dll being more efficient.
CUDA 2.3 bring better performance improvement for CUDA MB than 1% so those 2 plans definitely will have different peak performance to real performance ratios for SETI project.
And 45/5=9(Gflops) - too much for single quad core performance too IMO.
That is, 5 times "peak to real" is pretty arbitrary coefficient.
All htis makes absolute Gflops unusable IMO. What needs to be checked: will 2 cards rated 45 and 90 Gflops by BOINC (for example) exhibit 2 times difference in performance for CUDA MB app or not (can BOINC estimates be used for relative performance comparisons or not).
-
DA has added COPROCS to HOST_INFO Changeset 19797 (http://boinc.berkeley.edu/trac/changeset/19797)
Claggy
Edit: and after Changeset 19798 (http://boinc.berkeley.edu/trac/changeset/19798) get_host_info() GUI RPC now contains GPU info
No reply to my question on boinc_alpha, but it obviously had the desired effect!
I'll grab one as soon as there's a build available, and let you see it so you can decide if it's any use.
Boinc 6.10.22 released:
boinc_6.10.22_windows_intelx86.exe (http://boinc.berkeley.edu/dl/boinc_6.10.22_windows_intelx86.exe)
boinc_6.10.22_windows_x86_64.exe (http://boinc.berkeley.edu/dl/boinc_6.10.22_windows_x86_64.exe)
Claggy
Edit: Installed 6.10.22_x86 on my laptop, Boinc reports a GPU on start up, but no GPU work runs, and project computer details no longer show a GPU.
Edit 2: Installed 6.10.22_64 on my Desktop PC, same, Boinc reports a GPU, but GPU tasks don't start, just show waiting to run,
Reported to Boinc_Alpha list, DA's looking into it.
-
DA has added COPROCS to HOST_INFO Changeset 19797 (http://boinc.berkeley.edu/trac/changeset/19797)
Claggy
Edit: and after Changeset 19798 (http://boinc.berkeley.edu/trac/changeset/19798) get_host_info() GUI RPC now contains GPU info
No reply to my question on boinc_alpha, but it obviously had the desired effect!
I'll grab one as soon as there's a build available, and let you see it so you can decide if it's any use.
Boinc 6.10.23 released:
boinc_6.10.23_windows_intelx86.exe (http://boinc.berkeley.edu/dl/boinc_6.10.23_windows_intelx86.exe)
boinc_6.10.23_windows_x86_64.exe (http://boinc.berkeley.edu/dl/boinc_6.10.23_windows_x86_64.exe)
Claggy
Edit: this version's no better:
09/12/2009 00:45:31 Collatz Conjecture Application uses missing NVIDIA GPU
09/12/2009 00:45:31 Collatz Conjecture Missing coprocessor for task collatz_1259356581_147128_0
-
Looks like I will stick with 6.10.21 for the time being then.
-
There's a v6.10.24 now, which does seem to work.
Here's the host_info output (my formatting):
<coprocs>
<coproc_cuda>
<count> 1 </count>
<name> GeForce 9800 GTX/9800 GTX+ </name>
<req_secs> 0 </req_secs>
<req_instances> 0 </req_instances>
<estimated_delay> 0 </estimated_delay>
<drvVersion> 19038 </drvVersion>
<cudaVersion> 2030 </cudaVersion>
<totalGlobalMem> 536543232 </totalGlobalMem>
<sharedMemPerBlock> 16384 </sharedMemPerBlock>
<regsPerBlock> 8192 </regsPerBlock>
<warpSize> 32 </warpSize>
<memPitch> 262144 </memPitch>
<maxThreadsPerBlock> 512 </maxThreadsPerBlock>
<maxThreadsDim> 512 512 64 </maxThreadsDim>
<maxGridSize> 65535 65535 1 </maxGridSize>
<totalConstMem> 65536 </totalConstMem>
<major> 1 </major>
<minor> 1 </minor>
<clockRate> 1890000 </clockRate>
<textureAlignment> 256 </textureAlignment>
<deviceOverlap> 1 </deviceOverlap>
<multiProcessorCount> 16 </multiProcessorCount>
</coproc_cuda>
</coprocs>
Shame about <req_secs>, <req_instances>, and <estimated_delay> - they belong with work fetch, not host info: but it's easier to ignore something unneeded, rather than invent something missing.
-
Hmm, same info as from the Cuda api device query function, (naturally I suppose). No need to use that particular RPC then. quite useful for a gui frontend/manager such that it wouldn't have to call cuda api though.
-
In this particular aspect BOINC resembles Win$ows for me.
Both have some "advanced" (at first sight) features that actually can't be used if really needed.
Cool, BOINC reports CPU features!... up to SSE2 :P
Cool, BOINC reports GPU card parameters... when all projects who need GPU app already implemented direct device query... As most of Win$ows additional software, standalone tools needed to do real work if it's needed...
Why it's not good: it takes time to implement those actually unneeded for scheduling features that only make BOINC hardware-depenend. Instead of working in terms of abstract computing devices and effectively manage that devices having their description it operates just particular devices from few vendors...
-
I felt that way a bit. Now with Win7x64 am pretty happy ... It seems it plays all my old crappy games that wouldn't play under XP/Vista 32 bit.... figure that one out :o
-
I felt that way a bit. Now with Win7x64 am pretty happy ... It seems it plays all my old crappy games that wouldn't play under XP/Vista 32 bit.... figure that one out :o
Hehe :D Try to run one of truly ancient ones, for Win 3.1 or even DOS... AFAIK there is no DOS VM in x64 windows (no real mode emulation so Win3.1 and DOS apps should be incompatible at all with Win7 x64 in theory. It would be nice to check it directly ;) )
(Something like Eye of Beholder or Uukrul ;D )
-
No problem. 'Dosbox' 0.73 (http://www.dosbox.com) working great for dos emualtion for very early things, In any case, nothing to do with installer flops, but probably shows that anything is possible...