[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mint 1.10 Slow??
In article <9408111557.AA03092@hpbeo79.bbn.hp.com> you write:
>> Ok MagC ! is really faster !!! This is true. But MagC! has NO !!! Minix XFS
>> support ! If you want to compile with gcc you MiNT/Minix XFS & gcc. With
>> pure C you can't really work, can you ??? MiNT compiled with gcc is much
>> better than with Pure C !
>
>What a dynamic answer 8-) Could someone please write a converter
>which turns exclamation marks into CPU cycles - given Filipe's
>abundant input, this would speed up MiNT considerably.
*grin*
>
>Seriously, MiNT is only a multitasking kernel, and Mag!X also
>has an optimized VDI (essentially NVDI) and AES as well as BIOS
>and XBIOS. It's not surprising that it is really fast. MiNT alone
>can never get there.
..running GEM programs you mean. ok i don't really know Mag!X but
when i'm typing on the shells or in vi or whatever i don't get the
feeling i have such a slow system, not anymore... only when i run
CPU intensive stuff like compilers, floatingpoint things... or use GEM.
(or do stuff on GEMDOS filesystems but that also rarely happens
anymore. or can Mag!X display modem2 input @ 57600 bps without flow
control on a poor MegaSTe?)
so use minixfs, init, virtual consoles :) and avoid GEM whenever
you can. then its not soo bad IMHO...
>
>This is not to say that MiNT itself cannot be optimized at all,
>but I'm not at all in a position to judge where performance is lost.
>Do we have decent profiling tools for the MiNT kernel to find out
>more about the time spent in the various areas? If not, I'd suggest
>we start writing such debug/profiling utilities first to make sure
>that we're focusing on the right places for performance enhancement.
>Something like counting the CPU time for each of the kernel calls
>(and maybe a level below that) would be nice.
hmm gprof? i haven't tried it, maybe you have to disable the
tosfs disk change stuff...
what surely could take some profiling is GEM... but since atari isn't
likely to do it and others won't see source... (am i right multitos
still has no own malloc/free lib i.e. still does Malloc for every
little chunk? etc.)
my $.02...
Juergen