English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 03 August 2015, 01:53   #201
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by Mrs Beanbag View Post
Well, it depends how basic. If it is a fixed size and you can guarantee no collisions, it is very simple. If it can dynamically grow, you have to think about different strategies. And just the hash function can range from simple to complex.
Fixed size with collisions and a simple hash algorithm. In C that's not complex at all, while it's already very effective.
Thorham is offline  
AdSense AdSense  
Old 03 August 2015, 08:07   #202
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Mrs Beanbag View Post
If you use polymorphic classes, you are using RTTI. Or at least if you ever use dynamic_cast.
I didn't ever use dynamic_cast. In fact i didn't use polymorphism much - i had very few needs for it and it ain't good for performance.


Quote:
Originally Posted by Mrs Beanbag View Post
ok. i have no idea, to be honest! i have wanted a PNG decoder for Amiga though, it strikes me as a convenient format to store my game data in, since it's much more efficient than ILBM and then i can create the graphics on anything.

Does it fully implement the PNG format, with all modes and colour depths?
I don't remember the exact details, but it does implement everything that's useful for an aga fullscreen picture viewer, i.e. it ignores transparency and converts 16 bit rgb (48 bits) to 8 bit rgb (24 bits).
All normal images are shown ; only malformed files will be rejected.

And, yes, someone here may try to inject code in an image to take control of the machine, using an exploit in my code

There is certainly free code available to decode these (this is where you will see that it's not as efficient as it looks ).


Quote:
Originally Posted by Mrs Beanbag View Post
Are you sure it is not just because old hard drives outlive new ones? They seem to have become terribly unreliable these days, a computer i built a few years ago had a hard drive fail recently and i was looking for a replacement and realised consumer drives now only come with 1 year warranties! It used to be 3 year warranties were standard. I guess they just don't care any more. It went downhill when they went over 500Gb i think, manufacturers were in such a competition for data density. Samsung had big problems with their platters and ended up having to limit drives to 5400 rpm for reliable operation.

Also temperature is a consideration. I keep my own PC very cool, and it is not very high-powered. There was a study that showed reliability decreased with increasing temperature. Gaming PCs can get very hot inside...

I am only using enterprise grade HDDs from now on and hang the expense.

Or SSDs... but for 2Tbs of SSD you are talking serious money.
Of course old drives outlive new ones, but nevertheless, i don't think many peecees from 2001, running nearly every day, have reached 2015 with the same hd...
meynaf is offline  
Old 03 August 2015, 08:10   #203
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Thorham View Post
Fixed size with collisions and a simple hash algorithm. In C that's not complex at all, while it's already very effective.
A hash is quite easy in asm as well. This is what PhxAss does for label handling (making a sizeable part of its speed).
meynaf is offline  
Old 03 August 2015, 10:15   #204
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by meynaf View Post
A hash is quite easy in asm as well. This is what PhxAss does for label handling (making a sizeable part of its speed).
Indeed, but you should see it in C, it's almost nothing.
Thorham is offline  
Old 03 August 2015, 12:50   #205
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Thorham View Post
Indeed, but you should see it in C, it's almost nothing.
A hash has no interest apart its speed. Why wasting it with C ?
meynaf is offline  
Old 03 August 2015, 12:59   #206
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
"simple" hash table, vs hash table with full functionality in C++ stl...

https://gcc.gnu.org/onlinedocs/libst...le-source.html

*eyes bleed*

Quote:
Originally Posted by meynaf View Post
A hash has no interest apart its speed. Why wasting it with C ?
If C is slower than Asm then you definitely want to be using an efficient algorithm!
Mrs Beanbag is offline  
Old 03 August 2015, 13:45   #207
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Mrs Beanbag View Post
If C is slower than Asm then you definitely want to be using an efficient algorithm!
Normally if you use C, speed isn't an issue.
meynaf is offline  
Old 03 August 2015, 13:47   #208
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
Normally if you use C, speed isn't an issue.
What absolute twaddle!
Mrs Beanbag is offline  
Old 03 August 2015, 13:57   #209
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Mrs Beanbag View Post
What absolute twaddle!
When you will have disassembled as much compiled code as i have, you'll know better.
meynaf is offline  
Old 03 August 2015, 13:59   #210
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by meynaf View Post
Normally if you use C, speed isn't an issue.
LOL! As an assembly coding fan I must remind you that current compilers are very good and often produce much better code than assembly language programmers. Assembly can still be faster but require a good programmer, a limited problem and a lot of time compared to higher level languages.
Megol is offline  
Old 03 August 2015, 14:03   #211
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Assembly might be faster than C (i don't even care if it is or not, let alone by how much) but the idea that if you're writing in C you wouldn't want to use a fast algorithm instead of a slow one is just so wat i don't even
Mrs Beanbag is offline  
Old 03 August 2015, 14:06   #212
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Megol View Post
LOL! As an assembly coding fan I must remind you that current compilers are very good and often produce much better code than assembly language programmers. Assembly can still be faster but require a good programmer, a limited problem and a lot of time compared to higher level languages.
This is completely wrong. Code quality on compilers is a myth.
When I wrote my FLaC decoder it was 4 times faster than its C counterpart (GCC compile). Just an example among many.
meynaf is offline  
Old 03 August 2015, 14:38   #213
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by guybrush View Post
Beside the love and the passion that the community have; I would like to see things from a different perspective:

Today, my multi core i5 with a GTX that has more MFLOPS than a battery of flying saucers. The AmigaOS was running on 14 Mhz processor, with 2 MB of ram and a bus at 33 Mhz I believe.

Beside the fact that it was actually a multi-core computer (the CPU was just driving the 3 custom chips); how advanced was the Amiga design, to see nowadays computers with GHz and GB of ram, having troubles to run even simple OS like linux?

I have got a Raspberry pi, since it is cheap and is a great retro machine; that thing has 4 core and 1 Ghz processor I believe, with a GPU integrated and 1 Gb of ram? That's 100 times an Amiga, but when you run even the simplest version of Linux, with minimal UI, it struggle.

I was wondering if today, someone would make an evolution of that design, so we can actually have a full computer, with OS and everything, on a small single board; so we can actually throw away all the various micro controllers that are sold for hobby use (like arduino and such); something light, multitasking, optimized.
Quote:
is there a reason why the Amiga design was abandoned? From what I see it, a dedicated video card, audio card and northbridge/southbridge are in fact replacing the 3 custom chips, but there is no chance to see an OS like AmigaOS, running as it does on the "puny" specs of a standard Amiga.
What are you calling "the Amiga design"?
The specific combination of blitter, copper, paula? If so it is severely outdated. The copper have no use at all in a modern display system. The blitter is too limited and to slow for modern systems and the paula really isn't much either. The combination of them did provide good performance for a consumer system at the time - that's all.
Or do you mean the use of coprocessors? If so a current modern system have more coprocessors with much more power than the Amiga design.
The GPU can do things Amiga programmers could only dream about.

Quote:
Did the programmers got worst with the increase of speed? Or Jay was in fact an alien genius that did something that nobody else is able to replicate?
Programmers worse? Perhaps. But the real reason are IMHO 1) that current systems do so much more with a design intended to provide more features 2) rose colored glasses 3) not comparing like to like.
Megol is offline  
Old 03 August 2015, 14:45   #214
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by meynaf View Post
This is completely wrong. Code quality on compilers is a myth.
When I wrote my FLaC decoder it was 4 times faster than its C counterpart (GCC compile). Just an example among many.
There was a time when I would use your argument and could provide examples how bad compilers were. But it isn't the 90s anymore.
A 4x difference without changing the algorithm sound suspicious.

