Discrete Opamp Open Design - Page 252 - diyAudio
Go Back   Home > Forums > Source & Line > Analog Line Level

Analog Line Level Preamplifiers , Passive Pre-amps, Crossovers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 3rd January 2013, 07:35 PM   #2511
RNMarsh is offline RNMarsh  United States
diyAudio Member
 
RNMarsh's Avatar
 
Join Date: May 2012
Location: 2457 Cascade Trail; Cool, CA. 95614
I know I am cryptic at times ( OK, a lot of the time). I mean if we could ween average joe citizen off Microsoft Windows and over to Linux OS we would stand a chance of doing better by allowing for a new cpu archit... one which would be more like a mini-computer. Just how do you turn the big Windows/Intel uPC ship around? Or, are there alternatives (mini-cpu) that are affordable, PNP, for personal use that I dont know about? What cpu do you use -- and software?

I used to have -in my home- an LSI-11 (RT11 OS) maxed out mem and drives of the time..... math coprocessor and the works... efficienct codes and less operating overhead made it do FFT very fast. I used DADiSP software at home ... still available for PC too. Look it up. Superfast -- I could change part values on the schematic and see the bode-plot etc in real time change in the other window. In fact I could have a dozen windows open on the display screen and see the effect in each window's plot of what-ever change made in one window. You dont need a tonne of memory to do this but efficient code and cpu designed for number crunching (eg 'scientific'). And, it didnt use windows or linux... all machine code.
BTW - these number crunching machines are misleading when you compare memory size needed to get work done with todays x86 derivitive machines. The many layers of code and switching data I/O of mem is the best reason to change over to SSD. You'll think you just got hooked up to a Mini-cpu machine. really. Thx-RNMarsh

Last edited by RNMarsh; 3rd January 2013 at 07:58 PM. Reason: guts and gore -- decoding RNM
  Reply With Quote
Old 3rd January 2013, 08:47 PM   #2512
wahab is offline wahab  Algeria
diyAudio Member
 
Join Date: Nov 2009
Location: algeria/france
Quote:
Originally Posted by RNMarsh View Post
There is no reason why a dual or quad core PC couldnt do sim a lot faster
Simulation of dynamic systems has extreme data dependencies ,
that is , a computation need the previous results to be be executed ,
hence there s essentialy serial code that can hardly be parralelized.

Just try simulating any circuit with a multicore CPU , you ll see that
most of the work is done in a single core , with a second core being
marginaly used..

Quote:
Originally Posted by scott wurcer View Post
I looked and could not find any references for this. I don't know of any semiconductor company that owns a supercomputer configured for circuit simulation. Intel would be the best bet, I don't know.
Actually it is years that they are using all their available PCs in a giant cloud
to increase computation throughput...
  Reply With Quote
Old 3rd January 2013, 09:30 PM   #2513
diyAudio Member
 
scott wurcer's Avatar
 
Join Date: Jan 2004
Location: cambridge ma
Quote:
Originally Posted by wahab View Post

Actually it is years that they are using all their available PCs in a giant cloud
to increase computation throughput...
I already said we do that yesterday. I don't see Linux being served by a different CPU architecture. There simply has to be a compelling business argument. The only modern CPU that I've programmed in assembler was a 68040, Apple's prefered compiler vendor would not support any number crunching optimizations. The 68040 with co-processor had 8-80 bit FP registers. (great for pipelining FFT's) but the compiler even ignored variables declared register in C. I wrote a micro-optimzed FFT and posted back in the USENET days. A year or so later a guy from GE medical e-mailed me and asked for my source code for their next CT scanner. A strange way for me to help a customer.

There is a LOT more to this than simply hardware, it simply is not practicle anymore to depend on your software support to program/maintain a large package in assembler/machine code.

The holidays were not the best time to order parts and boards. The ETA is Monday for everything, so maybe next weekend a real prototype test.
__________________
"The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important."
  Reply With Quote
