1
- 13 December 2024, 19:24
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
clrmame Discussion / Re: Open source on Github
« on: 24 March 2018, 11:13 »
Hello
Ok, so I started to write from scratch another Rom manager in Java...
Regards
Ok, so I started to write from scratch another Rom manager in Java...
Regards
3
clrmame Discussion / Re: Open source on Github
« on: 20 March 2018, 06:19 »
Indeed, Intel J1800 is a slow processor, so yes, I could use batch mode with single profiles for software lists, *but* with my I5-3570 it's anything but slow, combined mode is very fast under windows, and even with virtualbox+wine overhead, that's not normal that the allocation phase for hash tables goes from <1s on windows to >1500s on VB+Linux+Wine with the same computer...
Anyway, I'll check on a Dual Xeon E5-2640v3 server with 256GB DDR4@2400, SSD only, running Proxmox
Anyway, I'll check on a Dual Xeon E5-2640v3 server with 256GB DDR4@2400, SSD only, running Proxmox
4
clrmame Discussion / Re: Open source on Github
« on: 19 March 2018, 15:25 »
One more thing... this memory alloc slow down is happening only with software lists included (with all configured systems/roms paths), it's immediate (<1s) with no software list
5
clrmame Discussion / Re: Open source on Github
« on: 19 March 2018, 13:12 »
ok I don't say minutes then (but I think hard enough)
6
clrmame Discussion / Re: Open source on Github
« on: 19 March 2018, 12:48 »
Same problem under virtualbox on my Windows10 PC with Intel I5, it took 25mn for memory allocation, so it's not an hardware problem
I'll now try 2 other things :
- Wine32/CMPro32
- Debian Stretch (stable) instead of Debian Buster (testing)
I'll now try 2 other things :
- Wine32/CMPro32
- Debian Stretch (stable) instead of Debian Buster (testing)
7
clrmame Discussion / Re: Open source on Github
« on: 19 March 2018, 11:09 »
yes it's a very slow memory allocation problem, I'm currently installing a fresh debian on virtualbox on my windows computer to see if the problem is linux/wine or hardware
8
clrmame Discussion / Re: Open source on Github
« on: 19 March 2018, 10:21 »
So if I understand well the situation, on my J1800 with wine (debian buster), the preallocation takes 30mn, then the progress bar show up, then the hash table is filled up and take less than 1mn
Many thanks to look at it when possible, an optimisation would be greatly appreciable on this preallocation part
BTW, on my Core-I5 3570 with native windows 10, this is almost immediate, there is a big gap! I would be tempted to try with virtualbox on my I5 just to see if it's a wine problem or a hardware problem...
Many thanks to look at it when possible, an optimisation would be greatly appreciable on this preallocation part
BTW, on my Core-I5 3570 with native windows 10, this is almost immediate, there is a big gap! I would be tempted to try with virtualbox on my I5 just to see if it's a wine problem or a hardware problem...
9
clrmame Discussion / Re: Open source on Github
« on: 19 March 2018, 08:17 »
That may not be noticeable if your hardware is too fast, I started to see a problem when I was working on slow hardware, but even under wine with ext4 on sata drive or usb3 drive, that won't be visible, but if you use usb2 port, and/or an old drive, and/or a shared network, or whatever which slow down I/O you should start to notice that "looking for unknown sets" phase will be slow on empty directories, and will accelerate on zip files...
I tried ntfs and ext4 (but not fat), wine and native, local and shared network... the problem is present everywhere at different degrees when using slow hardware
Another odd problem on slow hardware (in my case it's an Intel Celeron J800 with 2GB DDR3@1333) especially with wine, when I click on "Scan" or "New Scan" with a profile that use a full mame software list, I have to wait lot of minutes (around 30mn) before the progress bar start to show with "Creating HashTables"... During this time the only thing I see is cmpro's memory usage growing slowly from 270MB up to ~1GB , no disk io, and its process at 100%, I suppose you are making many small struct allocation in memory for each rom/set... is it possible to look at that part to see if it's possible to optimize? Please note that this 30mn wait does happen with a freshly started cmpro, it does not happen if I start a scan again, or if I reload the same profile
Thank you
I tried ntfs and ext4 (but not fat), wine and native, local and shared network... the problem is present everywhere at different degrees when using slow hardware
Another odd problem on slow hardware (in my case it's an Intel Celeron J800 with 2GB DDR3@1333) especially with wine, when I click on "Scan" or "New Scan" with a profile that use a full mame software list, I have to wait lot of minutes (around 30mn) before the progress bar start to show with "Creating HashTables"... During this time the only thing I see is cmpro's memory usage growing slowly from 270MB up to ~1GB , no disk io, and its process at 100%, I suppose you are making many small struct allocation in memory for each rom/set... is it possible to look at that part to see if it's possible to optimize? Please note that this 30mn wait does happen with a freshly started cmpro, it does not happen if I start a scan again, or if I reload the same profile
Thank you
10
clrmame Discussion / Re: Open source on Github
« on: 18 March 2018, 18:04 »
Yes, that’s right
It’s faster with ext4, but still present, it should be also visible on windows with slow drives (let’s say on usb2 keys for example)
It’s faster with ext4, but still present, it should be also visible on windows with slow drives (let’s say on usb2 keys for example)
11
clrmame Discussion / Re: Open source on Github
« on: 18 March 2018, 10:50 »
I mean all setnamed folders that should contain chd files inside rom path, except that almost chd were removed, and so those folders are currently empty
This happens on clrmamepro thru wine with direct access on a mounted ntfs drive *and* also on windows native when accessing thru samba share to that same mounted ntfs drive (using ntfs-3g fuse filesystem), the cpu goes above 80% on mount.ntfs-3g process during that phase (and it's significantly faster on checking unknown zip files than those empty directories)
Please note that I'm currently converting that drive from ntfs to ext4
I tried to scan the same rom dir with RomVault (using Mono and also native windows thru samba share), and got no general problem of performance, but I don't know what is exactly done while scanning with that rom manager...
Please also note that the rom path on NTFS drive is a SYMLINKD on another ROM path on that same drive
This happens on clrmamepro thru wine with direct access on a mounted ntfs drive *and* also on windows native when accessing thru samba share to that same mounted ntfs drive (using ntfs-3g fuse filesystem), the cpu goes above 80% on mount.ntfs-3g process during that phase (and it's significantly faster on checking unknown zip files than those empty directories)
Please note that I'm currently converting that drive from ntfs to ext4
I tried to scan the same rom dir with RomVault (using Mono and also native windows thru samba share), and got no general problem of performance, but I don't know what is exactly done while scanning with that rom manager...
Please also note that the rom path on NTFS drive is a SYMLINKD on another ROM path on that same drive
12
clrmame Discussion / Re: Open source on Github
« on: 18 March 2018, 07:19 »
Hello,
Moving to .NET could be a first step to the universal app, Linux and MacOS X users will be able to run cmpro using Mono instead of Wine which is painful as soon as an app is using lot of disks I/O
btw, as I talk about I/O : cmpro seems to be incredibly slow on empty subdirs when "looking for unknown sets", that strange behavior is far more visible thru samba shares, at a point that seconds become minutes
regards
Moving to .NET could be a first step to the universal app, Linux and MacOS X users will be able to run cmpro using Mono instead of Wine which is painful as soon as an app is using lot of disks I/O
btw, as I talk about I/O : cmpro seems to be incredibly slow on empty subdirs when "looking for unknown sets", that strange behavior is far more visible thru samba shares, at a point that seconds become minutes
regards
Pages: [1]