Edit:
Let me guess: your compiler of choice doesn't support 64 bit values well and you require them extensively in order to avoid precision losses?

Last edited by Megol; 03 August 2015 at 14:51.
Megol is offline  
Old 03 August 2015, 14:58   #215
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Megol View Post
There was a time when I would use your argument and could provide examples how bad compilers were. But it isn't the 90s anymore.
A 4x difference without changing the algorithm sound suspicious.
We can't truly compare anyway. Who will write a whole program in asm today ? You could just argue that 68k compilers are very bad, that todays x86 (or whatever) are good, and no proof can be shown.

However if you pretend that a compiler can make 68k code that can beat mine, i'll just laugh


Quote:
Originally Posted by Megol View Post
Edit:
Let me guess: your compiler of choice doesn't support 64 bit values well and you require them extensively in order to avoid precision losses?
Huh, no.
meynaf is offline  
Old 03 August 2015, 15:26   #216
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
i had to go for a long walk before writing this reply.

it is as if everything i have said about algorithmic time complexity has just gone down a black hole. i said that a lot of problems in modern code are caused by programmers not understanding it, well it seems that old-timer asm coders don't understand it either. They know a hash map is "fast" but that's about it.

Maybe hand-coded asm (by an expert) is 4 times faster (i remember reading the figure 3 times faster on average, elsewhere) but let's just say 10 times for simplicity. In any case, it is a more-or-less constant factor for any given compiler.

The point is, you could write the most efficient bubble sort ever in hand-coded asm, but even a crudely implemented quick sort written in AMOS Basic would still outperform it given a sufficiently large input. The choice of algorithm makes far more difference than the choice of language for all but fairly trivial operations. Asm might be ten times faster than any given language, but an O(n log n) algorithm might be hundreds, thousands, even millions of times faster than a naive O(n^2) algorithm, for the size of data sets you are dealing with.

Well then you would say, if you wrote the quick sort in asm it would be ever faster still. And you'd be right. But the user really doesn't care if he gets his result in a tenth of a second or a hundredth of a second, but he sure as hell doesn't want to have to wait ten minutes.