Old 3rd January 2013, 10:17 PM   #2514
bcarso is offline bcarso  United States
diyAudio Member
 
Join Date: May 2005
Location: Canoga Park, California
Quote:
Originally Posted by scott wurcer View Post
I already said we do that yesterday. I don't see Linux being served by a different CPU architecture. There simply has to be a compelling business argument. The only modern CPU that I've programmed in assembler was a 68040, Apple's prefered compiler vendor would not support any number crunching optimizations. The 68040 with co-processor had 8-80 bit FP registers. (great for pipelining FFT's) but the compiler even ignored variables declared register in C. I wrote a micro-optimzed FFT and posted back in the USENET days. A year or so later a guy from GE medical e-mailed me and asked for my source code for their next CT scanner. A strange way for me to help a customer.

There is a LOT more to this than simply hardware, it simply is not practicle anymore to depend on your software support to program/maintain a large package in assembler/machine code.
In this general connection, always reminded of this classic piece: Real Programmers Don't Use PASCAL
  Reply With Quote
Old 3rd January 2013, 11:46 PM   #2515
diyAudio Member
 
scott wurcer's Avatar
 
Join Date: Jan 2004
Location: cambridge ma
Quote:
Originally Posted by bcarso View Post
In this general connection, always reminded of this classic piece: Real Programmers Don't Use PASCAL

Love it! Yes - "Real Programmers write self-modifying code, especially if it saves them 20 nanoseconds in the middle of a tight loop."

I once wrote a self modifying convolution algorithm that eliminated redundant (most useful kernels are symmetric) multiplies and turned all 1, 0, -1 operations into adds/subracts on the fly.
__________________
"The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important."
  Reply With Quote
Old 4th January 2013, 01:23 AM   #2516
RNMarsh is offline RNMarsh  United States
diyAudio Member
 
RNMarsh's Avatar
 
Join Date: May 2012
Location: 2457 Cascade Trail; Cool, CA. 95614
Here's the point. The Intel/Microsoft lash-up could be a lot better.... There is real need for something better that is affordable to individuals and small business's. Just because it isnt being done right now is NO sign that there is NO Compelling reason for it. We wouldnt have High Def Tv and G4+ etc without industry being forced to change. There exists a compelling need. The PC we have in our homes was designed for data manipulation. Not for math calculations. Thus we have work arounds -- like off loading the video data to a seperate dpu with its own memory. And the addition of DSP's for the heavy lifting with math... such as sim's, real-time signal processing and subjects where time to execute is critical and predictable. Both code and hardware must be extreamly efficient to accomplish this. [enter stage left - DSP]. Most computers (like the PC) are not optimized to do both - data manipulation and mathematical calculations. The existing PC is trying to do both but was set up from the beginning -optimized-to be a data manipulator (data base management, word processing, etc). IMO its time to have a PC type that is optimized for engineering, science and digital signal processing. Let that PC do data manipulation as a secondary function....
OK Now I'm off my soap box. [but still upgrade asap to SSD] Thx-RNMarsh
  Reply With Quote
Old 4th January 2013, 01:43 AM   #2517
wahab is offline wahab  Algeria
diyAudio Member
 
Join Date: Nov 2009
Location: algeria/france
Current X86 CPUs do not ressemble to their ancestors.

X86 code is no more directly executed , it is translated in the fly in simple
RISC instructions.

Moreover , the old X86/87 instructions sets are there only for backward compatibility ,
most of the used instructions are at most ten years old starting with SSE2 up to
SSSE3/SSE3/4.1/4.2 and more recently AVX , most dedicated to maths computation ,
particularly the recent FMA3/4 (available on AMD CPUs and starting next year for Intel)
wich allow a floating point multiply+add in a single oiperation and with no intermediary
rounding that would render the operation less precise than a sequentialy executed one.

Currents CPUs have more than 1000 instructions , to compare with the 200 or so
twenty years ago.

Quad cores CPUs and beyond can process more than 100 gigaflps in double
precision and this will be vastly increased in the next years thanks to GPUs being
capable of offloading the CPU of Floating Point massively parralelizable tasks , so
i dont think that current PCs are not adequate for scientific calculations..
  Reply With Quote
Old 4th January 2013, 03:16 AM   #2518
gerhard is offline gerhard  Germany
diyAudio Member
 
gerhard's Avatar
 
Join Date: Oct 2005
Location: near Stuttgart, south Germany
Quote:
Originally Posted by scott wurcer View Post
I already said we do that yesterday. I don't see Linux being served by a different CPU architecture. There simply has to be a compelling business argument. The only modern CPU that I've programmed in assembler was a 68040, Apple's prefered compiler vendor would not support any number crunching optimizations. The 68040 with co-processor had 8-80 bit FP registers. (great for pipelining FFT's) but the compiler even ignored variables declared register in C.
Linux is served well on ARM and PowerPC; it's just that these machines are
either not performance-oriented or out of reach financially (current IBM
mainframe PPCs). The only real alternative to the x86 died with the DEC alpha.

And regarding 68K floating point: you were quite lucky. Some friends of
mine bought a Unix System V source license (that cost an arm and a leg)
and built 68010 machines around it.. Some day an alpha customer called...
"Your C compiler produces code that the assembler cannot translate!?!"
It turned out that the Motorola compiler happily generated VAX floating
point instructions in the 68010 asm output.

Too late here (5 am) to continue...

regards, Gerhard

(written on a Dell Precision laptop running at 2.5 GHz * 4 CPUs *2 threads,
2*512 GB SSD, 16 G RAM, almost idle..)
__________________
Everything has been said already - but not yet by everyone. (Karl Valentin)
  Reply With Quote
Old 4th January 2013, 03:25 AM   #2519
wahab is offline wahab  Algeria
diyAudio Member
 
Join Date: Nov 2009
Location: algeria/france
Quote:
Originally Posted by gerhard View Post

regards, Gerhard

(written on a Dell Precision laptop running at 2.5 GHz * 4 CPUs *2 threads,
2*512 GB SSD, 16 G RAM, almost idle..)
Rather 2 CPUs / 4 threads ..?..


Written on an old laptop Compaq Pentium4 1.6Ghz...
1 CPU/1thread 160GB HD 1G RAM almost iddle as well...

Last edited by wahab; 4th January 2013 at 03:28 AM.
  Reply With Quote
Old 4th January 2013, 03:47 AM   #2520
gerhard is offline gerhard  Germany
diyAudio Member
 
gerhard's Avatar
 
Join Date: Oct 2005
Location: near Stuttgart, south Germany
Quote:
Originally Posted by scott wurcer View Post
Love it! Yes - "Real Programmers write self-modifying code, especially if it saves them 20 nanoseconds in the middle of a tight loop."
At THAT time, we had a sign at our door in the Berlin Technical University:

Phearless
Pascal
Phreaks

and UCSD Pascal on a LSI11/2 or a 68010 really was a Really Good Thing(R).
Pascal MT+ on Z80 was not that bad, but Turbo Pascal on Z80 was GREAT!!!

We also had the first European machine (Dual PDP11/40E, but running only
one processor) with Unix on it. There were only 4 or 5 PDP11/40Es ever
(E was for microprogrammable. Someone at TUB made a microprogrammed
pascal interpreter for it, Peer Brinch Hansons' version, and it ran like a
scalded dog. )

regards, Gerhard
__________________
Everything has been said already - but not yet by everyone. (Karl Valentin)
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

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
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Discrete OPAMP audio-gd Vendor's Bazaar 27 20th September 2012 04:02 PM
discrete opamp help blackpowderaudio Parts 0 16th December 2009 03:46 PM
THAT transistor headphone amp (250ma discrete opamp) design sanity check. Russ White Headphone Systems 19 13th December 2007 12:52 PM


New To Site? Need Help?

All times are GMT. The time now is 01:18 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2