Of course we care about speed, but performance isn't the only consideration. There are other priorities too, such as development time, portability, maintainability, and of course being able to hire people who can actually do it.
Mrs Beanbag is offline  
Old 03 August 2015, 15:33   #217
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by meynaf View Post
We can't truly compare anyway. Who will write a whole program in asm today ? You could just argue that 68k compilers are very bad, that todays x86 (or whatever) are good, and no proof can be shown.
There's a lot of assembly code produced by those that claim assembly is superior, in general the code is shit.

Quote:
However if you pretend that a compiler can make 68k code that can beat mine, i'll just laugh
Given the same time and on a large project?

Quote:
Huh, no.
And you use the same algorithm? Still sounds fishy.
Megol is offline  
Old 03 August 2015, 15:47   #218
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by Mrs Beanbag View Post
i had to go for a long walk before writing this reply.

it is as if everything i have said about algorithmic time complexity has just gone down a black hole. i said that a lot of problems in modern code are caused by programmers not understanding it, well it seems that old-timer asm coders don't understand it either. They know a hash map is "fast" but that's about it.

Maybe hand-coded asm (by an expert) is 4 times faster (i remember reading the figure 3 times faster on average, elsewhere) but let's just say 10 times for simplicity. In any case, it is a more-or-less constant factor for any given compiler.
Such huge differences is either the result of the compiler not being mapped well to the processor or using a feature that can't be directly exposed in the high level language model.
The solution to those problem is in most cases inline assembly code or using intrinsics.

In the general case what causes compilers to be slower is rigid calling conventions.

Quote:
The point is, you could write the most efficient bubble sort ever in hand-coded asm, but even a crudely implemented quick sort written in AMOS Basic would still outperform it given a sufficiently large input. The choice of algorithm makes far more difference than the choice of language for all but fairly trivial operations. Asm might be ten times faster than any given language, but an O(n log n) algorithm might be hundreds, thousands, even millions of times faster than a naive O(n^2) algorithm, for the size of data sets you are dealing with.
Obviously true for anybody with some programming education. Unless one have a problem with (almost) sorted data

Quote:
Well then you would say, if you wrote the quick sort in asm it would be ever faster still. And you'd be right. But the user really doesn't care if he gets his result in a tenth of a second or a hundredth of a second, but he sure as hell doesn't want to have to wait ten minutes.

Of course we care about speed, but performance isn't the only consideration. There are other priorities too, such as development time, portability, maintainability, and of course being able to hire people who can actually do it.
And the programmer that have more time on his/her hands can spend it by testing other algorithms potentially leading of huge speedups.

Strictly speaking assembly can be faster than higher level languages (but not generally) but for most problems runtime generated machine code is the fastest. But that's even messier.
Megol is offline  
Old 03 August 2015, 15:48   #219
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Megol View Post
There's a lot of assembly code produced by those that claim assembly is superior, in general the code is shit.
It may be shit sometimes, but this shit still runs faster than what compilers produce


Quote:
Originally Posted by Megol View Post
Given the same time and on a large project?
I can write asm faster than many people write C (or java, or anything else).


Quote:
Originally Posted by Megol View Post
And you use the same algorithm? Still sounds fishy.
Yes. When i change the algorithm itself, you can expect even bigger gains (i got a routine 14x faster in my heroes2 port, in the editor).

As an example, take my picture viewer (aga only). You will never ever find a compiler that can just approach its speed. Actually it might even beat x86-compiled native code on the same machine when ran under winuae's jit.
http://meynaf.free.fr/pr/mv.lzx
meynaf is offline  
Old 03 August 2015, 16:03   #220
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,459
Quote:
Originally Posted by Mrs Beanbag View Post
The point is, you could write the most efficient bubble sort ever in hand-coded asm, but even a crudely implemented quick sort written in AMOS Basic would still outperform it given a sufficiently large input.
Of course the algorithm helps, but it's not always like bubble vs quick sort. My asm implementation of jpeg's "slow int" DCT is faster than the compiled "fast int" version - slower algorithm, but still faster code.


Quote:
Originally Posted by Mrs Beanbag View Post
Well then you would say, if you wrote the quick sort in asm it would be ever faster still. And you'd be right. But the user really doesn't care if he gets his result in a tenth of a second or a hundredth of a second, but he sure as hell doesn't want to have to wait ten minutes.
Obviously, but if you have something taking 90% cpu, you're happy it's not twice as slow. When i rewrote mpega.library's huffman decoder (which was C), i was happy to finally be able to listen to 320kbps mp3s on my 030 with acceptable quality.


Quote:
Originally Posted by Mrs Beanbag View Post
Of course we care about speed, but performance isn't the only consideration. There are other priorities too, such as development time, portability, maintainability, and of course being able to hire people who can actually do it.
Never said otherwise.
meynaf is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Amiga 1200 computer sidrulez! MarketPlace 4 02 January 2015 00:36
looking for my amiga 3000 computer amicrawler MarketPlace 4 19 September 2009 22:50
Amiga inc reveal new entry Amiga computer - $489usd Mikey_C News 132 01 October 2007 14:10
The DADDY Amiga computer is? Bloodwych Retrogaming General Discussion 27 05 August 2002 19:14

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:47.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.32227 seconds with 11 queries